Durante tres décadas, la criptografía permaneció discretamente en segundo plano en el desarrollo de l software . Protegía el tráfico y firmaba alguna que otra versión, pero rara vez llegaba a la sala de juntas.
Eso ha cambiado. Hoy en día, un director ejecutivo firma personalmente un documento en el que se declara que su empresa sigue prácticas de desarrollo seguro, y el SSDF ocupa un lugar central en ese compromiso.
Esa firma no es una mera formalidad. Se trata de una declaración formal con valor jurídico, y las pruebas en las que se basa deben ser sólidas en caso de que un comprador federal solicite verlas en algún momento. Esta guía explica qué exige el marco normativo, por qué la firma de código y la gestión de claves son tan importantes, y cómo elaborar pruebas que se puedan defender.
Qué es realmente el NIST SP 800-218 (SSDF)
El Marco de Desarrollo Seguro de Aplicaciones de la Web ( Software , SSDF) es la Publicación Especial 800-218 del NIST. El NIST publicó la versión 1.1 en febrero de 2022.
En lugar de ser una lista de verificación normativa, el SSDF describe los resultados que debe alcanzar el desarrollo seguro. Esto permite a los equipos adaptarlo al ciclo de vida de desarrollo que ya utilicen. El marco organiza esos resultados en cuatro grupos:
- Prepara la organización: asegúrate de que el personal, los procesos y las herramientas estén preparados para desarrollar un software o de forma segura.
- Proteger el « software »: Proteger todo tipo de código contra la manipulación y el acceso no autorizado.
- Desarrollar un software bien protegido: diseñar, crear y probar software para que presente pocas vulnerabilidades en el momento de su lanzamiento.
- Responder a las vulnerabilidades: Detectar, evaluar y corregir los problemas en las versiones publicadas de software y, a continuación, evitar que se repitan.
Por qué el SSDF pasó a ser un requisito de contratación pública
El marco pasó de ser una buena práctica a convertirse en un requisito de compra debido a una serie de medidas políticas federales. La Orden Ejecutiva 14028 (12 de mayo de 2021) ordenó a los organismos que endurecieran los requisitos en materia de seguridad de la cadena de suministro de software .
El Memorándum M-22-18 de la OMB (14 de septiembre de 2022), modificado por el M-23-16 (9 de junio de 2023), fue más allá. Estableció que la conformidad certificada con el SSDF era una condición previa para que las agencias federales pudieran utilizar los productos « software » incluidos en el ámbito de aplicación. En la práctica, los fabricantes tenían que firmar antes de que las agencias pudieran seguir comprando. Posteriormente, el Decreto Ejecutivo 14306 (6 de junio de 2025) derogó las disposiciones del Decreto Ejecutivo 14144 relativas a las certificaciones y a la redacción de los contratos del FAR, y ordenó al NIST que actualizara el SSDF.
La situación actual es más matizada. El memorándum M-26-05 de la OMB (23 de enero de 2026) derogó los memorandos M-22-18 y M-23-16, sustituyendo la obligación aplicable a todo el Gobierno por un enfoque basado en el riesgo y dirigido por los organismos. El uso del formulario común de la CISA es ahora opcional para las agencias, en lugar de obligatorio. Las agencias conservan la facultad discrecional de solicitar certificaciones y SBOM, y el caso 2023-002 del FAR sigue abierto.
¿A quién le tiene que importar (y no solo a los proveedores federales)?
Hay tres grupos que se ven directamente afectados por esto. En primer lugar, cualquier productor de software que venda a organismos federales. En segundo lugar, el director general o la persona autorizada que firme efectivamente el contrato.
En tercer lugar, y cada vez con mayor frecuencia, los compradores comerciales. Los bancos, las organizaciones sanitarias y las grandes empresas ahora hacen referencia al SSDF en los cuestionarios de riesgo de los proveedores. Este marco se ha convertido en un vocabulario común para el desarrollo seguro, por lo que su alcance va mucho más allá de los contratos federales.
La certificación es una firma, no una casilla de selección
Los productores firman el «Formulario de certificación de desarrollo seguro de Software » gestionado por la CISA. El director general o un directivo designado certifica, según su leal saber y entender, que se aplican dichas prácticas.
Esto es lo que complica aún más las cosas: no existe ningún sistema de certificación por parte de terceros. Ningún auditor expide un certificado que zanjara la cuestión. La conformidad se basa íntegramente en las pruebas que el fabricante conserva internamente.
El formulario advierte de que facilitar de forma deliberada información falsa o engañosa puede constituir una infracción del artículo 1001 del título 18 del Código de los Estados Unidos (18 U.S.C. § 1001), una norma penal, y que una declaración falsa también puede dar lugar a responsabilidades civiles en virtud de la Ley de Reclamaciones Falsas. Esto convierte una laguna en la documentación en un riesgo legal, por lo que la prueba que respalda la firma es tan importante como la propia firma.
Las prácticas que tienen mayor peso criptográfico para el SSDF
Hay varias prácticas que dependen directamente de la firma de código y la gestión de claves. Son precisamente estas las que los evaluadores pueden verificar mediante pruebas criptográficas, por lo que merecen una atención especial.
P.D. 1: proteger todas las formas de código contra la manipulación
PS.1 exige a los productores que protejan los artefactos de código fuente, compilación y lanzamiento frente a modificaciones no autorizadas. Esto implica aplicar controles de acceso y medidas de protección de la integridad a lo largo de todo el proceso. Las confirmaciones firmadas y los sistemas de compilación protegidos te proporcionan pruebas de integridad que podrás demostrar posteriormente.
P.D. 2: ofrecer a los consumidores una forma de verificar la integridad de la versión
PS.2 exige un mecanismo que permita a los usuarios comprobar que una versión coincide con lo que ha publicado el desarrollador. En la práctica, se firma criptográficamente cada artefacto de la versión y se publica el material de verificación. Cualquier persona que descargue el archivo « software » puede entonces comprobar la firma antes de confiar en el código.
PS.2 y PO.5: proteger las propias claves de firma
La fiabilidad de una firma depende de la clave que la respalda. La norma PS.2 exige una revisión periódica del proceso de firma de código, lo que incluye la renovación, rotación, revocación y protección de los certificados. La norma PO.5 aborda los entornos seguros en los que se lleva a cabo la firma, incluidos los entornos de compilación y distribución.
Esto implica generar y almacenar claves privadas en hardware, restringir quién puede firmar y revisar periódicamente la renovación, rotación y revocación de las mismas. Si se roba una clave de firma, un atacante podría firmar malware que parezca suyo, por lo que este control le protege tanto a usted como a sus clientes.
PW.6: Fortalecimiento de la compilación
El PW.6 se titula «Configurar los procesos de compilación, interpretación y construcción para mejorar la seguridad de los ejecutables». Se suma a la firma de artefactos, en lugar de sustituirla.
Su objetivo es reducir el número de vulnerabilidades y el coste de su corrección, eliminando los defectos antes de que comiencen las pruebas. Consta de dos tareas. En primer lugar, utilizar un compilador, un intérprete y herramientas de compilación que ofrezcan funciones que mejoren la seguridad. En segundo lugar, decidir qué funciones utilizar, configurarlas y aplicar las configuraciones aprobadas de forma coherente.
RV.2: SBOM firmadas y trazabilidad para una respuesta rápida
Cuando se da a conocer una vulnerabilidad, la rapidez depende de saber exactamente qué se ha comercializado. RV.2 recomienda el uso de listas de materiales ( Software , SBOM) firmadas y certificados de procedencia. Las SBOM firmadas permiten identificar rápidamente los componentes afectados y demostrar que el inventario es auténtico, lo que acorta el plazo entre la divulgación y la corrección.
Elaboración del expediente probatorio que respalda la certificación
El formulario firmado es solo una pequeña parte del proceso de conformidad. Lo que lo respalda es un conjunto de pruebas que demuestre que las prácticas se llevan a cabo realmente. Reúne estos seis elementos y presenta las pruebas correspondientes a cada uno de ellos desde el principio:
- Paquete de pruebas justificativas: Conserva el formulario firmado junto con los documentos que acrediten cada una de las afirmaciones que en él se recogen.
- Protección de las claves de firma de código: Demostrar que las claves privadas se almacenan en hardware y que el acceso a la firma está controlado.
- Verificación de la integridad de una versión: Demostrar un mecanismo eficaz que los usuarios puedan utilizar para verificar una versión.
- Control de acceso al proceso de compilación: Conservar los registros que demuestren quién ha podido acceder a la infraestructura de compilación y lanzamiento, y cuándo.
- SBOM firmada y procedencia: Elaborar inventarios de componentes firmados y datos de procedencia para las versiones publicadas de software.
- Autoevaluación sincera: pregúntate si estas pruebas resistirían una impugnación y, a continuación, subsana cualquier deficiencia que detectes.
Cómo Keyfactor ayudarte Keyfactor
Keyfactor ofrece a los productores de « software » una forma de convertir estas prácticas en datos que proceden de un único sistema, en lugar de una docena de herramientas inconexas.
Keyfactor AgileSec es el primer paso fundamental. Detecta y cataloga los activos criptográficos presentes en el código, los procesos de compilación y la infraestructura en la nube, para que puedas ver dónde se encuentran realmente las claves de firma y los certificados. AgileSec también genera datos firmados de SBOM y procedencia compatibles con RV.2, además de informes centralizados para el paquete de pruebas de certificación.
EJBCA emite y gestiona los certificados que sustentan la firma de confianza. Proporciona la autoridad de certificación y los certificados de firma de código que sirven de base para las identidades de firma a lo largo de toda la cadena de compilación y lanzamiento.
Keyfactor SignServer centraliza el proceso de firma. Firma las confirmaciones, las versiones, los resultados de compilación y las imágenes de contenedor desde un único sistema, lo que se corresponde directamente con PS.1, PS.2, PS.3 y las compilaciones reforzadas de PW.6. Para los equipos de CI/CD distribuidos, Keyfactor Signum integra la firma de código en los flujos de trabajo existentes de los desarrolladores.
Keyfactor Command automatiza el ciclo de vida de los certificados y las claves que exigen las normas PO.3 y PS.2. Gestiona el ciclo de vida de las claves de firma de código y los certificados, y genera los informes centralizados que alimentan su paquete de pruebas de acreditación.
Combina todo esto con el « Keyfactor » de Trust Control Plane, un único sistema de registro que supervisa, aprovisiona, coordina y gestiona las claves de firma y las pruebas. Cuando las pruebas que respaldan tu certificación provienen de un único lugar, defenderlas se convierte en una tarea rutinaria en lugar de un proceso complicado.
Hacer del SSDF una capacidad firmada y demostrable
El cumplimiento de las normas SSDF es una capacidad operativa, no un proyecto puntual. Las claves se renuevan, los flujos de datos cambian y surgen vulnerabilidades, por lo que la documentación debe mantenerse actualizada.
La ventaja es el efecto multiplicador. La misma infraestructura de firma y pruebas que respalda una certificación federal también da respuesta a los cuestionarios de seguridad comercial de bancos, el sector sanitario y las empresas compradoras. Basta con crearla una sola vez para cumplir con ambos requisitos.
Empieza ya: haz un inventario de cómo se firman tu código y tus versiones, comprueba cómo se protegen las claves de firma y recopila pruebas que puedas defender en caso de ser objeto de un escrutinio. Solicitar una demo Descubre cómo « Keyfactor » convierte el desarrollo seguro en una capacidad firmada y demostrable.
¿Tienes alguna pregunta sobre el SSDF? Tenemos las respuestas.
¿Qué es la norma NIST SP 800-218 (SSDF)?
La norma NIST SP 800-218 es el Marco de Desarrollo Seguro de Software (Secure Software Development Framework, SSDF), un conjunto de prácticas basadas en resultados que se agrupan en cuatro categorías: preparar la organización, proteger el software, crear software bien protegidas y responder a las vulnerabilidades. Describe lo que debe lograrse con el desarrollo seguro, en lugar de prescribir una lista de comprobación fija.
¿Quién debe cumplir con el SSDF?
Cualquier productor software que venda al Gobierno federal puede verse obligado adeclarar por sí mismo que sigue las prácticas del SSDF. Los compradores comerciales, como bancos, organizaciones sanitarias y grandes empresas, hacen referencia cada vez más al SSDF en los cuestionarios de riesgo de proveedores, por lo que su alcance se extiende mucho más allá de los contratos federales.
¿Qué es el formulario de certificación de desarrollo seguro de la CISA « Software »?
Es el formulario que firman los « software » para declarar que siguen las prácticas del SSDF. Las directivas M-22-18 y M-23-16 exigían a los organismos que lo recabaran. La OMB derogó ambas en enero de 2026, por lo que el uso del formulario queda ahora a discreción de cada organismo. Cuando un organismo lo solicite, lo firmará el director general o una persona designada que sea un empleado con autoridad para vincular a la empresa, certificando, según su leal saber y entender, que se aplican dichas prácticas.
¿Es la declaración del SSDF jurídicamente vinculante?
Sí. Se trata de una declaración formal con relevancia jurídica, y se espera que el firmante conserve pruebas suficientes para defenderla en caso de que sea impugnada. Una declaración falsa puede suponer una exposición a responsabilidades en virtud de la Ley de Reclamaciones Falsas, lo que eleva las consecuencias más allá de una simple falta de cumplimiento.
¿Qué relación hay entre la firma de código y el SSDF?
El PS.1 protege todo tipo de código contra la manipulación mediante la firma de confirmaciones, la firma de código y los hash. El PS.2 exige un mecanismo de verificación de la integridad de las versiones que utilice la firma de código, los hash publicados y la revisión periódica de la renovación, rotación y revocación de certificados, así como la protección de claves. El PS.3 se ocupa del archivo de las versiones junto con sus datos de integridad y procedencia.
¿Qué pruebas buscan los evaluadores?
Buscanlas pruebas que respaldan la certificación, no solo el formulario firmado: claves protegidas de firma de código, un mecanismo operativo de verificación de la integridad de las versiones, un control de acceso registrado sobre la infraestructura de compilación, y SBOM y procedencia firmados. La cuestión fundamental es si esas pruebas se mantendrían en caso de que se impugnara la certificación.
¿Requiere el SSDF una certificación de terceros?
No. El marco no cuenta con ningún sistema formal de certificación de terceros, por lo que la demostración del cumplimiento se basa en pruebas y declaraciones internas, y no en un certificado de auditoría. Esto hace que recaiga sobre la organización la responsabilidad de conservar pruebas justificables.
¿Cuál es el primer paso práctico para cumplir con los requisitos del SSDF?
Empieza por conocer cómo se firman el código y las versiones, y cómo se protegen las claves de firma. A continuación, formaliza un proceso de compilación firmado y centraliza la documentación. Crear esa capacidad una sola vez te permitirá responder tanto a las certificaciones federales como a los cuestionarios de seguridad comerciales desde el mismo sistema de registro.
