ISO/IEC 27001:2022 · destino de mapeo derivado
A.8.25Secure development life cycle
Build security into the whole software development lifecycle, so protection is considered at every stage rather than tested for at the end.
El mapeo de un vistazo
A.8.25Secure development life cycleISO/IEC 27001:2022
A.8.25 queda cubierto por 21 controles del Sekit CSF. +16 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-0115Secure SDLC policy · PolíticaapoyaEsta faceta de política integra requisitos de seguridad en cada etapa del desarrollo, desde el diseño hasta el lanzamiento, para trabajo interno y externalizado, alineándose con la exigencia central de ciclo de vida de A.8.25.RCF-0116Secure SDLC policy · ProcesoapoyaLa faceta de proceso ejecuta las actividades de seguridad acordadas, captura de requisitos, revisión de código, verificación de dependencias, en cada función y lanzamiento, no solo en los grandes.RCF-0117Secure SDLC policy · TécnicaapoyaLa faceta técnica configura el pipeline para que las verificaciones automáticas de seguridad deban pasar antes de que el código llegue a producción, aplicando de forma mecánica la disciplina de ciclo de vida de A.8.25.RCF-0118Threat modeling · PolíticaapoyaLa faceta de política de modelado de amenazas exige documentar las amenazas antes de iniciar el desarrollo de aplicaciones nuevas y cambios importantes, una pieza temprana del ciclo de vida de A.8.25.RCF-0119Threat modeling · ProcesoapoyaLa faceta de proceso del modelado de amenazas ejecuta una sesión de identificación de amenazas por cada cambio calificado y registra lo encontrado y decidido.RCF-0120Threat modeling · TécnicahabilitaLas herramientas que capturan las amenazas identificadas de forma estructurada y las siguen hasta el cierre le dan al paso de modelado de amenazas de A.8.25 un registro duradero en lugar de un taller aislado.RCF-0121Secure code review · PolíticaapoyaEsta faceta de política exige una revisión con enfoque de seguridad en cada cambio de código antes del lanzamiento, una de las prácticas concretas que espera A.8.25.RCF-0122Secure code review · ProcesoapoyaLa faceta de proceso ejecuta una revisión por pares con enfoque de seguridad, realizada por desarrolladores capacitados, en cada cambio de código en lugar de una revisión funcional general.RCF-0125SAST/DAST · ProcesoapoyaLa faceta de proceso ejecuta pruebas de seguridad estáticas y dinámicas como parte rutinaria de cada compilación y lanzamiento, con los hallazgos priorizados hasta su cierre.RCF-0126SAST/DAST · TécnicaapoyaLa faceta técnica integra herramientas SAST y DAST en el pipeline para que un hallazgo crítico detenga automáticamente el lanzamiento.RCF-0130CI/CD hardening · PolíticaapoyaEsta faceta de política fija requisitos de seguridad escritos para el propio pipeline de compilación y despliegue, tratándolo como un sistema de producción que A.8.25 debe proteger.RCF-0131CI/CD hardening · ProcesoapoyaLa faceta de proceso aplica y re-verifica periódicamente los controles de seguridad del pipeline en cada compilación y despliegue en lugar de configurarlos una sola vez.RCF-0132CI/CD hardening · TécnicaapoyaLa faceta técnica bloquea el pipeline para que las definiciones de compilación, los secretos y los pasos de despliegue no puedan manipularse, aplicando una barrera de seguridad en cada etapa.RCF-0133IaC scanning · PolíticaapoyaEsta faceta de política exige que las plantillas de infraestructura como código pasen un escaneo de seguridad antes del despliegue, extendiendo la disciplina de ciclo de vida de A.8.25 a las definiciones de infraestructura.RCF-0134IaC scanning · ProcesoapoyaLa faceta de proceso escanea cada plantilla de infraestructura en busca de errores de configuración como paso rutinario antes de aplicar los cambios.RCF-0139Container security · PolíticarelacionadoLa política de seguridad de contenedores fija estándares escritos para construir y almacenar imágenes de contenedor, un asunto de despliegue contiguo al alcance de SDLC de A.8.25, no interno a él.RCF-0140Container security · ProcesorelacionadoLa faceta de proceso revisa las imágenes de contenedor y las configuraciones en tiempo de ejecución frente al estándar de seguridad con un calendario recurrente.RCF-0143DevSecOps governance · ProcesohabilitaEsta faceta de proceso hace del trabajo de seguridad una parte visible y recurrente de la planificación de sprints, manteniendo las actividades de seguridad de A.8.25 integradas en lugar de añadidas al final.RCF-0365Privacy by design · ProcesorelacionadoEl proceso de privacidad desde el diseño ejecuta una verificación de privacidad como paso rutinario antes del lanzamiento, una disciplina paralela al requisito de seguridad desde el diseño de A.8.25, no la misma.RCF-0366Privacy by design · TécnicarelacionadoLos sistemas usan por defecto la opción que protege la privacidad, campos mínimos, límites de retención, uso compartido por consentimiento explícito, un control en tiempo de diseño que complementa el enfoque de A.8.25 en desarrollo seguro.RCF-0403Release management · PolíticaapoyaEsta faceta de política define cómo se empaquetan, aprueban y lanzan las actualizaciones de software, incluyendo quién autoriza un lanzamiento, la pieza de barrera de lanzamiento del ciclo de vida de A.8.25.
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.
Política de desarrollo seguro
Las reglas que sigue el equipo de desarrollo para crear software de forma segura: requisitos de seguridad, revisión de código y modelado de amenazas.
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
La mayoría de los equipos de desarrollo de pymes tiene una política de desarrollo seguro sobre el papel, pero el ciclo deja de ser seguro en cuanto se aprieta una fecha límite. El escaneo SAST se ejecuta en cada pull request, pero un hallazgo crítico termina marcado como riesgo aceptado en un chat en vez de una excepción registrada. El modelado de amenazas ocurrió una vez, al diseñar el producto, y nunca más al lanzar nuevas funciones. La revisión de código verifica que la función funcione, no que la entrada esté validada o que no haya secretos incrustados. La brecha que más señalan los auditores es el vínculo faltante entre un hallazgo y la prueba de que alguien lo corrigió.
Brechas habituales
Existe una política de desarrollo seguro, pero las revisiones de código rara vez incluyen una lista de verificación de seguridad, así que fallos comunes pasan la revisión por pares sin ser detectados.
El escaneo SAST se ejecuta en el pipeline, pero los hallazgos críticos se silencian o se exceptúan en lugar de bloquear el lanzamiento.
El modelado de amenazas se hizo para el diseño inicial del sistema y nunca más, así que cambios importantes de funciones se lanzan sin una revisión nueva.
Preguntas que hará tu auditor
¿La revisión de seguridad ocurre una sola vez al lanzar o a lo largo de todo el ciclo?
En cada etapa: modelado de amenazas antes de empezar el desarrollo, revisión por pares con enfoque de seguridad en cada cambio de código, y pruebas automatizadas que condicionan cada lanzamiento.
¿Qué impide que una vulnerabilidad crítica llegue a producción?
El pipeline de compilación está configurado para que los hallazgos críticos de SAST y DAST bloqueen automáticamente el lanzamiento hasta que se corrijan.
¿Las definiciones de infraestructura y contenedores se tratan como código que necesita revisión de seguridad?
Sí, las plantillas de infraestructura como código y las imágenes de contenedor se escanean en busca de errores de configuración antes de desplegarse, junto con el código de la aplicación.
¿Quién es responsable de autorizar un lanzamiento a producción?
La política de gestión de lanzamientos nombra al aprobador y los pasos de empaquetado y aprobación que debe pasar cada lanzamiento.
Dónde lo exige la regulación
El artículo 21 de NIS2 exige un ciclo de vida de desarrollo seguro (6.2) con pruebas de seguridad dedicadas en cada etapa (6.5).
El ENS mp.sw.1 exige que el desarrollo de aplicaciones siga una disciplina de ingeniería segura, desde el diseño hasta la aceptación.
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.25?»
También vía MCP, gratis con cuenta