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

A.8.4Access to source code

Control read and write access to source code, development tools and software libraries, since these are sensitive assets that shape what your systems do.

El mapeo de un vistazo
A.8.4Access to source codeISO/IEC 27001:2022

A.8.4 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.

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

El control de acceso al código fuente suele vivir dentro de la plataforma que aloja el repositorio, GitHub, GitLab o Bitbucket, en lugar de un documento de política aparte. Una pyme mostrará reglas de protección de ramas y revisiones obligatorias como evidencia, pero la brecha que encuentran los auditores es el propio pipeline de compilación: las credenciales y secretos que permiten al pipeline escribir en producción suelen tener más acceso que cualquier desarrollador individual, y nadie ha revisado quién puede disparar un despliegue o editar directamente la definición de compilación. El acceso al repositorio de un antiguo contratista, otorgado para un solo proyecto, rara vez se revoca el día en que termina el encargo.

Brechas habituales

La protección de ramas del repositorio restringe los push directos, pero las propias credenciales del pipeline de CI/CD pueden saltarse esas restricciones por completo.
El acceso para editar definiciones de compilación y scripts de despliegue no se revisa por separado del acceso al código fuente en sí.
Antiguos contratistas conservan acceso de lectura a repositorios privados meses después de terminado el encargo porque el proceso de baja no cubre el control de código fuente.

Preguntas que hará tu auditor

¿Quién puede hacer push directo al código fuente sin pasar por revisión?
Nadie: la protección de ramas exige un pull request aprobado antes de fusionar código, y el pipeline no puede manipularse porque las definiciones de compilación y los secretos están bloqueados.
¿Se puede modificar el pipeline de despliegue sin que nadie lo note?
No: las definiciones de compilación, los secretos y los pasos de despliegue están técnicamente bloqueados y cada etapa del pipeline aplica su propia barrera de seguridad.
¿Se revisa el acceso al código fuente cuando alguien deja el equipo?
El acceso al repositorio está ligado al proveedor de identidad, así que se revoca automáticamente como parte del proceso de baja.

Dónde lo exige la regulación

El artículo 21 de NIS2 exige gestión de configuración (6.3) y gestión controlada de cambios (6.4) para los sistemas que manejan código fuente y definiciones de compilación.
El ENS mp.sw.2 exige procedimientos controlados de aceptación y puesta en servicio, que se extienden a quién puede modificar el código que llega a producció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.4?»
También vía MCP, gratis con cuenta