La mayoría de los equipos de desarrollo con los que trabajamos descubren que existe algo llamado «desarrollo seguro» el día que reciben el pliego de una licitación pública, el cuestionario de proveedores de un cliente grande o el informe de una auditoría de certificación. Hasta ese momento la seguridad era una preocupación del equipo de sistemas: firewalls, copias de seguridad, antivirus. De repente alguien pregunta por el estándar de codificación segura, por las pruebas de seguridad en el ciclo de vida, por la separación de entornos y por quién revisa el código antes de que llegue a producción.
El desarrollo seguro es una pieza más dentro de la seguridad informática de tu organización.
Ese momento suele ser incómodo porque las respuestas no se improvisan. Tanto la ISO 27001 como el Esquema Nacional de Seguridad (ENS) dedican controles específicos al software que una organización desarrolla o encarga, y no se conforman con buenas intenciones: piden procesos definidos, evidencias y revisiones periódicas. Un auditor no valora si tu código es elegante; valora si puedes demostrar cómo se decide, se escribe, se prueba y se despliega.
Este artículo explica qué exigen exactamente ambos marcos en materia de desarrollo seguro ISO 27001 y ENS, con ejemplos concretos de fallos que aparecen en auditoría, cómo se detectan, por qué el listón sube cuando trabajas para el sector público o para grandes empresas, y por qué la auditoría de seguridad del código funciona mucho mejor como rutina periódica que como examen final.
1. Qué es el desarrollo seguro ISO 27001 y cómo lo aborda el ENS
Conviene empezar deshaciendo un malentendido habitual: ninguno de los dos marcos te dice cómo programar. No hay un anexo que prohíba una función concreta ni que imponga un framework. Lo que ambos exigen es que la seguridad esté incorporada al proceso de construcción del software, en lugar de añadida al final como una capa de pintura.
En la norma ISO 27001 y su proceso de certificación, el bloque que define el desarrollo seguro ISO 27001 vive en los controles tecnológicos del Anexo A de la versión 2022. Los que casi siempre acaban en el alcance de un equipo de desarrollo son:
- A.8.25 — Ciclo de vida de desarrollo seguro. Debe existir un ciclo de vida definido, con la seguridad presente desde el diseño y no solo antes de publicar.
- A.8.26 — Requisitos de seguridad de las aplicaciones. Los requisitos de seguridad se identifican y se especifican como cualquier otro requisito funcional.
- A.8.27 y A.8.28 — Arquitectura segura y codificación segura. Principios de arquitectura documentados y un estándar de codificación que el equipo conoce y aplica.
- A.8.29 — Pruebas de seguridad. Pruebas de seguridad durante el desarrollo y la aceptación, no solo pruebas funcionales.
- A.8.30 — Desarrollo externalizado. Si subcontratas, supervisas y verificas lo que te entregan.
- A.8.31 y A.8.32 — Separación de entornos y gestión de cambios. Desarrollo, pruebas y producción separados, con cambios controlados y trazables.
- A.8.33 — Datos de prueba. Nada de clonar producción con datos reales a un portátil.
El ENS, regulado por el Real Decreto 311/2022, llega al mismo sitio por otro camino. Sus medidas están organizadas en marcos y familias, y el software aparece sobre todo en mp.sw (protección de las aplicaciones informáticas), con apoyo de mp.info para el tratamiento de la información, op.exp para explotación y gestión de cambios, y op.mon para monitorización. La medida mp.sw se desdobla en dos ideas muy reconocibles: desarrollo de aplicaciones (con metodología, separación de entornos y no usar datos reales en pruebas) y aceptación y puesta en servicio (con pruebas de seguridad previas al paso a producción). Si quieres el contexto completo del marco, lo desarrollamos en la guía del Esquema Nacional de Seguridad.
La diferencia práctica más importante entre ambos: la ISO 27001 es voluntaria y tú defines el alcance; el ENS es obligatorio para el sector público español y, por extensión contractual, para sus proveedores tecnológicos. Y el nivel exigido (básico, medio o alto) no lo eliges tú, sino que sale de la categorización del sistema.
2. Ejemplos reales: qué falla y cómo se detecta
La teoría del desarrollo seguro ISO 27001 se entiende mejor con los hallazgos que se repiten. Estos cinco aparecen en prácticamente todas las auditorías de código que hacemos, y cada uno se detecta con una técnica distinta.
2.1 Inyección SQL por concatenación de cadenas
Sigue siendo el clásico. Un endpoint de búsqueda o de filtrado que construye la consulta pegando texto:
// Vulnerable
$sql = "SELECT * FROM pedidos WHERE cliente_id = " . $_GET['id'];
$db->query($sql);
// Correcto: consulta preparada
$stmt = $db->prepare('SELECT * FROM pedidos WHERE cliente_id = ?');
$stmt->execute([$_GET['id']]);Cómo se detecta: análisis estático (SAST). Cualquier herramienta moderna marca la concatenación de una variable de entrada en una consulta. Es el tipo de fallo que no debería llegar nunca a una revisión manual porque una máquina lo encuentra en segundos. Lo tratamos con más detalle en nuestra guía del OWASP Top 10 y las vulnerabilidades web críticas.
2.2 Autorización rota (IDOR)
Un endpoint comprueba que el usuario ha iniciado sesión, pero no que ese recurso concreto sea suyo:
// Vulnerable: autenticado, pero sin comprobar propiedad
GET /api/facturas/48213 → devuelve la factura de otro cliente
// Correcto
$factura = Factura::where('id', $id)
->where('empresa_id', $usuario->empresa_id)
->firstOrFail();Cómo se detecta: aquí las herramientas automáticas fallan casi siempre, porque la máquina no sabe qué recurso debería ver cada usuario. Se detecta con revisión manual de código y con pentest autenticado usando dos cuentas distintas. Es el ejemplo perfecto de por qué el escaneo automático no sustituye a la auditoría.
2.3 Secretos en el repositorio
Claves de API, contraseñas de base de datos o tokens de la pasarela de pago commiteados «temporalmente». El problema no es solo el fichero actual: el historial de Git conserva el secreto aunque lo borres después.
Cómo se detecta: escaneo de secretos en el repositorio y en el historial completo, ejecutado como hook y en el pipeline de integración continua. La remediación siempre incluye rotar la credencial: borrarla del código no la invalida.
2.4 Dependencias vulnerables
Entre el 70% y el 80% del código que se ejecuta en una aplicación moderna no lo ha escrito tu equipo. Una librería de tratamiento de imágenes desactualizada, un paquete de serialización con un CVE conocido, un módulo del ecommerce abandonado por su autor.
Cómo se detecta: análisis de composición de software (SCA) contra las bases de datos de vulnerabilidades, ejecutado a diario y no solo cuando alguien se acuerda. Este control cubre a la vez A.8.28 de la ISO y buena parte de mp.sw del ENS.
2.5 Datos reales en entornos de prueba
Es el hallazgo que más incomoda en las auditorías con enfoque ENS y en las revisiones de cumplimiento del RGPD: una copia de la base de datos de producción, con nombres, direcciones y pedidos reales, en un servidor de staging sin parches y con acceso abierto. La ISO lo cubre en A.8.33 y el ENS lo menciona explícitamente en el desarrollo de aplicaciones.
Cómo se detecta: revisión de procedimientos y del proceso de aprovisionamiento de entornos. No es un fallo de código, es un fallo de proceso, y por eso las herramientas nunca lo encuentran.
3. Detección: las cinco capas del desarrollo seguro ISO 27001
Un error frecuente al implantar el desarrollo seguro ISO 27001 es comprar una herramienta cara y dar el problema por resuelto. La detección eficaz combina capas con costes y cadencias muy distintas.
3.1 SAST: análisis estático del código
Lee el código fuente sin ejecutarlo y busca patrones peligrosos. Es rápido, barato y se integra en cada pull request. Su defecto conocido son los falsos positivos: si no se afina, el equipo aprende a ignorar las alertas, que es peor que no tenerlas. La regla práctica es empezar bloqueando solo los hallazgos de severidad crítica y alta, e ir ampliando.
3.2 SCA: dependencias de terceros
Compara tu árbol de dependencias con los CVE publicados. Debe correr a diario, porque una librería que ayer era segura hoy puede tener un exploit público. Conviene generar y conservar el inventario de componentes (SBOM): cuando aparece una vulnerabilidad grave en una librería muy extendida, la diferencia entre responder en una hora o en tres días es tener ese inventario.
3.3 DAST: análisis dinámico
Ataca la aplicación en ejecución en un entorno de preproducción. Encuentra lo que solo existe en tiempo de ejecución: cabeceras de seguridad ausentes, gestión de sesiones débil, mensajes de error que revelan la pila tecnológica, endpoints que no aparecían en el código revisado.
3.4 Revisión manual de código
Un ingeniero leyendo la lógica de negocio. Es la única capa que encuentra autorización rota, condiciones de carrera en el flujo de pago, validaciones que se hacen solo en el cliente o reglas de negocio que se pueden esquivar llamando a los endpoints en otro orden. Es cara en tiempo, así que se reserva para los módulos críticos: autenticación, pagos, permisos y todo lo que toque datos personales.
3.5 Pentest
Una persona atacando el sistema completo, encadenando fallos que individualmente parecían de riesgo bajo. Un directorio listable, más un nombre de usuario filtrado en un mensaje de error, más una política de contraseñas débil, más un panel de administración accesible, suman un compromiso total aunque cada pieza tenga severidad media. Si nunca has hecho uno, el hacking ético aplicado a empresas explica bien qué esperar del proceso.
¿Tu código pasaría una auditoría de ISO 27001 o del ENS?
En Keliam revisamos el ciclo de desarrollo completo: estándar de codificación, pipeline de detección, separación de entornos y evidencias. Te entregamos los hallazgos priorizados por riesgo real y un plan de remediación que tu equipo puede ejecutar.
4. Por qué el listón sube en entornos públicos y grandes empresas
Si desarrollas software para el sector público, el desarrollo seguro ISO 27001 y el ENS dejan de ser una recomendación. La categorización del sistema determina el nivel exigido y ese nivel viaja por la cadena de suministro: si prestas un servicio que soporta un sistema de categoría media, tu parte tiene que cumplir a ese nivel. En la práctica esto significa tres cosas que sorprenden a los equipos pequeños.
Primera: te lo van a pedir por escrito antes de firmar. Los pliegos incluyen requisitos de seguridad en el desarrollo, y el órgano de contratación puede exigir la Certificación de Conformidad con el ENS o declaraciones concretas. Lo tratamos desde el lado comercial en la guía sobre qué exige el ENS a proveedores tecnológicos.
Segunda: tendrás que demostrarlo, no solo afirmarlo. Un auditor pedirá el estándar de codificación firmado, actas de revisión de código, informes de las herramientas con fechas, el registro de cambios y la evidencia de que las pruebas de seguridad se ejecutaron antes de cada paso a producción. Es la diferencia entre «tenemos SAST» y «aquí están los 18 informes de los últimos 12 meses con sus hallazgos cerrados».
Tercera: el incumplimiento tiene consecuencias contractuales. Una brecha en un sistema público no acaba en una conversación técnica: acaba en notificación al CCN-CERT, en revisión del contrato y, cada vez más, en penalizaciones. Si además manejas datos personales, se suma el régimen del RGPD y, según el sector, las obligaciones de NIS2.
En las grandes empresas privadas el mecanismo es equivalente aunque el vocabulario cambie: el cuestionario de homologación de proveedores hace las mismas preguntas, y una respuesta floja te deja fuera del proceso de compra sin más explicación. Si estás valorando por dónde arrancar, el artículo sobre por dónde empezar en ciberseguridad empresarial ayuda a ordenar prioridades antes de meterse en una certificación.
5. La auditoría de código periódica: el desarrollo seguro ISO 27001 como rutina
Aquí está, en nuestra experiencia, el cambio de mentalidad que más resultados da. La mayoría de organizaciones tratan la auditoría de seguridad como un evento: llega la fecha, se contrata, se recibe un PDF de ochenta páginas, se corrigen las tres cosas más llamativas y se archiva el resto hasta el año siguiente. Ese modelo falla por una razón sencilla: el código cambia todas las semanas y el informe envejece desde el día que se entrega.
5.1 Qué cambia con un ciclo periódico
Cuando la revisión es continua, el coste por hallazgo se desploma. Un fallo detectado en el pull request cuesta minutos; el mismo fallo detectado en un pentest anual cuesta reabrir un módulo que nadie ha tocado en meses, con el desarrollador original ya en otro proyecto. Y detectado tras un incidente cuesta, además, la notificación, la investigación forense y la confianza del cliente.
5.2 Una cadencia que funciona
Para un equipo de desarrollo mediano, el reparto que mejor funciona es este:
- En cada pull request: SAST y escaneo de secretos, bloqueando solo severidad crítica y alta.
- Diario y automático: SCA de dependencias con alerta al canal del equipo.
- Semanal: DAST sobre el entorno de preproducción.
- Trimestral: revisión manual de un módulo crítico rotando (autenticación, pagos, permisos, integraciones).
- Anual o ante cambios mayores: pentest externo con retest de los hallazgos críticos incluido en el mismo contrato.
La última coletilla importa: contratar el retest desde el principio evita la situación clásica de corregir a medias y no verificar nunca. Un hallazgo no está cerrado hasta que alguien independiente confirma que lo está.
5.3 Cómo se mide que esto funciona
Si vas a defender esta inversión ante dirección, mide cuatro cosas: el tiempo medio desde que se detecta un hallazgo hasta que se corrige, el porcentaje de dependencias con vulnerabilidades conocidas en producción, la cobertura de revisión sobre los módulos críticos y el número de hallazgos que reaparecen tras haberse cerrado. Ese último indicador es el más revelador: si los mismos fallos vuelven, el problema no es la herramienta, es que falta el estándar de codificación o la formación del equipo.
Este enfoque encaja de forma natural con la lógica de mejora continua de ambos marcos. La ISO 27001 lo articula a través del ciclo del SGSI y de las auditorías internas; el ENS, a través de la revisión periódica del cumplimiento. En los dos casos se espera que el sistema mejore con el tiempo, y eso solo se puede demostrar con datos históricos. Si estás construyendo el sistema de gestión desde cero, el análisis de riesgos con metodología ISO 27001 es el punto de partida que ordena en qué código merece la pena invertir primero.
6. Cómo empezar sin parar el roadmap
La objeción habitual al desarrollo seguro ISO 27001 es que suena a frenar la entrega de funcionalidades. No tiene por qué. Una implantación realista en un equipo que hoy no tiene nada se hace en tres tandas.
Semanas 1 a 4 — visibilidad. Inventario de aplicaciones, repositorios y entornos. Activar SCA y escaneo de secretos en modo informativo, sin bloquear nada. El objetivo de esta fase es únicamente saber dónde estás; el número inicial de alertas será alto y eso es normal.
Semanas 5 a 12 — proceso. Escribir el estándar de codificación segura (cinco páginas bien hechas valen más que cincuenta genéricas), integrar SAST en el pipeline bloqueando solo lo crítico, separar entornos de verdad y sustituir los datos reales de staging por datos anonimizados. Al final de esta fase ya tienes la mayor parte de A.8.25 a A.8.33 y de mp.sw cubiertas.
Meses 4 a 6 — verificación. Primera revisión manual de los módulos críticos, primer pentest externo y definición de la cadencia estable. A partir de aquí el sistema se sostiene solo con el mantenimiento habitual.
El error que sí conviene evitar es el inverso: contratar un pentest caro antes de tener lo básico. El informe se llenará de hallazgos que una herramienta gratuita habría detectado, pagarás precio de especialista por trabajo automatizable y el equipo se desmoralizará ante una lista inabarcable. Primero automatiza lo evidente; luego paga por los ojos humanos.
7. Conclusión
El desarrollo seguro ISO 27001 no pide código perfecto, y el ENS tampoco. Piden un proceso que produzca código razonablemente seguro de forma repetible, y evidencias de que ese proceso existe y se aplica. Traducido a decisiones concretas: un estándar de codificación que el equipo conozca, detección automática en el pipeline, revisión humana en lo crítico, entornos separados sin datos reales fuera de producción y una auditoría periódica que cierre el ciclo verificando lo corregido.
El beneficio real va más allá del certificado. Los equipos que adoptan el desarrollo seguro ISO 27001 como rutina reducen el retrabajo, entregan con menos sobresaltos y responden en horas —no en semanas— cuando aparece una vulnerabilidad grave en una librería que usan. El cumplimiento acaba siendo la consecuencia, no el objetivo.
Si tu organización se está planteando la certificación, ha recibido un cuestionario de proveedores que no sabe responder o simplemente lleva años acumulando código sin revisar, el mejor primer paso es una auditoría de diagnóstico: saber exactamente dónde estás antes de decidir cuánto invertir en llegar donde quieres.
8. Preguntas frecuentes
¿Necesito estar certificado para aplicar el desarrollo seguro ISO 27001?
No. Los controles del Anexo A son buenas prácticas aplicables por sí solas. Muchas organizaciones implantan el ciclo de desarrollo seguro años antes de plantearse certificarse, y llegan a la auditoría con la mitad del trabajo hecho.
¿El ENS me afecta si soy una empresa privada?
Directamente no, pero contractualmente sí en cuanto prestes servicios a una administración pública. La obligación llega por el contrato y por la cadena de suministro, y suele exigir el mismo nivel que el sistema al que das servicio.
¿Cada cuánto hay que hacer un pentest?
Como mínimo una vez al año, y siempre que haya un cambio de arquitectura relevante: una migración, un nuevo método de pago, la apertura de una API a terceros o un cambio de proveedor de hosting. Entre pentests, la detección automática cubre el día a día.
¿Vale con las herramientas gratuitas?
Para empezar, sí. El ecosistema abierto de SAST, SCA y escaneo de secretos cubre perfectamente los primeros meses. La inversión merece la pena cuando el volumen de código o el número de equipos hace que la gestión de los hallazgos, y no la detección, sea el cuello de botella.
