ISO/IEC 27001:2022 · destino de mapeo derivado
A.8.29Security testing in development and acceptance
Test software for security during development and before it is accepted into production, so weaknesses are caught before release.
El mapeo de un vistazo
A.8.29Security testing in development and acceptanceISO/IEC 27001:2022
A.8.29 queda cubierto por 14 controles del Sekit CSF. +9 más en la tabla de abajo. Abrir en el grafo completo →
Mapeado desde el Sekit CSF
Los controles de Sekit que cubren este requisito, lente a lente.
RCF-0031Control testing program · PolíticaapoyaEsta política de Sekit define qué controles se prueban, con qué frecuencia y por quién, dando a las pruebas de seguridad antes del lanzamiento la estructura planificada que exige este control ISO.RCF-0033Control testing program · TécnicaapoyaEl control técnico de Sekit ejecuta herramientas automatizadas como escaneos programados de forma continua, extendiendo el rigor de pruebas que exige este control ISO más allá de una comprobación única antes del lanzamiento.RCF-0117Secure SDLC policy · TécnicaapoyaEste control técnico de Sekit condiciona el pipeline a que las comprobaciones de seguridad automatizadas pasen antes de producción, el mecanismo de aplicación que exige este control ISO para las pruebas previas a la aceptación.RCF-0121Secure code review · PolíticaapoyaLa política de Sekit exige una revisión con foco en seguridad antes del lanzamiento, una de las actividades de prueba que exige este control ISO durante el desarrollo y antes de la aceptación.RCF-0122Secure code review · ProcesoapoyaEste control de proceso de Sekit ejecuta una revisión por pares con foco en seguridad en cada cambio, la capa de pruebas humana que exige este control ISO junto a los escaneos automatizados.RCF-0123Secure code review · TécnicaapoyaEl control técnico de Sekit integra un escáner automatizado en el flujo de trabajo para detectar fallas en cada cambio, uno de los métodos de prueba automatizados que exige este control ISO.RCF-0124SAST/DAST · PolíticaapoyaEsta política de Sekit documenta el requisito de pruebas estáticas y dinámicas automatizadas antes del lanzamiento, uno de los métodos de prueba que exige este control ISO junto a la revisión y las comprobaciones de aceptación.RCF-0125SAST/DAST · ProcesoapoyaEl control de proceso de Sekit ejecuta pruebas estáticas y dinámicas como parte rutinaria de cada compilación, aplicando las pruebas que exige este control ISO a cada lanzamiento y no de forma ocasional.RCF-0126SAST/DAST · TécnicaapoyaEste control técnico de Sekit integra las herramientas de prueba en el pipeline para que un hallazgo crítico detenga el lanzamiento, la puerta aplicada que espera este control ISO.RCF-0129Dependency/SBOM management · TécnicaapoyaEl control técnico de Sekit ejecuta escaneo automatizado de dependencias que marca o bloquea compilaciones con componentes con vulnerabilidades conocidas, una prueba específica que exige este control ISO antes de la aceptación.RCF-0135IaC scanning · TécnicaapoyaEste control técnico de Sekit bloquea el despliegue de las plantillas de infraestructura que no pasan el escaneo automatizado, cerrando una vía a producción que evita por completo las pruebas a nivel de aplicación.RCF-0137API security · ProcesoapoyaEl control de proceso de Sekit integra la seguridad en el diseño de la API, las pruebas antes del lanzamiento y el monitoreo en vivo, dando a los endpoints un escrutinio continuo que un escaneo único antes del lanzamiento por sí solo no alcanzaría.RCF-0141Container security · TécnicaapoyaEste control técnico de Sekit escanea las imágenes de contenedor antes del despliegue y sigue aplicando restricciones mientras los contenedores están en ejecución, detectando desviaciones que un escaneo previo al lanzamiento por sí solo no vería.RCF-0404Release management · ProcesoapoyaEste control de proceso de Sekit hace pasar cada lanzamiento por pruebas y aprobación antes del despliegue, con registros conservados, la disciplina de aceptación que exige este control ISO antes de que el software llegue a producción.
Correspondencias en NIST CSF 2.0
Alcanzadas a través de los controles del Sekit CSF que ambos mapean: un mapeo, no una equivalencia formal.
Correspondencias en ISO/IEC 42001:2023 — Annex A
Correspondencias en Cyber Essentials
Evidencia que demuestra este control
Lo que pide un auditor, o el motor de evidencias de Sekit.
Evidencia de pruebas de seguridad de aplicaciones
La prueba de que el código y las aplicaciones se analizan automáticamente en busca de fallos (SAST/DAST), incluidas las dependencias y las APIs.
Seguridad de la cadena de construcción y despliegue (CI/CD)
Los controles de seguridad en el proceso automatizado de construir y desplegar software, incluidos contenedores e infraestructura como código.
Del catálogo de evidencias de Sekit
En la práctica
Las pruebas de seguridad antes del lanzamiento combinan comprobaciones automatizadas y humanas: escaneos estáticos y dinámicos en cada compilación, escaneo de dependencias que marca componentes con vulnerabilidades conocidas, y una revisión por pares con foco en seguridad que detecta lo que las herramientas pasan por alto. Los auditores buscan en la configuración del pipeline puertas de bloqueo reales: un hallazgo crítico bloquea el lanzamiento, y los hallazgos se siguen hasta el cierre, no se descartan. La brecha más frecuente es un escaneo de dependencias que reporta correctamente, pero nadie es responsable de priorizar las alertas, así que una biblioteca con vulnerabilidad conocida se lanza una y otra vez mientras el informe del escaneo prueba técnicamente que el control existe.
Brechas habituales
El escaneo de dependencias marca correctamente una vulnerabilidad crítica en una biblioteca compartida, pero nadie ha priorizado la alerta ni le ha asignado un responsable.
El análisis estático se ejecuta en CI pero sus resultados son solo informativos, así que las compilaciones con hallazgos de severidad alta aun así se despliegan a producción.
Las imágenes de contenedor se escanean antes del despliegue, pero no se aplican restricciones en tiempo de ejecución, así que un contenedor con una vulnerabilidad conocida se puede iniciar manualmente.
Preguntas que hará tu auditor
¿Un hallazgo crítico de sus pruebas de seguridad bloquea un lanzamiento, o solo se registra?
Las herramientas de prueba de seguridad están integradas en el pipeline, así que un hallazgo crítico detiene el lanzamiento automáticamente antes de que llegue a producción.
¿Cómo detectan dependencias de terceros vulnerables antes de que se lancen?
El escaneo automatizado de dependencias marca o bloquea las compilaciones que contienen componentes con vulnerabilidades conocidas, como se refleja en la evidencia de pruebas de seguridad de aplicaciones.
¿Todo cambio de código lo revisa una persona, además de ser escaneado por las herramientas?
Sí, cada cambio recibe una revisión por pares con foco en seguridad de un desarrollador capacitado, además de las pruebas estáticas y dinámicas automatizadas.
¿Cómo se aprueban los lanzamientos antes del despliegue?
Cada lanzamiento pasa por pruebas y aprobación antes del despliegue, en la práctica y con registros, en vez de desplegarse directamente desde la máquina de un desarrollador.
Dónde lo exige la regulación
NIS2 art. 6.5 exige pruebas de seguridad antes de que los sistemas entren en servicio, y ENS mp.sw.2 exige aceptación formal y puesta en servicio solo después de completar esas pruebas.
Controles relacionados
Vía el tema compartido del Sekit CSF, no el índice del propio marco.
Pregúntale a Sekura: «¿Qué evidencia demuestra A.8.29?»
También vía MCP, gratis con cuenta