Seguridad en SecureCodingHub

Todos los datos en reposo se cifran con AES-256. Los volúmenes de base de datos, las copias de seguridad y el almacenamiento de archivos están cifrados con claves gestionadas a través de un servicio dedicado de gestión de claves.

Todas las comunicaciones entre los clientes y nuestros servidores utilizan TLS 1.3. Aplicamos HTTPS en todos los endpoints con cabeceras HSTS y supervisión de transparencia de certificados.

Los datos de los clientes están aislados lógicamente en la capa de aplicación. Los datos de cada organización están segregados con controles de acceso estrictos, lo que evita cualquier filtración de datos entre inquilinos.

Los clientes empresariales pueden integrarse con su proveedor de identidad mediante inicio de sesión único con SAML 2.0. Admitimos los principales IdP, incluidos Azure AD, Okta y OneLogin.

La compatibilidad con MFA añade una capa adicional de seguridad a las cuentas de usuario. Admitimos aplicaciones autenticadoras basadas en TOTP para la verificación del segundo factor.

Las sesiones se aseguran criptográficamente con tokens de corta duración, expiración automática y capacidad de revocación. Las sesiones inactivas se terminan tras un tiempo de espera configurable.

Realizamos pruebas de penetración periódicas con terceros sobre nuestra infraestructura y aplicación. Los hallazgos se clasifican, priorizan y subsanan en función de su gravedad.

Nuestra canalización de CI/CD incluye análisis automatizado de dependencias y análisis de composición de software. Las vulnerabilidades conocidas en bibliotecas de terceros se señalan y se atajan con prontitud.

Mantenemos un programa de divulgación responsable para investigadores de seguridad. Si descubre una vulnerabilidad, le rogamos que nos la comunique y colaboraremos con usted para resolverla.

Recogemos únicamente los datos necesarios para prestar nuestros servicios. No recopilamos información personal innecesaria y no vendemos los datos de los usuarios a terceros.

Los datos se conservan únicamente durante el tiempo necesario para cumplir los fines para los que fueron recogidos. Cuando los datos ya no son necesarios, se eliminan o anonimizan de forma segura.

Los usuarios pueden solicitar la eliminación de su cuenta y los datos asociados en cualquier momento. Tramitamos las solicitudes de supresión con prontitud y confirmamos su finalización en un plazo de 30 días.

Todo cambio que se despliega en producción pasa por una revisión mediante pull request con, al menos, un ingeniero ajeno a la pareja de trabajo del autor. La CI ejecuta comprobaciones unitarias, de integración y de seguridad en cada push. Los despliegues a producción atraviesan un paso de aprobación independiente. Los cambios de emergencia siguen un procedimiento documentado de break-glass con revisión retrospectiva esa misma semana. Los cambios de infraestructura se gestionan como código y se revisan con el mismo flujo que el código de la aplicación.

El análisis de composición de software se ejecuta en cada pull request y, además, en una planificación nocturna contra la rama principal. Las alertas de gravedad crítica y alta activan un aviso al ingeniero de guardia con una ventana objetivo de subsanación medida en días, no en semanas. Las alertas medias y bajas se agrupan en una revisión semanal. Las imágenes base de los contenedores se reconstruyen con una cadencia fija para que los parches transitivos del sistema operativo lleguen a producción sin necesidad de cambios en la aplicación.

El plan de respuesta a incidentes define cuatro niveles de gravedad, las rutas de escalado y un único punto de responsabilidad por incidente. El primer interviniente se encarga de la contención y de la comunicación con el cliente, mientras que un investigador dedicado sigue la pista técnica. Las revisiones posteriores al incidente son sin culpa y dan lugar a un registro escrito con acciones cuyo seguimiento se mantiene hasta su cierre. El plan se pone a prueba al menos dos veces al año frente a escenarios guionizados, de modo que la memoria muscular exista antes de que se produzca un incidente real.

Si su equipo de seguridad detecta algo durante un pentest contractual, una revisión interna o el uso habitual del producto, comuníquelo directamente a nuestro equipo de seguridad en lugar de discutirlo públicamente primero. Acusaremos recibo en un plazo de dos días laborables, le facilitaremos un identificador de seguimiento y le mantendremos informado del estado hasta que se cierre el problema. Tratamos la divulgación coordinada como una colaboración.

Los administradores del cliente controlan la asignación de roles dentro de su inquilino. El principio que recomendamos es el mismo que aplicamos internamente: asignar el rol más restringido que permita al usuario hacer su trabajo y revisar las asignaciones con un ciclo regular. El acceso administrativo, en particular, debe limitarse a un pequeño grupo nominado, y ese grupo debe auditarse a medida que las personas cambian de rol dentro de su organización.

Cuando una persona abandona su organización, su desactivación en el proveedor de identidad debe propagarse a través de SCIM para revocar el acceso a la plataforma. Recomendamos encarecidamente el aprovisionamiento basado en SCIM frente a la gestión manual de usuarios para cualquier organización de más de treinta puestos. Si no puede adoptar SCIM por ahora, una lista de comprobación de off-boarding a nivel de cuenta con un responsable designado es el siguiente mejor control.

Una página de estado que recoge la disponibilidad de la plataforma y los incidentes de servicio degradado. Una lista de subencargados. El acuerdo vigente de tratamiento de datos. Esta propia página de seguridad. Una vez completado SOC 2 Type II, el informe estará disponible bajo NDA, previa solicitud, a través de su contacto de cuenta. Las actualizaciones materiales de las políticas que afecten a los clientes se anuncian a través de su contacto de cuenta, en lugar de quedar enterradas en un changelog.

Los diagramas de arquitectura de red interna, los flujos detallados de autenticación, las herramientas concretas que utiliza nuestro equipo de seguridad, los calendarios de rotación de claves al nivel de claves individuales y los nombres y funciones del personal del equipo de seguridad. Cualquiera de estos puntos puede revisarse bajo NDA cuando la conversación lo requiera —por ejemplo, durante una revisión de seguridad liderada por compras—, pero no procede publicarlos en una página pública. Publicarlos rebajaría el coste de un ataque dirigido sin aportar a ningún cliente un beneficio real.