01Qué es un Secure SDLC – y por qué las pruebas por sí solas no bastan
Un SSDLC no es un proyecto adicional, sino una disciplina de proceso: los requisitos, actividades y responsabilidades de seguridad se definen a lo largo de todas las fases del desarrollo de software – desde los requisitos, pasando por el diseño, la implementación, las pruebas y el release, hasta la operación. La idea fundamental es prevenir o detectar las vulnerabilidades lo antes posible, porque su corrección se encarece con cada fase posterior («shift left»). Las pruebas de seguridad puntuales poco antes del release siguen siendo importantes, pero solo examinan el resultado; un SSDLC aborda además las causas dentro del proceso. El enfoque es independiente del modelo de desarrollo y puede integrarse tanto en organizaciones clásicas como ágiles o DevOps.
02NIST SSDF (SP 800-218): el catálogo de referencia de prácticas de desarrollo seguro
El Secure Software Development Framework del NIST (SP 800-218, versión 1.1, final desde febrero de 2022) describe 19 practices con 42 tasks en cuatro grupos: «Prepare the Organization» (PO), «Protect the Software» (PS), «Produce Well-Secured Software» (PW) y «Respond to Vulnerabilities» (RV). Cada practice incluye ejemplos de implementación y referencias a otras normas, pero está formulada deliberadamente de forma neutral en cuanto a tecnología y metodología – el SSDF resulta así idóneo como lenguaje común entre desarrollo, seguridad y compras. Desde el 17 de diciembre de 2025 está disponible además el borrador de la versión 1.2 (SP 800-218r1, Initial Public Draft; el plazo de comentarios finalizó el 30 de enero de 2026); aún no es definitivo y, por tanto, solo debe tratarse como una perspectiva.
03SP 800-218A: el perfil SSDF para la IA generativa
Para el desarrollo de IA generativa y de los llamados dual-use foundation models, el NIST publicó en julio de 2024 el complemento SP 800-218A («Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile»). El Community Profile amplía las practices del SSDF con tareas, recomendaciones y referencias específicas de IA para todo el ciclo de vida del desarrollo de modelos – por ejemplo, para el tratamiento de los datos de entrenamiento y de los artefactos de modelo. Se dirige a organizaciones que desarrollan modelos de IA, los integran en sistemas o los adquieren, y está concebido expresamente para utilizarse junto con SP 800-218.
04OWASP SAMM: medir la madurez y derivar una hoja de ruta
Mientras el SSDF describe qué hay que hacer, el OWASP Software Assurance Maturity Model (SAMM, versión 2 desde enero de 2020, actualmente versión 2.2 de julio de 2024) responde a lo bien que una organización ya lo está haciendo. El modelo se estructura en cinco business functions – Governance, Design, Implementation, Verification y Operations – con tres security practices cada una (15 en total), que se evalúan a su vez mediante dos streams y tres niveles de madurez. SAMM está concebido explícitamente como un modelo medible y registra, además de la cobertura, la calidad de las actividades; del resultado puede derivarse una hoja de ruta de mejora priorizada. VamiSec pone a disposición un self-assessment SAMM en ssdlc-assessment.com.
05Security gates: puntos de control definidos por fase
Los security gates son criterios definidos de antemano que una iniciativa debe cumplir antes de pasar a la siguiente fase – exactamente lo que exige la practice PO.4 del SSDF («Define and Use Criteria for Software Security Checks»). Gates típicos son: requisitos de seguridad documentados en la fase de requisitos (PO.1), un threat model en el diseño (PW.1), directrices de codificación segura y comprobaciones automatizadas como SAST y Software Composition Analysis en la implementación (PW.5, PO.3), revisiones de código y pruebas de seguridad antes del release (PW.7, PW.8), así como artefactos de build y release protegidos con integridad verificable (PS.1, PS.2). En la operación, la identificación continua de vulnerabilidades, su priorización y el análisis de causas raíz (RV.1–RV.3) cierran el ciclo. Los criterios de gate eficaces se formulan de forma medible – por ejemplo, mediante el porcentaje de gates superados, el tiempo hasta la corrección de las vulnerabilidades detectadas o la reaparición de las mismas clases de vulnerabilidades; SAMM ancla este gobierno en la practice «Strategy & Metrics».
06CRA: obligaciones de proceso para productos con elementos digitales
El Cyber Resilience Act (Reglamento (UE) 2024/2847, en vigor desde diciembre de 2024) convierte un SSDLC operativo en una obligación para los fabricantes de productos con elementos digitales: el anexo I, parte I, define los requisitos sobre las propiedades del producto (entre otros, security by design y configuraciones predeterminadas seguras sobre la base de una evaluación de riesgos), y la parte II, los requisitos para el tratamiento de vulnerabilidades – incluida la elaboración de una Software Bill of Materials (SBOM). Las vulnerabilidades explotadas activamente y los incidentes graves estarán sujetos a notificación obligatoria a partir del 11 de septiembre de 2026 (alerta temprana en un plazo de 24 horas, información adicional en 72 horas, informe final tras 14 días o un mes, según el caso); el reglamento será plenamente aplicable a partir del 11 de diciembre de 2027. Las actualizaciones de seguridad deben proporcionarse durante un período de soporte de, por regla general, cinco años – sin procesos documentados de desarrollo y de tratamiento de vulnerabilidades, esto difícilmente puede demostrarse de forma sólida.
