ENISA Secure by Design y los 22 playbooks que convierten la seguridad en una condición de liberación

Del principio a la evidencia mediante acciones, release gates, excepciones y decisiones de go/no-go en el ciclo de vida del producto

En el primer artículo de esta serie analizábamos el desplazamiento que propone el ENISA Secure by Design and Default Playbook: la seguridad deja de aparecer principalmente al final del desarrollo, cuando el producto ya está construido y las decisiones estructurales son difíciles de modificar, para incorporarse al momento en que se definen requisitos, relaciones de confianza, privilegios, mecanismos de autenticación, configuraciones y componentes.

Ese cambio conduce inevitablemente a una segunda pregunta. Incorporar la seguridad al diseño es necesario, pero ¿cómo podemos saber que las decisiones adoptadas durante el diseño llegaron realmente al producto? ¿Qué evidencia permite comprobar que un control existe y funciona? ¿Cuándo una desviación puede aceptarse y quién tiene autoridad para hacerlo? Y, finalmente, ¿qué condiciones deberían impedir que una determinada versión llegue a producción o al mercado?

Es en este punto donde el documento de ENISA pasa del plano de los principios al de su operacionalización.

El Secure by Design and Default Playbook, versión 1.0, publicado el 30 de julio de 2026, desarrolla 22 playbooks destinados principalmente a fabricantes y equipos de producto de pequeñas y medianas empresas. Su propósito no es construir una nueva capa burocrática sobre el desarrollo, sino traducir principios de seguridad en acciones repetibles que puedan integrarse en los procesos existentes de ingeniería, producto y liberación. ENISA acompaña además la publicación con un repositorio específico que reúne los 22 playbooks en un formato de consulta más operativo.

La aportación no consiste en haber inventado las security gates, las quality gates o las definiciones de terminado, conceptos que llevan años presentes en SSDLC, DevSecOps y marcos como OWASP SAMM. Lo que ENISA hace de forma particularmente útil es sistematizar esa lógica alrededor de cada principio y relacionar de manera expresa la acción técnica, la evidencia que permite observarla y los criterios que deberían revisarse antes de liberar una versión.

La consecuencia que podemos extraer es relevante: que una funcionalidad esté terminada no significa necesariamente que la versión esté preparada para ser liberada desde la perspectiva de seguridad.

Del principio a una decisión verificable

Los 22 playbooks comparten una estructura deliberadamente uniforme. Cada uno identifica el principio que pretende implementar, explica el objetivo perseguido y los fallos que trata de evitar, incorpora una lista de acciones prácticas, determina una evidencia mínima y termina con una release gate, es decir, un conjunto de criterios de aprobado o no aprobado que pueden incorporarse a una revisión de liberación o, cuando resulte posible, al propio proceso de CI/CD.

La lógica puede resumirse de esta manera:

principio → objetivo → acción → evidencia → criterio de liberación

La secuencia parece sencilla, pero introduce una diferencia importante frente a una aproximación basada exclusivamente en políticas o declaraciones.

Una organización puede haber establecido formalmente que aplica mínimo privilegio, que gestiona sus dependencias, que realiza modelado de amenazas o que desarrolla siguiendo prácticas de codificación segura. Ninguna de esas afirmaciones permite saber, por sí sola, qué ocurrió en una versión concreta. Para responder a esa cuestión necesitamos bajar un nivel y preguntarnos qué acción se realizó, qué resultado produjo, qué evidencia permanece y cómo influyó esa evidencia en la decisión de liberar.

El valor del modelo aparece precisamente en esa relación entre lo que se afirma, lo que se hace y lo que puede demostrarse.

Ahora bien, los 22 playbooks no deben interpretarse como una lista universal que deba ejecutarse mecánicamente en su totalidad antes de cada release. ENISA mantiene una lógica basada en el riesgo, el contexto del producto y el cambio introducido. El modelo de amenazas, la evaluación del riesgo y las modificaciones de cada versión deben determinar qué criterios necesitan volver a comprobarse. Cuando una propiedad de seguridad no se ha visto afectada, puede documentarse como tal en lugar de volver a ejecutar indiscriminadamente todas las verificaciones.

Esta precisión es fundamental porque mantiene la proporcionalidad del enfoque. Una puerta de liberación basada en riesgo no pregunta simplemente si hemos marcado todas las casillas, sino si sabemos qué ha cambiado y qué propiedades de seguridad podrían haberse visto afectadas por ese cambio.

Figura 1 (IA): Los playbooks convierten principios de seguridad en acciones, evidencias y criterios verificables capaces de condicionar la liberación de una versión.

Evidencia de implementación no significa todavía evidencia suficiente

La noción de evidencia mínima es una de las contribuciones más prácticas del documento, pero también una de las que requiere mayor cuidado conceptual.

ENISA utiliza esa expresión para referirse al conjunto mínimo de artefactos, registros, configuraciones o resultados que pueden demostrar que las acciones previstas en el playbook han sido realizadas. La propia guía insiste en que no es necesario crear un documento independiente para cada control y recomienda reutilizar evidencias que ya existen dentro del proceso de ingeniería: diagramas de arquitectura, archivos del repositorio, configuraciones, tickets, resultados de pruebas, SBOM, salidas de CI/CD o registros de liberación.

Este enfoque permite evitar una situación bastante habitual: que la ingeniería ocurra en repositorios, pipelines y sistemas de tickets mientras el cumplimiento se documenta después en una estructura paralela que intenta reconstruir retrospectivamente lo sucedido.

Cuando sea posible, la evidencia debería nacer donde se ejecuta el control. Si el pipeline analiza las dependencias, su salida constituye una evidencia. Si una modificación crítica exige revisión por pares, la aprobación puede quedar registrada en la pull request. Si una vulnerabilidad genera una corrección, el ticket debería permitir seguir la relación entre el hallazgo, el cambio realizado, las pruebas ejecutadas y la versión en la que quedó resuelto.

Sin embargo, conviene evitar un salto lógico frecuente: evidencia mínima no equivale automáticamente a evidencia suficiente de seguridad.

Entre afirmar que un control está implementado, demostrar que funciona y concluir que resulta suficiente frente al riesgo existen tres niveles diferentes.

Una configuración puede demostrar que un mecanismo está habilitado. Una prueba puede aportar evidencia de que responde como se esperaba en determinadas condiciones. Pero concluir que esa configuración y esas pruebas proporcionan una protección suficiente exige considerar cobertura, contexto, amenazas, limitaciones de las herramientas y riesgo residual.

Podemos expresarlo mediante tres preguntas distintas:

¿Existe el control? → ¿Funciona? → ¿Es suficiente para este riesgo?

No deberían confundirse.

Esta distinción resulta especialmente importante cuando utilizamos herramientas automatizadas. Ejecutar SAST, DAST o análisis de composición no convierte automáticamente una versión en segura. Las herramientas tienen reglas, configuraciones, coberturas, falsos positivos y falsos negativos. La automatización puede demostrar de manera consistente que una prueba fue ejecutada y cuál fue su resultado; determinar qué significa ese resultado para la seguridad del producto sigue requiriendo contexto y criterio técnico.

Esta idea encaja con marcos consolidados como el NIST Secure Software Development Framework, cuyo objetivo es integrar prácticas de desarrollo seguro en el SDLC para reducir vulnerabilidades, mitigar el impacto de aquellas que no se detectan inicialmente y actuar sobre sus causas raíz, sin reducir la seguridad a una única herramienta o fase de prueba.

Figura 2 (IA): Demostrar que un control existe no demuestra todavía que funcione ni que resulte suficiente frente al riesgo que pretende tratar.

Cuando la seguridad entra realmente en el go/no-go

El concepto de release gate permite dar el paso siguiente. ENISA propone que los criterios de cada playbook puedan incorporarse como elementos habituales de las revisiones de preparación para la liberación y, cuando proceda, automatizarse dentro del CI/CD.

La guía conecta además esta lógica con una revisión de riesgo previa a la liberación, en la que deben verificarse los requisitos aplicables, la configuración por defecto, las vulnerabilidades conocidas, el tratamiento de los riesgos relevantes y las excepciones documentadas antes de adoptar una decisión de go/no-go.

Esto no significa que toda release gate produzca automáticamente un bloqueo técnico. Algunas comprobaciones pueden ejecutarse de forma automatizada; otras necesitan valoración humana, y el propio modelo admite excepciones justificadas.

La formulación más exacta sería, por tanto, que la seguridad adquiere capacidad para condicionar formalmente la liberación y, cuando el criterio requerido no se satisface ni existe una excepción legítimamente aceptada, para impedirla.

La diferencia con una recomendación informal es considerable.

Si una organización declara que las vulnerabilidades críticas deben estar resueltas antes del lanzamiento, pero el proceso permite liberar sistemáticamente versiones con vulnerabilidades críticas sin decisión formal, la regla tiene poco valor de gobierno. Para que exista una verdadera puerta de liberación necesitamos que el criterio esté integrado en el flujo de trabajo, que exista claridad sobre quién puede autorizar una excepción y que esa excepción deje evidencia.

Por ello, la eficacia de una release gate depende tanto del control técnico como de la gobernanza que lo rodea.

Automatizar lo repetible sin automatizar el juicio

La automatización ocupa un lugar importante en la propuesta de ENISA, particularmente porque el documento está pensado para organizaciones con recursos limitados. La posibilidad de trasladar comprobaciones a CI/CD permite reducir trabajo manual, aumentar la consistencia y ofrecer retroalimentación más cercana al momento en que se introduce un cambio.

Sin embargo, no todo debería transformarse en una condición binaria ejecutada por una herramienta.

Resulta razonable automatizar la comprobación de que se ejecutó un análisis de dependencias, que existe el SBOM asociado a una versión, que determinadas pruebas pasaron, que la configuración coincide con una línea base o que un artefacto está firmado correctamente.

Es mucho más difícil automatizar preguntas como si el riesgo residual de una determinada vulnerabilidad resulta aceptable para el contexto de uso, si un control compensatorio proporciona protección suficiente, si una modificación requiere rehacer el modelo de amenazas o si una excepción puede mantenerse durante otro ciclo de liberación.

La distinción debería orientarnos hacia una regla práctica: automatizar aquello cuya decisión ya está suficientemente definida y reservar el juicio humano para aquello que requiere contexto, ponderación y responsabilidad.

Eso permite evitar tanto el exceso de procesos manuales como la falsa seguridad de creer que un pipeline puede sustituir decisiones que pertenecen a la gobernanza del riesgo.

La excepción también debe diseñarse

Un modelo de liberación realista necesita admitir que habrá ocasiones en las que un determinado criterio no pueda satisfacerse inmediatamente.

Puede existir una vulnerabilidad para la que todavía no haya parche, un componente que no pueda sustituirse en la versión prevista, una limitación técnica que impida aplicar el control originalmente diseñado o una situación en la que la corrección inmediata genere riesgos operativos mayores que el mantenimiento temporal de la desviación.

La cuestión no es eliminar las excepciones, sino evitar que funcionen como un atajo informal alrededor de los controles.

ENISA plantea que las desviaciones deben disponer, al menos, de justificación, responsable y fecha de revisión, incorporando en distintos playbooks la necesidad de contemplar medidas compensatorias y límites temporales.

Desde una perspectiva de GRC, conviene dar un paso adicional y distinguir entre la excepción al control y la aceptación del riesgo residual.

Podemos autorizar temporalmente que un control no se implemente de la manera prevista, pero la verdadera decisión de gobierno consiste en comprender qué riesgo permanece como consecuencia de esa excepción y determinar si la organización dispone de autoridad y fundamento suficiente para aceptarlo.

Una excepción bien gobernada debería permitir reconstruir qué condición no se cumple, por qué no puede cumplirse en ese momento, qué riesgo genera esa situación, qué medidas compensatorias se han establecido, quién dispone de autoridad para aceptar el riesgo y en qué momento deberá revisarse nuevamente la decisión.

De este modo, la excepción deja de significar “el control no se aplica” y pasa a significar “la organización conoce el riesgo que permanece y ha adoptado una decisión explícita y temporal sobre él”.

Figura 3 (IA): Una excepción no elimina el riesgo: exige hacerlo visible, valorar el riesgo residual, asignar autoridad y establecer cuándo deberá revisarse.

Saber qué estamos liberando

El playbook dedicado a la cadena de suministro permite apreciar especialmente bien la relación entre conocimiento del producto, evidencia y decisión de liberación.

Los productos actuales dependen de bibliotecas, paquetes, servicios y componentes desarrollados por terceros, de manera que conocer únicamente el código producido internamente resulta insuficiente para conocer realmente aquello que se está liberando.

ENISA propone inventariar dependencias y proveedores relevantes, generar y mantener SBOM, integrar análisis de dependencias en CI, proteger los sistemas de construcción y las claves de firma, restringir permisos sobre repositorios y pipelines y aplicar controles adicionales en productos de mayor riesgo.

El SBOM es especialmente útil, pero conviene mantener la cautela doctrinal: un SBOM no es un control de seguridad completo ni demuestra por sí mismo que la cadena de suministro sea segura.

Su valor principal está en proporcionar transparencia sobre los componentes. Esa transparencia adquiere utilidad cuando puede relacionarse con versiones, vulnerabilidades conocidas, procedencia, procesos de actualización y soporte.

La pregunta relevante antes de una liberación deja entonces de ser únicamente si nuestro código funciona y se amplía hacia otra bastante más exigente: ¿sabemos con suficiente precisión qué estamos poniendo en el mercado y podremos identificar después qué productos están afectados cuando aparezca una vulnerabilidad en alguno de sus componentes?

Esa trazabilidad no es solo una cuestión de ingeniería. El CRA exige que la documentación técnica incorpore información sobre diseño, desarrollo, gestión de vulnerabilidades y, entre otros elementos, la nomenclatura de materiales de software en los términos previstos por el Reglamento.

Secure by Default también necesita evidencia

La lógica de las puertas de liberación no se limita a Secure by Design. ENISA la extiende también a Secure by Default.

Esto resulta importante porque una configuración segura por defecto no debería permanecer como una intención declarada por el fabricante; debería constituir una propiedad verificable de la configuración con la que el producto se pone inicialmente a disposición del usuario.

Los playbooks relativos a la minimización de servicios habilitados, el acceso inicial restrictivo, las comunicaciones seguras, las identidades y secretos únicos, la incorporación inicial de medidas de seguridad, las actualizaciones automáticas, la visibilidad de la postura de seguridad y los mecanismos de recuperación obligan a comprobar cómo se comporta realmente el producto desde su primera utilización.

Esta perspectiva es especialmente interesante porque desplaza la atención desde la existencia de una opción de seguridad hasta su configuración efectiva. No basta con que el producto admita comunicaciones cifradas si inicialmente permite utilizar un protocolo inseguro sin necesidad. Tampoco basta con ofrecer MFA en algún menú si el escenario de riesgo exige que el usuario lo configure dentro del proceso inicial.

La relación con el CRA es directa en este punto. Su anexo I exige que los productos con elementos digitales se diseñen, desarrollen y produzcan con un nivel adecuado de ciberseguridad basado en el riesgo y, cuando corresponda, que se comercialicen sin vulnerabilidades explotables conocidas y con una configuración segura por defecto.

Del playbook al Cyber Resilience Act y por qué apoyo técnico no significa conformidad

La relación con el Reglamento (UE) 2024/2847, Cyber Resilience Act, necesita formularse con especial precisión.

El Playbook es una herramienta técnica de apoyo. No constituye un instrumento de evaluación de conformidad, no crea una presunción de cumplimiento del CRA y superar las release gates internas definidas a partir de sus playbooks no permite afirmar automáticamente que un producto sea conforme con el Reglamento.

El CRA se aplica a los productos con elementos digitales comprendidos en su ámbito y establece obligaciones específicas para fabricantes y otros operadores económicos, junto con requisitos esenciales de ciberseguridad y gestión de vulnerabilidades. La intensidad del procedimiento de evaluación de conformidad dependerá, además, de la naturaleza y clasificación del producto y del procedimiento que corresponda.

Los release gates pueden, sin embargo, desempeñar un papel muy relevante como mecanismo interno para operacionalizar determinadas exigencias y producir evidencias sobre decisiones de diseño, configuración segura, gestión de vulnerabilidades, componentes o cadena de suministro.

La distinción puede formularse así: el playbook puede ayudar a generar y ordenar evidencia técnicamente relevante para el cumplimiento, pero no sustituye la determinación de los requisitos jurídicos aplicables ni el procedimiento de evaluación de conformidad previsto por el CRA.

Esto exige que el fabricante identifique los requisitos esenciales aplicables, realice y documente su evaluación de riesgos de ciberseguridad, mantenga la documentación técnica, gestione las vulnerabilidades durante el período de soporte y siga el procedimiento de evaluación de conformidad que corresponda al producto. El anexo VII del CRA exige, entre otros elementos, una descripción del diseño y desarrollo, los procesos de gestión de vulnerabilidades, la evaluación de riesgos de ciberseguridad y los informes de pruebas utilizados para verificar la conformidad.

Además, la dimensión temporal no debe perderse. Aunque el CRA se encuentra ya en vigor, su aplicación general comenzará el 11 de diciembre de 2027. No obstante, el artículo 14 resulta aplicable desde el 11 de septiembre de 2026 y el capítulo IV, relativo a los organismos de evaluación de la conformidad, desde el 11 de junio de 2026.

Por tanto, cuando hablamos hoy de preparación para el CRA conviven obligaciones que ya han comenzado a producir efectos con otras cuyo período de preparación regulatoria todavía está transcurriendo.

Adopción progresiva no significa cumplimiento progresivo

ENISA propone una adopción escalonada de los playbooks para facilitar su incorporación en organizaciones con capacidades limitadas. El punto de partida debe ser el contexto, la gestión del riesgo y el modelado de amenazas, para continuar con una línea base de ingeniería y ampliar posteriormente la cobertura y la automatización.

Esta gradualidad organizativa resulta razonable, pero no debe interpretarse como un permiso para posponer requisitos necesarios. El documento advierte expresamente que la adopción progresiva de los playbooks no implica retrasar controles o requisitos aplicables, incluidos los derivados de obligaciones legales bajo el CRA.

La distinción es especialmente importante para pymes.

Una organización puede necesitar tiempo para madurar su SSDLC, introducir nuevas herramientas, automatizar evidencias o mejorar la integración entre desarrollo y seguridad. Lo que no puede hacer es convertir esa hoja de ruta interna en una justificación para diferir una obligación jurídica cuyo momento de aplicación ya ha llegado o un control necesario frente a un riesgo que ya conoce.

La progresividad se refiere a la madurez del sistema de ingeniería, no a una reducción de la exigencia normativa.

Qué cambia para GRC y auditoría

La estructura propuesta por ENISA tiene consecuencias que van más allá de los equipos de desarrollo.

Tradicionalmente, una parte importante del trabajo de GRC y auditoría ha consistido en reconstruir retrospectivamente lo que ocurrió mediante políticas, formularios, entrevistas, capturas, matrices y muestras documentales. La creciente disponibilidad de evidencia generada directamente por repositorios, pipelines, sistemas de tickets, herramientas de análisis y plataformas de despliegue permite cambiar parcialmente esa dinámica.

El registro de riesgos puede relacionarse con requisitos; los requisitos, con controles; los controles, con pruebas; las pruebas, con versiones concretas; y las excepciones, con responsables y fechas de revisión.

Esto no sustituye la auditoría ni convierte automáticamente el pipeline en un sistema de aseguramiento.

El auditor continuará teniendo que valorar si el control está correctamente diseñado, si la evidencia es íntegra y suficientemente completa, si las herramientas están correctamente configuradas, si existen vías para eludir el proceso y si la organización está interpretando razonablemente sus resultados.

La ventaja es otra: disponer de evidencia nativa del proceso de ingeniería reduce la necesidad de reconstruir los hechos mucho tiempo después y permite concentrar el aseguramiento en la calidad de los controles y en la razonabilidad de las decisiones.

La trazabilidad mejora la auditoría; no la reemplaza.

No se trata de producir más documentos sino de producir mejor evidencia

El mensaje no debería interpretarse como una invitación a reducir indiscriminadamente la documentación.

Determinadas obligaciones legales y regulatorias exigen documentación específica, y el CRA constituye precisamente un buen ejemplo de ello. El análisis de riesgos, la documentación técnica, las pruebas de conformidad o las justificaciones de determinadas decisiones no desaparecen porque dispongamos de mejores pipelines.

La cuestión es evitar documentación redundante que no aporta evidencia real sobre el funcionamiento del control.

La seguridad demostrable depende menos del volumen documental que de su calidad, actualidad, integridad y trazabilidad.

Una organización debería poder reconstruir por qué consideró razonablemente segura una versión en el momento en que decidió liberarla: qué riesgos conocía, qué medidas aplicó, qué comprobaciones realizó, qué problemas permanecían abiertos, qué excepciones aceptó, quién asumió esas decisiones y qué condiciones obligarán a revisarlas posteriormente.

Cuando esa historia puede reconstruirse a partir de evidencia coherente, la decisión de go/no-go deja de depender únicamente de percepciones o declaraciones y comienza a convertirse en una verdadera decisión de gobierno.

De la evidencia documental a la evidencia procesable

Esta evolución conduce de forma natural al tercer artículo de la serie.

Si comenzamos a vincular riesgos, afirmaciones de seguridad, controles, pruebas, resultados y decisiones de liberación, surge una pregunta adicional: ¿es necesario mantener toda esa información dispersa entre documentos, tickets, pipelines y repositorios, o podemos expresarla de forma estructurada para que otras herramientas puedan interpretarla y verificarla?

La sección siguiente del documento de ENISA introduce precisamente la posibilidad de convertir determinadas afirmaciones de seguridad en atestaciones estructuradas y procesables por máquinas, capaces de relacionar afirmaciones, evidencias y resultados de verificación sin proponer por ello un nuevo esquema obligatorio.

La cuestión ya no será únicamente qué evidencia tenemos, sino cómo conseguir que esa evidencia pueda reutilizarse, verificarse y alimentar automáticamente otros procesos de seguridad, adquisición, despliegue o aseguramiento.

Ese será el siguiente paso de esta serie.

Serie De la seguridad declarada a la seguridad demostrable

I. Secure by Design ya no puede ser un eslogan cuando la seguridad entra en la arquitectura del producto

II. ENISA Secure by Design y los 22 playbooks que convierten la seguridad en una condición de liberación

III. De la evidencia documental a la evidencia procesable y el futuro de la demostrabilidad de la seguridad

Referencias esenciales

ENISA, Secure by Design and Default Playbook. A Practical Guide to Secure by Design and Default Principles for SMEs, versión 1.0, 30 de julio de 2026. La publicación oficial incorpora también el repositorio de los 22 playbooks. ENISA

Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024, relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales, especialmente sus artículos 13, 14 y 71 y sus anexos I y VII. EUR-Lex

NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, como referencia complementaria para la integración sistemática de prácticas de desarrollo seguro dentro del ciclo de vida del software. NIST Seguridad Informática

OWASP Software Assurance Maturity Model (SAMM), como referencia complementaria para la organización y maduración progresiva de prácticas de seguridad dentro del desarrollo.

Autor y responsable editorial: Leocadio Marrero Trujillo.
El enfoque, la arquitectura, los criterios de análisis y las conclusiones de este artículo han sido definidos y validados por el autor. Durante su elaboración se han utilizado herramientas de inteligencia artificial generativa como apoyo para la estructuración, reformulación, edición y creación de determinados elementos gráficos.

El contenido ha sido sometido a revisión humana sustantiva, comprobación de fuentes y validación jurídica y técnica. El autor ha aprobado la versión definitiva y asume íntegramente la responsabilidad editorial sobre su contenido