A.8.29
Probar la seguridad antes de publicar nada
Control Tecnológico
Qué significa
Defina y ejecute pruebas de seguridad durante el desarrollo y en la aceptación.
Cómo lo verifica StandardOS
Conectado en solo lectura, según un calendario. Una comprobación superada mantiene fresca una entrada de evidencia; una fallida la deja caducar, para que una regresión salga a la luz en lugar de esperar a la auditoría. Cada integración, y qué puede ver cada credencial.
- GitHubStandardOS lee si la rama predeterminada exige comprobaciones de estado superadas antes de una fusión, para que las pruebas se ejecuten antes de que algo se despliegue y no después.
- GitHubStandardOS lee si el análisis de código o una puerta de revisión forma parte de lo que protege la rama predeterminada.
- AWSStandardOS lee si ECR analiza las imágenes antes de desplegarlas.
- SnykStandardOS lee qué proyectos activos tienen desactivada la prueba de pull requests, de modo que una dependencia vulnerable se notifica tras la fusión en lugar de detenerse antes.
Riesgos que trata este control
Del registro de riesgos inicial que StandardOS propone en la configuración. Usted conserva, edita o elimina cada uno; estos son los que citan A.8.29 como tratamiento.
- Código escrito por un proveedor llega a producción sin revisiónAplicación
Qué preguntan los clientes sobre este control
Los cuestionarios de seguridad no usan números de control. Estas son las preguntas, tal como las plantean los clientes, que desembocan en A.8.29. Cada una se responde a partir de los mismos cuatro registros: el estado en la DdA, la política aprobada, evidencia fechada y una comprobación en vivo. El mapa completo de los treinta temas.
¿Siguen un ciclo de desarrollo seguro con revisión de código y gestión de cambios?
Desarrollo seguro, revisión de código, gestión de cambios, CI/CD · también A.8.25, A.8.32
Dónde encaja esto en NIS2
A.8.29 es parte de lo que exige el artículo 21, apartado 2, letra e), Security in network and information systems acquisition, development and maintenance
. Implementarlo una vez cuenta para ambos, y esa es toda la razón de que exista la correspondencia con NIS2.
Controles que trabajan con este
Aparecen juntos en el mismo riesgo o la misma política, así que normalmente también se implementan juntos.
- A.8.30Supervisar la seguridad cuando otros construyen para usted
- A.5.19Gestionar el riesgo que traen los proveedores
- A.8.25Seguridad a lo largo de cómo se construye el software
- A.8.26Decidir qué debe hacer una aplicación con seguridad
- A.8.27Diseñar sistemas sobre principios seguros
- A.8.28Escribir código que resista los ataques
- A.8.31Mantener aparte los entornos de construcción, prueba y producción
- A.8.33Usar datos seguros al probar
Lo que cuesta la certificación ISO 27001. Los días de auditoría están fijados por ISO/IEC 27006, así que puede calcular su propia cifra. O vea qué cláusulas cubre StandardOS, incluidas las que no cubre.
Lo que StandardOS tiene listo para A.8.29 el día de la auditoría
Una decisión de aplicabilidad y un borrador de justificación, rellenados de antemano a partir de un perfil de siete preguntas y marcados como borrador hasta que los haga suyos. Un estado de implementación. Entradas de evidencia fechadas que caducan, para que la exportación que lee su auditor muestre qué era cierto y cuándo, archivado bajo esta referencia.