01Secure by design vs. secure by default
Secure by design describe cómo se construye un sistema: las amenazas se modelan pronto, y los patrones de arquitectura, la criptografía contrastada y la gestión sistemática de vulnerabilidades se integran en el proceso de desarrollo en lugar de añadirse a posteriori. Secure by default describe cómo llega el producto al cliente: con la configuración más segura razonablemente posible de fábrica, sin exigir conocimientos expertos; las protecciones están activas y debilitarlas requiere una decisión deliberada. El playbook organiza los 14 principios de diseño en Architectural Foundations y Operational Integrity, y los 8 principios por defecto en Default Hardening y Guided Protection.
02Los 22 principios de un vistazo
Architectural Foundations (6) abarca trust boundaries y threat modelling, mínimo privilegio, una arquitectura sólida de identidad y autenticación, la minimización de la superficie de ataque, la defensa en profundidad y el open design. Operational Integrity (8) añade la gestión del ciclo de vida, el diseño centrado en el usuario, la codificación segura y su verificación, el logging y la monitorización, la gestión de configuraciones y cambios, la respuesta a incidentes, la gestión de vulnerabilidades y parches, y los controles de la cadena de suministro, SBOM incluido. En el lado por defecto figuran la minimización de servicios por defecto, el acceso inicial restrictivo, la comunicación cifrada de fábrica e identidades únicas por dispositivo (Default Hardening), además del onboarding de seguridad obligatorio, las actualizaciones automáticas, una postura de seguridad transparente y procesos seguros de recuperación y transferencia de propiedad (Guided Protection).
03Anatomía del playbook: lista de verificación, evidencias, release gate
Cada principio sigue el mismo formato de cinco bloques: principio, objetivo, una lista de verificación con las acciones de mayor impacto, evidencias mínimas –el conjunto más pequeño de artefactos que demuestra la implantación– y un release gate con criterios de aprobado/suspenso para las revisiones de release o la pipeline CI/CD. Las evidencias deben proceder de artefactos de ingeniería existentes (diagramas de arquitectura, logs de CI, tickets, SBOM) y pueden servir a varios playbooks a la vez; se permiten excepciones, pero solo documentadas con responsable y fecha de revisión. Para la adopción, ENISA propone tres etapas: aclarar primero el contexto y las prioridades; establecer después una base de ingeniería con codificación segura, logging, gestión de vulnerabilidades y controles de la cadena de suministro –complementada con los playbooks por defecto relevantes para el producto– y, por último, ampliar cobertura y automatización. Importante: este plan por etapas organiza el esfuerzo, no aplaza ninguna obligación legal.
04Threat modelling en versión ligera
En lugar de análisis pesados, el playbook recomienda un minimum viable threat model en torno a las cuatro preguntas del marco de Shostack: ¿en qué estamos trabajando? ¿Qué puede salir mal? ¿Qué vamos a hacer al respecto? ¿Lo hicimos suficientemente bien? El resultado cabe en una página: un diagrama con componentes, flujos de datos y trust boundaries, los cinco a diez escenarios de amenaza más relevantes, controles por escenario con ajustes secure-default y métodos de verificación, además de disparadores definidos para actualizar el modelo. ENISA señala expresamente los antipatrones típicos: el threat modelling como ejercicio puntual de cumplimiento, modelos sobredimensionados sin efecto en las decisiones de diseño y la falta de actualización tras cambios del producto. En productos con componentes de IA, la prompt injection, el envenenamiento de modelos y las entradas adversarias también forman parte del modelo.
05Atestación procesable por máquina: compliance as code
La parte más visionaria del documento: las afirmaciones de seguridad salen de los PDF estáticos hacia artefactos estructurados y firmables (JSON/YAML) que conectan tres capas: objetivos de seguridad (control layer), controles implantados y su configuración (implementation layer) y resultados de verificación automatizados con hashes de evidencia (assessment and verification layer). Con el ejemplo desarrollado SafeGate-X1, un controlador industrial Linux, ENISA muestra cómo las amenazas se vuelven trazables desde los principios hasta release gates automáticos, del gate de escaneo Nmap a la prueba de sistema de archivos de solo lectura en la CI. ENISA no prescribe deliberadamente ningún esquema nuevo y remite a estándares existentes: NIST OSCAL, OWASP CycloneDX con CDXA y VEX, el perfil de seguridad de SPDX 3.0, proyectos de la OpenSSF como Scorecard y SLSA, además de in-toto y Sigstore. Y deja claro un punto: una atestación del fabricante no es una prueba; la verificación y la evaluación independiente siguen siendo pasos separados.
06El puente hacia el CRA: el anexo C
El anexo B del playbook recoge los requisitos esenciales de ciberseguridad del anexo I del Cyber Resilience Act; el anexo C asigna a ellos, de forma indicativa, cada uno de los 22 principios: las actualizaciones automáticas al anexo I parte I 2(c), los controles de la cadena de suministro a la obligación de SBOM de la parte II o el acceso inicial restrictivo a la configuración por defecto segura de la parte I 2(b). Eso convierte el documento en una puerta de entrada de ingeniería útil para las gap analysis del CRA: los equipos ven qué playbooks alimentan qué requisitos y recopilan pronto evidencias sólidas a través de los release gates. Al mismo tiempo, ENISA subraya que seguir el playbook no establece la conformidad con el CRA: la evaluación de la conformidad, las normas armonizadas y la documentación técnica exigida por el reglamento siguen siendo obligaciones independientes.
Deep dive: Cyber Resilience Act de la UE → 
