NIST SSDF (SP 800-218)

Los cuatro grupos de prácticas

El SSDF organiza sus prácticas en cuatro grupos. Cada práctica enuncia un resultado, y NIST deja claro que no es una lista de comprobación: es una base para planificar en función del riesgo.

Grupo	Objetivo	Ejemplos
Preparar la organización (PO)	Las personas, los procesos y las herramientas están preparados	Definir requisitos de seguridad, asignar funciones, proteger el entorno de desarrollo
Proteger el software (PS)	El código y las versiones están a salvo de manipulaciones	Proteger todas las formas de código, verificar la integridad de las versiones, archivar cada versión
Producir software bien protegido (PW)	Pocas vulnerabilidades en lo que se lanza	Diseñar pensando en la seguridad, reutilizar software bien protegido, revisar y probar el código
Responder a las vulnerabilidades (RV)	Encontrar los fallos restantes y ocuparse de ellos	Identificar vulnerabilidades de forma continua, priorizarlas y corregirlas, analizar las causas raíz

Las prácticas que afectan a su cadena de suministro

• PO.3, cadenas de herramientas de apoyo, y PO.5, entornos seguros. Su sistema de CI forma parte de lo que debe proteger. Consulte la lista de comprobación de seguridad del pipeline de CI/CD.
• PS.3, archivar y proteger cada versión. Incluye recopilar datos de procedencia de los componentes de cada versión, y el SSDF cita la SBOM como una forma de hacerlo.
• PW.4, reutilizar software bien protegido. Los componentes de terceros deben examinarse y mantenerse actualizados, y ahí es donde encaja el análisis de composición de software.
• RV.1, identificar vulnerabilidades de forma continua. Es una obligación permanente, no un control previo al lanzamiento, por lo que exige monitorizar lo que ya ha distribuido.
• RV.2, evaluar, priorizar y corregir. Consulte cómo priorizar vulnerabilidades.

¿Es obligatorio el SSDF?

No por sí mismo. Es una publicación de NIST, no una ley. Durante unos años importó directamente a los proveedores federales de EE. UU., porque los memorandos M-22-18 y M-23-16 de la OMB les exigían declarar que seguían prácticas extraídas de él. Eso cambió el 23 de enero de 2026: el memorando M-26-05 de la OMB revocó ambos y adoptó un enfoque basado en el riesgo. Las agencias pueden seguir usando el formulario común de atestación y las normas de NIST, pero ya no están obligadas a ello, de modo que los proveedores deben contar con que los requisitos varíen según la agencia.

Fuera de las compras federales, el SSDF sigue siendo útil como lenguaje común. Los clientes toman elementos de él en sus cuestionarios de seguridad, y tiene correspondencia con otras normas.

Versiones del SSDF

• La versión 1.1, SP 800-218, publicada en febrero de 2022, es la versión final vigente.
• La versión 1.2, SP 800-218 Revision 1, se publicó como borrador en diciembre de 2025.
• SP 800-218A es un perfil comunitario que amplía el SSDF a la IA generativa y a los modelos fundacionales de doble uso.

Cómo adoptar el SSDF

1. Haga un mapa de lo que hace hoy. Repase las prácticas y registre dónde ya las cumple y con qué evidencias.
2. Ordene las carencias por riesgo. El SSDF espera que lo aplique según su propio riesgo, así que no todas las prácticas merecen la misma profundidad.
3. Automatice las evidencias. Las evidencias que salen del pipeline se mantienen actualizadas sin trabajo adicional. Las que se escriben a mano quedan obsoletas.
4. Asigne responsables. Cada práctica necesita a alguien responsable. La mayoría recaerá en ingeniería más que en seguridad.
5. Revise a intervalos fijos. Actualice el mapa a medida que cambien sus herramientas y avance la versión 1.2.

SSDF, SLSA y el CRA

El SSDF dice lo que debería lograr un programa de desarrollo seguro. SLSA profundiza en una parte de él, la integridad del build. El Cyber Resilience Act de la UE es una ley con obligaciones propias. El trabajo hecho para uno se aprovecha en los demás, porque todos esperan que sepa qué contiene su software y que gestione sus vulnerabilidades.

Dónde encaja CRACI

El SSDF es un programa amplio, y ninguna herramienta lo cubre. CRACI aporta evidencias para las prácticas que dependen del build y de lo distribuido: SBOM de cada job de GitHub Actions, jobs aislados y control de salida en el entorno de build, monitorización continua del software distribuido y triaje de lo que encuentra. CRACI no hace que usted sea conforme, y el mapeo y la atestación siguen siendo cosa suya. Consulte seguridad de la cadena de suministro de software con CRACI.

NIST SSDF: preguntas frecuentes

¿Qué es el NIST SSDF?

El Secure Software Development Framework, publicado como NIST SP 800-218. Es un conjunto de prácticas para crear software seguro, organizado en cuatro grupos: preparar la organización, proteger el software, producir software bien protegido y responder a las vulnerabilidades.

¿Qué significa SSDF?

Secure Software Development Framework.

¿Es obligatorio el SSDF?

No. Es una guía, no una ley. Los proveedores federales de EE. UU. tenían que declarar que seguían prácticas extraídas de él, pero el memorando M-26-05 de la OMB revocó ese requisito en enero de 2026. Las agencias aún pueden pedir atestaciones.

¿Cuál es la última versión del SSDF?

La versión 1.1 (SP 800-218, febrero de 2022) es la versión final vigente. La versión 1.2 se publicó como borrador en diciembre de 2025, así que consulte el sitio de NIST para conocer su estado.

¿Cuál es la diferencia entre el SSDF y SLSA?

El SSDF abarca el desarrollo seguro en su conjunto: personas, procesos y tecnología. SLSA profundiza en la integridad del build y la procedencia. Funcionan bien juntos.

¿Exige el SSDF una SBOM?

Pide recopilar y compartir datos de procedencia de los componentes de cada versión, y cita la SBOM como una forma de hacerlo. Describe resultados en lugar de imponer una herramienta concreta.