NIST SSDF: el marco de desarrollo seguro de software

El Secure Software Development Framework (SSDF) del NIST, publicado como Special Publication 800-218, es un conjunto de prácticas de alto nivel para el desarrollo seguro de software que cualquier organización puede incorporar a su ciclo de desarrollo actual para reducir las vulnerabilidades del software publicado y limitar el daño de las que queden. Es un vocabulario compartido de resultados, no una metodología rígida.

Para valorar a tu propio equipo frente a las 19 prácticas, prueba la autoevaluación del NIST SSDF.

Qué es el SSDF y qué no es

El SSDF deliberadamente no te dice qué herramientas comprar, qué fases ejecutar ni cómo estructurar tu equipo. En su lugar describe resultados que el desarrollo seguro debe lograr, redactados de forma que una empresa Agile, una canalización DevOps y un proyecto en cascada puedan cumplirlos cada uno a su manera. Cada práctica va acompañada de tareas de ejemplo y referencias a otros estándares, pero la parte estable es la práctica en sí. Este diseño basado en resultados es lo que permite que el marco se coloque encima del ciclo de vida que ya tienes en lugar de obligarte a sustituirlo.

Los cuatro grupos de prácticas

El SSDF organiza sus prácticas en cuatro grupos que abarcan todo el ciclo de vida:

• PO: Prepare the Organization (preparar la organización). Sentar las bases del desarrollo seguro: definir requisitos de seguridad, asignar funciones y responsabilidades, dar formación y poner en marcha los procesos, las cadenas de herramientas y los criterios antes de escribir código.
• PS: Protect the Software (proteger el software). Proteger el código fuente y las releases frente a la manipulación y el acceso no autorizado, y dar a quienes lo consumen una forma de verificar la integridad y la procedencia de lo que reciben: la dimensión de integridad de la cadena de suministro.
• PW: Produce Well-Secured Software (producir software bien protegido). El trabajo de ingeniería central: diseño seguro (incluido el modelado de amenazas), prácticas de codificación segura, revisión de código, pruebas de seguridad y publicación con configuraciones seguras por defecto.
• RV: Respond to Vulnerabilities (responder a las vulnerabilidades). Encontrar, analizar, corregir y aprender de las vulnerabilidades descubiertas tras la publicación, incluido un proceso de recepción, divulgación y análisis de causa raíz para que no se repita la misma clase de fallo.

Leídos juntos, los grupos forman un ciclo: preparar la organización, proteger los artefactos, construir el software de forma segura y responder cuando algo se escapa, devolviendo las lecciones a la preparación.

Las prácticas del SSDF de un vistazo (SP 800-218 versión 1.1)

La SP 800-218 versión 1.1, publicada en febrero de 2022, define 19 prácticas en los cuatro grupos, y cada práctica tiene un ID que usan los formularios de atestación, los contratos y las auditorías para referirse a ella:

• PO - Prepare the Organization: PO.1 definir los requisitos de seguridad para el desarrollo de software; PO.2 implantar funciones y responsabilidades; PO.3 implantar cadenas de herramientas de apoyo; PO.4 definir y usar criterios para las comprobaciones de seguridad del software; PO.5 implantar y mantener entornos seguros para el desarrollo de software.
• PS - Protect the Software: PS.1 proteger todas las formas de código frente al acceso no autorizado y la manipulación; PS.2 ofrecer un mecanismo para verificar la integridad de las releases de software; PS.3 archivar y proteger cada release de software.
• PW - Produce Well-Secured Software: PW.1 diseñar el software para cumplir los requisitos de seguridad y mitigar los riesgos de seguridad; PW.2 revisar el diseño del software; PW.4 reutilizar software existente y bien protegido cuando sea viable; PW.5 crear el código fuente siguiendo prácticas de codificación segura; PW.6 configurar los procesos de compilación, de intérprete y de build para mejorar la seguridad; PW.7 revisar y analizar el código legible por humanos; PW.8 probar el código ejecutable; PW.9 configurar el software para que tenga ajustes seguros por defecto. (La numeración se salta PW.3, que se fusionó con PW.4.)
• RV - Respond to Vulnerabilities: RV.1 identificar y confirmar vulnerabilidades de forma continua; RV.2 evaluar, priorizar y corregir vulnerabilidades; RV.3 analizar las vulnerabilidades para identificar sus causas raíz.

El NIST también ha publicado la SP 800-218A, un perfil comunitario del SSDF que añade prácticas para el desarrollo de IA generativa y de modelos fundacionales de doble uso. Cuando traslades el SSDF a tu SDLC, sigue la cobertura con estos ID: hace visibles las carencias y te da el vocabulario que usa el formulario federal de autoatestación.

Por qué existe el SSDF

El SSDF es una respuesta a la crisis de la cadena de suministro de software. Una serie de compromisos de gran repercusión dejó claro que las prácticas de desarrollo inseguras en software muy utilizado generan un riesgo sistémico: una sola compilación o dependencia comprometida puede propagarse a miles de organizaciones posteriores. En 2021, la Orden Ejecutiva 14028 de EE. UU. sobre la mejora de la ciberseguridad del país encargó al NIST elaborar orientaciones sobre prácticas de desarrollo seguro para el software que compra el Gobierno federal.

El SSDF es la respuesta consolidada y neutral del NIST: una única base de referencia que las agencias y sus proveedores pueden citar en lugar de que cada uno invente la suya. Al redactarlo como resultados y no como mandatos, el NIST lo hizo útil tanto como marco de mejora interna como referencia para las compras.

Cómo encaja en tu SDLC

Adoptar el SSDF no significa reorganizar cómo construyes software. Como se basa en resultados, trasladas cada práctica al ciclo de vida que ya tienes y cubres las carencias:

• Planificación y diseño. Aquí entran el diseño seguro y el modelado de amenazas (PW) y los requisitos de seguridad (PO).
• Implementación. Prácticas de codificación segura y revisión de código (PW), además de proteger el propio repositorio de código (PS). La higiene de credenciales (detectar claves filtradas con un escáner de secretos) apoya tanto PW como PS.
• Pruebas e integración. Pruebas de seguridad (PW) con análisis estático, dinámico y de composición, como explicamos en nuestro explicativo sobre DAST.
• Build y release. Protecciones de integridad y procedencia de las releases (PS) que permiten a quien consume verificar lo que recibe.
• Operaciones. Recepción, triaje, corrección y divulgación de vulnerabilidades (RV).

Lo importante es la cobertura, no ajustarse a una forma prescrita: ¿puedes demostrar que cada resultado del SSDF se logra en algún punto de tu proceso?

La atestación y por qué importa más allá del Gobierno

Tras la Orden Ejecutiva 14028, el Gobierno de EE. UU. introdujo la obligación de que los productores de software que venden a las agencias federales atestaran que sus prácticas de desarrollo se alinean con el SSDF, mediante un formulario de autoatestación. En enero de 2026, el memorando M-26-05 de la OMB revocó los memorandos que hacían obligatorio el formulario (M-22-18 y M-23-16): las agencias aún pueden optar por usarlo y pueden exigir un SBOM por contrato, así que muchos compradores lo siguen pidiendo. La atestación es una declaración formal, respaldada por la propia garantía del productor, de que se cumplen los criterios de desarrollo seguro.

Lo importante es el efecto dominó. Como la atestación es una condición para vender a uno de los mayores compradores de software del mundo, las prácticas alineadas con el SSDF se han convertido en una expectativa de facto en buena parte del mercado, no solo en las cadenas de suministro federales. Un proveedor que no puede demostrar un desarrollo alineado con el SSDF tiene cada vez más dificultades también con los clientes empresariales. En ese sentido, el SSDF se ha convertido discretamente en una base de referencia para el desarrollo seguro comercial, extendida desde las compras públicas.

La conclusión

El SSDF es el marco del NIST, basado en resultados, para construir software de forma segura, organizado en cuatro grupos de prácticas: Prepare the Organization, Protect the Software, Produce Well-Secured Software y Respond to Vulnerabilities. Existe por la crisis de la cadena de suministro y la Orden Ejecutiva 14028, encaja en cualquier SDLC porque describe resultados y no herramientas, y gracias a la atestación federal se ha convertido en una expectativa básica mucho más allá del Gobierno. Trátalo como una lista de resultados que demostrar, no como un proceso que copiar.

Preguntas frecuentes

¿Qué es el NIST SSDF? La Special Publication 800-218: un conjunto de prácticas de desarrollo seguro de alto nivel y basadas en resultados que las organizaciones incorporan a cualquier ciclo de vida para reducir y contener las vulnerabilidades del software publicado.

¿Cuáles son los cuatro grupos de prácticas? Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) y Respond to Vulnerabilities (RV): abarcan la preparación, la integridad de los artefactos, la ingeniería segura y la respuesta tras la publicación.

¿Por qué existe? Como respuesta a la crisis de la cadena de suministro de software y a la Orden Ejecutiva 14028 de EE. UU. (2021), que encargó al NIST definir orientaciones de desarrollo seguro para el software que se vende al Gobierno federal.

¿Cómo encaja en un SDLC? Describe resultados, no fases ni herramientas, así que los equipos Agile, DevOps y en cascada trasladan cada práctica a su ciclo de vida actual y cubren las carencias.

¿Qué es la atestación del SSDF? Una autodeclaración formal de que un productor sigue prácticas alineadas con el SSDF, exigida para vender software a las agencias federales de EE. UU., lo que ha convertido el SSDF en una expectativa de facto del mercado más allá del Gobierno.