Caso de éxito · SaaS de seguridad y cumplimiento
Plataforma europea de cumplimiento ISO 27001 (cliente bajo NDA)
Cómo Preparamos un SaaS de Cumplimiento ISO 27001 para Producción en AWS
Una empresa europea de seguridad de la información tenía un producto en Next.js que ayuda a sus clientes a gestionar programas ISO/IEC 27001: biblioteca de controles, pedidos de evidencia, análisis de brechas, registros de riesgos y auditorías, revisiones de accesos, registro de proveedores y documentos del SGSI generados automáticamente. El producto corría sobre Supabase Auth y Vercel. Sus clientes auditan seguridad, así que la plataforma tenía que cumplir el mismo estándar que les ayuda a alcanzar.
Siblings Software completó la aplicación y la llevó a producción en la cuenta de AWS del propio cliente: ECS Fargate, RDS PostgreSQL, Cognito, S3 y SES, con MFA obligatorio, aislamiento de clientes a nivel de base de datos y una ruta de despliegue donde cada cambio se escanea, se ensaya y se controla antes de llegar a producción.
En resumen
| Cliente | Empresa europea de seguridad de la información (bajo NDA) |
| Producto | SaaS multi-cliente para programas ISO/IEC 27001 |
| Modalidad | Proyecto cerrado de finalización y endurecimiento |
| Período | Septiembre a octubre de 2026 |
| Stack | Next.js 16, Prisma, PostgreSQL 18 en RDS, ECS Fargate, Cognito, S3, SES, GitHub Actions |
| División del trabajo | Siblings: aplicación, CI/CD y runbooks. Cliente: cuenta de AWS y Terraform |
| Estado | En producción en AWS desde octubre de 2026 |
- Equipo: Siblings Software
- Servicios relacionados: Servicios DevSecOps, Migración a la nube, Desarrollo Next.js
- Más ejemplos: todos los casos de éxito
El Desafío
El producto funcionaba como MVP, pero había tres obstáculos para venderlo a empresas. La autenticación dependía de un servicio externo que no coincidía con el destino de AWS del contrato. El aislamiento entre clientes dependía del código de la aplicación, así que un filtro olvidado podía exponer la evidencia de cumplimiento de otro cliente. Y no había una forma repetible y auditable de publicar un cambio en producción.
El contrato fijaba el destino: GitHub Actions hacia Amazon ECR, dos tareas de ECS Fargate detrás de un balanceador, RDS PostgreSQL, Cognito y S3, dentro de la cuenta de AWS del cliente. El equipo de infraestructura del cliente administra esa cuenta y escribe el Terraform. Siblings tenía que entregar una aplicación que encajara exactamente en esa plataforma, sin manejar nunca valores secretos.
Qué Construyó Siblings
Terminamos y endurecimos los módulos que los clientes usan todos los días: biblioteca de controles y mapeos, pedidos de evidencia con carga de archivos, cuestionarios y planillas, análisis de brechas, registros de riesgos, auditorías, revisiones de accesos y proveedores, documentos del SGSI con editor, recordatorios por email, métricas y agenda sincronizada con Outlook mediante Microsoft Graph.
Después llevamos la plataforma a nivel de producción. El login pasó a Amazon Cognito con MFA obligatorio por app autenticadora, verificado por la aplicación en cada sesión, así una contraseña sola nunca llega a los datos de clientes. El aislamiento entre clientes pasó a PostgreSQL con seguridad a nivel de fila forzada, sin roles que la salteen en tiempo de ejecución y con un registro de auditoría de solo agregado. Cada pedido recibe un nonce nuevo de Content Security Policy, cada escritura se valida contra CSRF, los archivos se validan por contenido y tamaño, y las rutas sensibles tienen límites de uso.
Cómo se Publica Cada Versión
La integración continua revisa licencias de dependencias, busca secretos filtrados, mantiene npm audit en cero, corre lint y chequeo de tipos, y ejecuta unas veinte suites de prueba automatizadas contra un PostgreSQL 18.3 real: aislamiento entre clientes, autenticación y MFA, seguridad de la aplicación, almacenamiento, agenda, contratos de despliegue y cada módulo del producto.
Las imágenes se construyen sobre imágenes base endurecidas y fijadas, y se escanean con Trivy, que frena la publicación ante cualquier vulnerabilidad crítica con corrección disponible. GitHub Actions se autentica en AWS con OpenID Connect, sin claves de AWS de larga duración en el repositorio. Las imágenes se suben a ECR por digest inmutable. Las migraciones viajan en una imagen separada, se ensayan contra PostgreSQL 18.3 con los permisos exactos del rol de producción, y la actualización de ECS solo avanza cuando ese mismo digest ya fue migrado. Volver atrás es redesplegar el digest anterior.
Resultados y Estado Actual
El paquete de preparación para producción se cerró el 13 de octubre de 2026. Un login real con contraseña y app autenticadora en el pool de Cognito de producción llegó a la aplicación el 10 de octubre, y durante el despliegue los pedidos alternaron entre dos tareas de ECS mientras la sesión cifrada se mantuvo en ambas, sin volver a pedir login. El email salió del sandbox de SES el 6 de octubre. Todas las suites automatizadas pasan en CI y npm audit sigue en cero.
Algunos puntos quedan deliberadamente del lado del cliente: conectar Microsoft Graph para la sincronización real de casillas, programar las tareas de recordatorios y agenda en su infraestructura, y cargar sus propios datos. Una prueba de penetración quedó fuera de este paquete. Cada uno está documentado en un runbook que el equipo del cliente puede seguir sin nosotros.
Cómo Usamos Agentes de IA con Seguridad
Gran parte del código se escribió con agentes de IA que trabajan dentro de reglas escritas para el repositorio. Esas reglas prohíben credenciales, claves, tokens y datos de clientes en los prompts, exigen datos de prueba sanitizados y exigen revisión humana de cada migración generada y de todo el código de seguridad. Los controles de CI de arriba aplican a los cambios de los agentes igual que a los de las personas.
Es el modelo de entrega que usamos hoy en todos los proyectos. Mirá servicios DevSecOps para los controles del pipeline y seguridad de código generado con IA para cómo revisamos código hecho con IA.
Preguntas Frecuentes
Sí. En este proyecto el equipo del cliente administraba la cuenta de AWS y el Terraform, y Siblings entregó la aplicación, el pipeline de CI/CD y un contrato escrito entre ambos: nombres de variables y secretos, tamaño de las tareas, endpoints de salud, pasos de migración y vuelta atrás. Nunca leemos valores secretos.
Si lo necesitás, sí, como parte de nuestros servicios de ingeniería de plataformas y migración a la nube. Cuando tu equipo ya administra el Terraform, como en este caso, documentamos exactamente lo que necesita la aplicación y la infraestructura queda en tus manos.
Acá el login usa Amazon Cognito con app autenticadora obligatoria, y la propia aplicación verifica el enrolamiento en cada sesión, así un token sin segundo factor confirmado nunca llega a datos de clientes. Las passkeys no se aceptaron como reemplazo de la app autenticadora a propósito.
En PostgreSQL, con seguridad a nivel de fila forzada, para que ni siquiera un error en el código de la aplicación pueda devolver filas de otro cliente. La aplicación se conecta con un rol que no puede saltear esas políticas, y pruebas automáticas con dos clientes verifican el aislamiento en cada cambio.
Sí. El nombre de este cliente es confidencial por un NDA mutuo, por eso este caso describe el trabajo sin nombrarlo. Podemos coordinar una llamada de referencia con su permiso.
¿Necesitás un producto SaaS listo para clientes exigentes en seguridad?
Completamos, endurecemos y publicamos productos que tienen que pasar revisiones de seguridad de empresas. Empezá por servicios DevSecOps, migración a la nube o ingeniería de plataformas, o contanos sobre tu producto acá abajo.