SekitCrosswalk
ISO/IEC 27001:2022 · destino de mapeo derivado

A.8.28Secure coding

Apply secure coding practices so common, avoidable vulnerabilities are not written into your software in the first place.

El mapeo de un vistazo

A.8.28 queda cubierto por 1 control del Sekit CSF. Abrir en el grafo completo

Mapeado desde el Sekit CSF

Los controles de Sekit que cubren este requisito, lente a lente.

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.

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.
Del catálogo de evidencias de Sekit

En la práctica

La codificación segura en la práctica significa un escáner automatizado integrado en el flujo de desarrollo, que detecta fallas comunes como inyección o control de acceso roto antes de que un revisor humano vea el cambio. Los auditores quieren ver el escáner corriendo en cada pull request, no configurado una vez y luego ignorado mientras los hallazgos se acumulan sin revisar. El fallo que se repite es un escáner que sí marca problemas reales, pero los hallazgos quedan en una cola que nadie prioriza, así que el control existe en papel mientras la misma clase de vulnerabilidad sigue llegando a producción lanzamiento tras lanzamiento.

Brechas habituales

El escáner de seguridad de código está configurado pero sus hallazgos no se priorizan, así que varias clases de vulnerabilidad conocidas han llegado a producción repetidamente.
Los estándares de codificación segura existen para la aplicación principal pero no se aplican a los scripts y herramientas internas construidos por el mismo equipo.
El escáner corre en los pull requests hacia la rama principal pero no está integrado en las ramas de funcionalidades, así que los problemas surgen tarde en el ciclo de revisión.

Preguntas que hará tu auditor

¿Cómo detectan fallas comunes de codificación como la inyección antes del lanzamiento?
Un escáner automatizado de seguridad de código está integrado en el flujo de desarrollo, así que cada cambio se revisa sin depender del esfuerzo manual.
¿Qué pasa cuando el escáner encuentra una vulnerabilidad?
El hallazgo se prioriza como parte del flujo de trabajo, y la evidencia de pruebas de seguridad de aplicaciones muestra los resultados de escaneo con seguimiento hasta su resolución en vez de quedar abiertos.
¿La codificación segura cubre las herramientas internas, o solo la aplicación principal?
El mismo escáner y estándar de codificación aplican dondequiera que el equipo de desarrollo escriba código, así que las herramientas internas pasan por la misma comprobación que el software de cara al cliente.

Dónde lo exige la regulación

NIS2 art. 6.5 exige pruebas de seguridad para detectar fallas de codificación, y ENS mp.sw.1 exige prácticas de desarrollo de aplicaciones seguras, ambas respaldadas directamente por el escaneo automatizado.

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.28?»
También vía MCP, gratis con cuenta