Seguridad y Prácticas de Ingeniería
Cómo construimos, qué protegemos y qué ponemos por escrito
Última actualización: Julio de 2026
La mayor parte de lo que hace seguro a un software se decide mucho antes de cualquier revisión de seguridad. Estas son las prácticas que llevamos a cada proyecto, y con gusto detallamos cualquiera de ellas antes de que te comprometas.
Seguridad dentro del ciclo
No es una etapa al final: el modelado de amenazas y la revisión van en el mismo flujo que la construcción.
Mínimo privilegio por defecto
Acceso nominal, acotado al proyecto, revocado cuando termina.
Entrega lista para HIPAA
Business Associate Agreement, acceso de mínimo necesario y salvaguardas de la Security Rule.
1. Seguridad en el ciclo de desarrollo
La seguridad es parte de cómo se hace el trabajo, no una revisión al final:
- Modelado de amenazas durante la arquitectura, para que los trade-offs queden registrados antes de que exista código.
- Revisión por pares en cada cambio, sin commits directos a ramas protegidas.
- Escaneo de dependencias y de secretos en integración continua; el build falla cuando el hallazgo importa.
- Pruebas automatizadas como puerta de liberación, para que el riesgo lo sostenga el pipeline y no quien esté de guardia.
2. Control de acceso
- Solo cuentas nominales, sin credenciales compartidas entre ingenieros.
- Acceso acotado al proyecto, otorgado por el principio de mínimo necesario y revocado cuando el proyecto o el rol de la persona en él termina.
- Autenticación multifactor en todo lo que la soporte.
- Acceso a producción limitado a quien lo necesita, y registrado.
3. Manejo de datos
- Cifrado en tránsito (TLS) y en reposo, con las claves gestionadas de la plataforma salvo que el cliente exija otra cosa.
- Secretos en un gestor de secretos, nunca en el código fuente ni en archivos de configuración.
- Los datos de producción no se copian a máquinas de desarrollo. Cuando hace falta dato realista para pruebas, se enmascara o se sintetiza.
- Trabajamos dentro de entornos controlados por el cliente siempre que él prefiera ese arreglo.
4. Proyectos con HIPAA
Cuando un proyecto involucra Protected Health Information, ZIONN opera como Business Associate:
- Business Associate Agreement firmado antes de cualquier acceso a PHI.
- Salvaguardas administrativas, físicas y técnicas de la HIPAA Security Rule.
- Acceso de mínimo necesario, por persona nombrada, con traza de auditoría.
- PHI cifrada en tránsito y en reposo, mantenida dentro de los entornos acordados con el cliente.
- Notificación de incidente sin demora injustificada, y apoyo a las obligaciones del propio cliente.
- Subcontratistas vinculados por términos escritos equivalentes.
5. Operación y resiliencia
- Infraestructura como código, para que los entornos sean reproducibles y los cambios revisables.
- Monitoreo y alertas configurados como parte de la entrega, no añadidos después.
- Procedimientos de respaldo y restauración que se prueban de verdad, no solo se configuran.
- Cambios liberados de forma incremental, con una ruta de rollback definida antes del despliegue.
6. Personas
- Obligación de confidencialidad para todos los que tienen acceso a cliente, incluidos subcontratistas.
- Verificación de antecedentes cuando el proyecto o la regulación lo exigen.
- Acceso revisado cuando alguien entra o sale de un proyecto.
7. Qué ponemos por escrito
Antes de que empiece un proyecto, con gusto respondemos tu cuestionario de seguridad, firmamos tu BAA o DPA, aceptamos tus exigencias de acceso y de residencia de datos, y conversamos con tu equipo de seguridad sobre cualquiera de los puntos anteriores.
Si algo de esto no cumple tu estándar, dínoslo. Es mejor tener esa conversación ahora que después de firmar un contrato.
8. Reportar un problema
Si crees haber encontrado una vulnerabilidad en algo que operamos, escribe a security@zionn.io. Incluye suficiente detalle para reproducirla. Confirmaremos la recepción, investigaremos y te mantendremos informado, y no tomaremos acciones contra investigación hecha de buena fe.