ISO 27001:2022, A.8.25 a A.8.28: los cuatro controles de desarrollo y qué evidencia cada uno
Ciclo de vida de desarrollo seguro, requisitos de seguridad de las aplicaciones, arquitectura segura, codificación segura: qué exigen los cuatro controles del anexo A, cuáles de ellos evidencia con fecha un escaneo de código continuo, cuáles no puede evidenciar, y dónde A.8.8 los atraviesa todos.
Por qué la versión de 2022 es más precisa aquí
En la versión anterior, los requisitos de desarrollo seguro estaban repartidos en una sección más amplia. La revisión de 2022 los reagrupó en el anexo A bajo el tema tecnológico y les dio números propios. Para una pyme eso tiene una consecuencia práctica: el auditor recorre los números uno a uno y espera una prueba distinta para cada uno. Una declaración general de que se desarrolla de forma segura no cubre ninguno de los cuatro.
Nuestra página sobre seguridad del código y cumplimiento recoge la correspondencia en versión corta. Aquí va la versión larga, control por control, con la indicación honesta de qué aporta un escaneo y qué no.
A.8.25: ciclo de vida de desarrollo seguro
El control exige que se establezcan y apliquen reglas para el desarrollo seguro de software y sistemas. La segunda mitad es la difícil. Las reglas se escriben rápido en un documento; que se aplican hay que demostrarlo. Un escaneo que se ejecuta en cada commit y evalúa cada cambio en el contexto de la base de código antes de que el código siga adelante es una prueba precisamente de esa segunda mitad: la regla actúa en el proceso, no solo en el informe anual.
Lo que el escaneo no sustituye es la regla en sí. El documento que fija cómo se desarrolla tiene que existir. El escaneo evidencia su aplicación, no su existencia.
A.8.26: requisitos de seguridad de las aplicaciones
Aquí se trata de identificar, especificar y aprobar los requisitos de seguridad al desarrollar o adquirir una aplicación. Eso ocurre antes de la primera línea de código, en pliegos, tickets y aprobaciones. Un escáner no ve nada de eso. Puede comprobar si una entrada se valida, pero no si alguien decidió antes que debía validarse.
La evidencia para A.8.26 es, por tanto, un documento: los requisitos especificados y su aprobación. Quien presenta aquí un informe de escaneo evidencia el control equivocado.
A.8.27: arquitectura de sistemas segura y principios de ingeniería
Este control exige que se establezcan, documenten y apliquen en cada desarrollo principios de arquitectura segura. También eso es una cuestión de diseño. Cómo se separan los servicios, dónde están los límites de confianza, qué datos se procesan dónde: eso está en documentos de arquitectura y revisiones, no en el código fuente. Un escáner encuentra una contraseña escrita en el código, pero no encuentra que un componente nunca debió, por diseño, estar expuesto a la red.
Para A.8.27, la evidencia son las revisiones de arquitectura. Un test de penetración puede complementarlas, porque comprueba el sistema en funcionamiento como un todo desde la perspectiva de un atacante.
A.8.28: codificación segura
El control exige que se apliquen principios de codificación segura. Aquí el escaneo está en casa. Entradas sin validar, llamadas peligrosas al sistema, controles de acceso ausentes, credenciales escritas en el código: son infracciones de los principios de codificación que tienen un patrón, y un escaneo en cada commit las detecta en cuanto aparecen. Cada hallazgo, su clasificación, la corrección y la fecha forman juntos la prueba de que los principios no solo se adoptan, sino que se hacen cumplir.
La prueba tiene un límite superior, y conviene que el auditor lo oiga primero de vosotros: una regla sobre quién puede aprobar qué factura no se expresa como patrón de código, así que el escaneo nunca señalará una infracción de ella, y una herramienta que busca patrones a veces marca cosas que en vuestra instalación concreta resultan inofensivas. La criba humana entre el resultado en bruto y el hallazgo documentado es lo que mantiene ambos problemas fuera del expediente.
A.8.8: gestión de vulnerabilidades técnicas, de forma transversal
A.8.8 no es un control de desarrollo, pero está por encima de los cuatro: hay que obtener información sobre las vulnerabilidades técnicas de los sistemas utilizados, evaluar la exposición y adoptar medidas. Para el propio código eso significa, sobre todo, las dependencias de código abierto. El escaneo las compara de forma continua con las vulnerabilidades conocidas, y cuando se actualiza una biblioteca, el hallazgo, la medida y la fecha van al expediente. Es la prueba más sencilla de toda la lista, y la que con más frecuencia falta.
La puerta de entrada es el análisis de código gratuito: conexión, escaneo del inventario en secretos, dependencias y patrones inseguros, hallazgo priorizado.
Preguntas frecuentes
¿Evidencia un escaneo de código los cuatro controles de desarrollo?
No. Evidencia directamente y con fecha A.8.28 y la parte de aplicación de A.8.25. A.8.26 y A.8.27 tratan de requisitos y arquitectura, decisiones tomadas antes del código, y para eso hacen falta documentos y revisiones.
¿Sustituye el escaneo al SGSI o a la certificación?
No, y el orden es el inverso: el SGSI decide qué controles os aplican, la evaluación de riesgos hasta dónde, y la certificación comprueba ambas cosas. El escaneo solo suministra los hallazgos fechados para dos de esos controles y para A.8.8. Alimenta el expediente; no es el expediente.
Todavía no hemos implantado la norma. ¿Merece la pena el escaneo igualmente?
Sí, porque los mismos hallazgos cuentan también según el artículo 30 del BSIG si os aplica NIS2, y porque las evidencias que hoy nacen con fecha no habrá que recopilarlas después. El escaneo es la herramienta que tenéis primero, no la última.