Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- El Marco de Desarrollo Seguro de Software (SSDF) del NIST (Instituto Nacional de Estándares y Tecnología) recomienda que se sigan verificando los componentes de terceros, incluidos los de código abierto, en función de tus propios requisitos.
- Un análisis de vulnerabilidades es solo una parte del proceso de verificación, y los ejemplos del SSDF también abarcan el estado de mantenimiento y la integridad.
- En el caso del software de código abierto, normalmente no hay ningún proveedor obligado a demostrar que un componente cumple tus requisitos, por lo que es tu equipo el que recopila esa documentación.
- Esas pruebas incluyen la procedencia, es decir, un registro del origen y los cambios de cada componente. Una simple lista de componentes no basta para reflejarlo.
- La verificación se reduce a cuatro aspectos: requisitos, pruebas, medidas de seguridad previas a la compilación y un plan para los componentes sin mantenimiento. Empieza por los requisitos.
Si un cliente te pregunta cómo verificas las bibliotecas de código abierto de tu producto, es probable que el Marco de Desarrollo de Software Seguro (SSDF) del NIST haya influido en la formulación de esa pregunta. Una de sus tareas, la PW.4.4 del grupo «Producir software bien protegido», exige a los productores que verifiquen los componentes de terceros —incluidos los de código abierto — en función de los requisitos que ellos mismos definan.
Un informe de análisis sin incidencias recoge las vulnerabilidades conocidas, pero los ejemplos de PW.4.4 también indican si un componente sigue recibiendo mantenimiento y si se puede confirmar su integridad. La tarea en sí no define el término «verificar», ni menciona ninguna herramienta concreta, ni especifica qué pruebas hay que conservar.
Eso te deja a ti la tarea de redactar los requisitos y presentar la prueba. Y, en el caso de los componentes de código abierto, normalmente no hay ningún contrato que regule la biblioteca, por lo que ningún proveedor está obligado a facilitarte esa prueba.
La situación actual del SSDF del NIST en 2026
El NIST publica el SSDF como Publicación Especial (SP) 800-218. La versión final actual es «Marco de desarrollo de software seguro (SSDF), versión 1.1: Recomendaciones para mitigar el riesgo de vulnerabilidades de software», de febrero de 2022. Clasifica sus prácticas en cuatro grupos, cada uno con un código de dos letras: Preparar la organización (PO), Proteger el software (PS), Producir software bien protegido (PW) y Responder a las vulnerabilidades (RV). Cada práctica tiene un identificador, como PW.4, y a sus tareas se les añade un número adicional, como PW.4.4.
La versión 1.1 está dirigida a los productores y adquirentes de software, y establece que las organizaciones no gubernamentales pueden utilizarla de forma voluntaria. Describe sus prácticas como base para la planificación basada en el riesgo y aclara que no pretenden ser una lista de verificación. El NIST presenta el SSDF como un vocabulario común que los adquirentes pueden utilizar con sus proveedores, por lo que un requisito suele llegar a ti a través de la política de un comprador o de un contrato que haga referencia al mismo.
Nota: El NIST publicó un borrador público inicial de la SP 800-218, Revisión 1, «Marco de desarrollo de software seguro» (SSDF), versión 1.2, el 17 de diciembre de 2025, en respuesta a la Orden Ejecutiva 14306. A fecha de octubre de 2026, la versión 1.1 sigue siendo la versión definitiva. El borrador mantiene la práctica PW.4.4 y la tarea de procedencia, PS.3.2, con la misma numeración y redacción, y añade dos nuevas prácticas, junto con texto de ejemplo, bajo la práctica PW.4.4. Este artículo se basa en la versión 1.1.
Lo que establece el punto PW.4.4 y lo que deja sin precisar
La norma PW.4.4 exige a los productores que verifiquen que los componentes de software adquiridos —ya sean comerciales, de código abierto o de terceros— cumplan los requisitos que la organización defina a lo largo de todo su ciclo de vida. Esa redacción deja en tus manos la definición de los requisitos y menciona expresamente los componentes de código abierto. Además, mantiene la verificación activa mientras se utilice el componente, mucho más allá de una revisión puntual en el momento de su adopción.
Además, el NIST ofrece siete ejemplos teóricos de implementación.
| Ejemplo de PW.4.4 | Qué incluye | Fundamentos |
|---|---|---|
| Ejemplos 1 y 2: comprobar si existen vulnerabilidades conocidas públicamente que los proveedores aún no hayan solucionado, incluida la detección automática en la cadena de herramientas | Defectos conocidos del componente | SP 800-218, versión 1.1, teórica |
| Ejemplo 3: utilizar los resultados ya disponibles de los servicios comerciales de verificación | Resultados de la evaluación externa | SP 800-218, versión 1.1, teórica |
| Ejemplo 4: confirmar que el componente sigue recibiendo mantenimiento activo y que no ha llegado al final de su vida útil (EOL), lo que incluye que se estén corrigiendo las vulnerabilidades recién descubiertas | Estado de la asistencia técnica y corrección de nuevas vulnerabilidades | SP 800-218, versión 1.1, teórica |
| Ejemplo 5: elaborar un plan de acción para los componentes que ya no reciben mantenimiento o que pronto dejarán de estar disponibles | Tu respuesta cuando finalice el servicio de asistencia | SP 800-218, versión 1.1, teórica |
| Ejemplo 6: confirmar la integridad mediante firmas digitales u otros mecanismos | Integridad del artefacto | SP 800-218, versión 1.1, teórica |
| Ejemplo 7: revisar, analizar o probar el código | El código en sí | SP 800-218, versión 1.1, teórica |
La comprobación de vulnerabilidades conocidas abarca dos de esos siete ejemplos, por lo que un informe de análisis por sí solo resuelve parte de la tarea. Un análisis de fallos conocidos no suele indicar si un artefacto está intacto o si alguien sigue manteniendo el componente, y los ejemplos 4 y 6 abordan esas cuestiones.
El borrador 1.2 del SSDF añade un octavo ejemplo en el apartado PW.4.4: revisar periódicamente las bibliotecas de terceros para detectar cambios de propiedad y evaluar el impacto de cada cambio. Un análisis de vulnerabilidades conocidas no suele detectar un cambio de propiedad, por lo que este ejemplo requeriría una comprobación específica.
En el caso de un componente sin mantenimiento, el plan de acción del Ejemplo 5 suele adoptar una de estas tres formas: sustituirlo, aplicar un parche a la versión que utilizas o aceptar el riesgo por escrito. La opción intermedia implica que alguien tiene que escribir y probar la corrección, y ese alguien eres tú, a menos que hayas acordado que lo haga otra persona.
El software de código abierto a menudo no cuenta con un proveedor que te facilite pruebas
El punto PO.1.3, relativo a las funciones del SSDF en lo que respecta a las relaciones con los proveedores, abarca la comunicación de los requisitos a terceros que suministran componentes comerciales. Entre los ejemplos que se citan se incluyen la incorporación de requisitos en los contratos, la exigencia a los proveedores de que certifiquen que su software cumple dichos requisitos y la exigencia de datos de procedencia y mecanismos de verificación de la integridad para todos los componentes de su software.
El código abierto que distribuyes se rige por la norma PW.4.4, pero no por la PO.1.3, por lo que el SSDF te pide que lo verifiques sin que exista una tarea para acordar las condiciones con sus autores. En la práctica, una biblioteca suele venir sin contrato, por lo que normalmente no hay ninguna contraparte obligada a facilitarte pruebas de procedencia o integridad. Alguien de tu equipo tiene que elaborarlas o recopilarlas.
Tus requisitos son lo primero, y PO.1.1 es el punto de partida que utiliza el propio SSDF para redactarlos. Su segundo ejemplo consiste en definir políticas para garantizar la seguridad de tus procesos de desarrollo, incluidas las relativas al código abierto y a otros componentes de terceros. Redáctalas antes de evaluar cualquier herramienta. PW.4.4 evalúa los componentes en función de tus requisitos, y las comprobaciones predeterminadas de una herramienta suelen sustituir a dichos requisitos si te saltas este paso.
Un breve documento de requisitos puede abordar qué actividades de mantenimiento son aceptables, qué ocurre cuando un componente deja de contar con soporte por parte de sus proveedores, quién aprueba una excepción y cómo se verifica la integridad. El quinto ejemplo del punto PO.1.3 describe un proceso para gestionar los requisitos que un componente no cumple, incluida la revisión periódica de las excepciones aprobadas. Se puede aplicar el mismo proceso a los componentes de código abierto.
Según el SSDF: PW.4.1, la tarea del SSDF relativa a la adquisición de componentes incluye dos ejemplos que describen las medidas que tu equipo puede adoptar sin recurrir a un proveedor. Una de ellas consiste en obtener información sobre la procedencia, como una lista de materiales de software (SBOM) o un análisis de composición, para cada componente. La otra consiste en alojar componentes de código abierto autorizados y verificados en uno o varios repositorios.
Sin un proveedor intermedio, normalmente no hay nada entre la versión publicada por el responsable del mantenimiento y tu compilación, a menos que añadas una medida de seguridad. Las opciones incluyen verificar las firmas cuando los editores las faciliten, recompilar a partir del código fuente o filtrar lo que llega antes de que acceda a tu entorno de compilación. Los ejemplos teóricos del SSDF mencionan algunos de ellos, como las firmas en PW.4.4 y la compilación a partir del código fuente en PW.4.1.
La procedencia según el apartado PS.3.2 es algo más que una lista de componentes
La norma PS.3.2 forma parte del grupo «Protect the Software» de la SSDF. En ella se pide a los fabricantes que recopilen, protejan, mantengan y compartan los datos de procedencia de todos los componentes de cada versión, y se menciona la SBOM como un ejemplo de dónde pueden almacenarse dichos datos. En el caso de los componentes de código abierto, normalmente no hay ningún proveedor obligado a facilitártelos.
El NIST define la procedencia —tomando como referencia la Publicación Especial 800-53— como la cronología del origen, el desarrollo, la propiedad, la ubicación y los cambios de un componente. Según esa definición, una lista de nombres y versiones indica qué contiene una versión, mientras que la cronología indica de dónde procede cada elemento y qué ha sucedido con él. Una lista de componentes no incluye automáticamente esta segunda información, por lo que debes comprobar si tu SBOM registra ese historial o solo la lista.
Los ejemplos que figuran en PS.3.2 incluyen compartir los datos con los adquirentes y con tus propios equipos de respuesta, proteger su integridad para que los destinatarios puedan verificarlos y actualizarlos cada vez que se actualice un componente. PS.3.2 dice «todos los componentes» y no utiliza la palabra «transitivo». Aplicarlo a dependencias que nunca has elegido directamente es una inferencia, pero una que se deduce de la palabra «todos». Decide si las dependencias transitivas entran dentro del ámbito de aplicación en función de tus requisitos y deja constancia de la decisión.
Hay otros dos términos que aparecen junto con las SBOM. SLSA (Supply-chain Levels for Software Artifacts) es una especificación independiente sobre seguridad de la cadena de suministro, y su «Build Level 3» describe una plataforma de compilación reforzada que protege contra la manipulación durante el proceso de compilación. Los documentos VEX (Vulnerability Exploitability eXchange), tal y como los describe la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), indican el estado de un producto respecto a una vulnerabilidad determinada, por ejemplo, si está afectado, no está afectado o se ha corregido. Ambos proporcionan pruebas para las tareas del SSDF. La procedencia SLSA registra quién compiló un paquete, con qué proceso y a partir de qué entradas, lo cual forma parte del historial que el PS.3.2 exige que se conserve. Un registro VEX muestra si una vulnerabilidad conocida afecta a un componente, que es lo que se pide en el primer ejemplo de PW.4.4.
Qué preguntaba el formulario de certificación federal sobre los componentes
Anteriormente, los compradores federales solían solicitar información directamente sobre los componentes de terceros. En virtud de los memorandos M-22-18 y M-23-16 de la Oficina de Gestión y Presupuesto (OMB), las agencias debían obtener certificaciones de los fabricantes de software, y la CISA y la OMB publicaron el «Formulario de certificación de desarrollo seguro de software » con ese fin el 11 de marzo de 2024.
En la sección III del formulario, se solicita a los productores que certifiquen que han realizado un esfuerzo de buena fe para mantener cadenas de suministro de código fuente fiables, utilizando herramientas automatizadas o procesos equivalentes que aborden la seguridad de los componentes de terceros y gestionen las vulnerabilidades relacionadas. Asimismo, se les pide que certifiquen que mantienen la procedencia de los componentes de terceros «en la mayor medida posible». El apéndice del formulario establece la correspondencia entre estos puntos y las tareas del SSDF, entre las que se incluyen PW.4.4 y PS.3.2.
El formulario no incluye los componentes de código abierto y propietarios de terceros integrados en el producto que utiliza una agencia. No obstante, los productores que utilizan dichos componentes siguen certificando que han seguido los pasos descritos en la Sección III para reducir el riesgo que supone depender de ellos.
El 23 de enero de 2026, el memorándum M-26-05 de la OMB derogó los memorandos M-22-18 y M-23-16. Las agencias pueden seguir utilizando el formulario y exigir SBOM en sus contratos, y el memorándum cita la norma SP 800-218 como referencia que pueden utilizar. En él se afirma que «no existe un método universal y válido para todos» a la hora de proteger el software y el hardware que utilizan las agencias, por lo que se deja en manos de cada agencia el establecimiento de políticas de garantía que se adapten a su perfil de riesgo.
| Documento | Lo que dice | Situación actual | Fundamentos |
|---|---|---|---|
| SP 800-218, versión 1.1 | Define PW.4.4 y PS.3.2 | Final, febrero de 2022 | Directrices del NIST |
| SP 800-218, borrador de la revisión 1 (SSDF 1.2) | Mantiene ambas tareas y añade material nuevo | Borrador inicial para el público | Borrador de directrices del NIST |
| OMB M-22-18 y M-23-16 | Se exigió a los organismos que obtuvieran las certificaciones | Derogado el 23 de enero de 2026 | Política de la OMB |
| Formulario de certificación | Los productores dan fe de las prácticas inspiradas en el SSDF | Opcional para agencias | Formulario de la agencia (CISA y OMB) |
| OMB M-26-05 | Las agencias establecen sus propias políticas de garantía | Actual | Política de la OMB |
Tras la derogación de las normas M-22-18 y M-23-16, el hecho de que un comprador pregunte cómo se verifican los componentes o cómo se rastrea su procedencia depende de la política y del contrato de dicho comprador.
Determinar qué significa la verificación para tus dependencias
En la práctica, la verificación se reduce a cuatro decisiones: qué requisitos debe cumplir un componente, qué pruebas se conservan, qué se interpone entre una versión de origen y tu compilación, y qué hacer cuando un responsable de mantenimiento de origen deja de dar soporte a ese componente. Las dos primeras son cuestiones de política que solo tu equipo puede abordar. Las dos últimas son aquellas en las que las herramientas pueden hacerse cargo del trabajo repetitivo.
SecureChain, de TuxCare, se sitúa entre las versiones originales y tu compilación. Analiza el código fuente de los paquetes de código abierto en busca de malware y patrones sospechosos, recompila los paquetes a partir de ese código fuente en entornos aislados y reforzados, y sigue aplicando parches a los mismos en virtud de un acuerdo de nivel de servicio mientras el proyecto original esté activo. El servicio «Endless Lifecycle Support» (ELS) sigue proporcionando correcciones una vez finalizado el mantenimiento del proyecto original, cubriendo así la opción de «aplicar parches a la versión que ejecutas» descrita anteriormente. La cobertura abarca JavaScript, Python, Java, Go, Rust y PHP. TuxCare también proporciona SBOM, registros VEX y procedencia SLSA de nivel 3 para cada paquete.
Si estás pensando en cómo gestionar los paquetes de código abierto que no han sido revisados o que ya no reciben mantenimiento, pregúntanos qué cubre SecureChain.
PREGUNTAS FRECUENTES
¿Qué es el SSDF del NIST?
El SSDF del NIST es el Marco de Desarrollo Seguro de Software, que el NIST, la agencia estadounidense de normalización, publica como Publicación Especial (SP) 800-218. Agrupa las prácticas de desarrollo seguro en cuatro categorías: «Preparar la organización», «Proteger el software», «Producir software bien protegido» y «Responder a las vulnerabilidades». La versión final actual es la 1.1, de febrero de 2022.
¿A quién va dirigido el SSDF del NIST?
Los productores de software —como los proveedores comerciales y los equipos de desarrollo internos— y los adquirentes de software —entre los que se incluyen las agencias federales y otras organizaciones— constituyen los dos públicos principales. El NIST, la agencia estadounidense de normalización, afirma que las organizaciones no gubernamentales pueden utilizar el Marco de Desarrollo de Software Seguro (SSDF) de forma voluntaria. Una empresa que utilice componentes de código abierto se considera un productor.
¿Cubre el SSDF el software de código abierto?
En parte. En el Marco de Desarrollo Seguro de Software (SSDF), tanto la tarea de verificación de componentes de terceros (PW.4.4) como la de adquisición de los mismos (PW.4.1) mencionan los componentes de código abierto. La tarea de comunicar los requisitos a los proveedores (PO.1.3) solo menciona componentes comerciales. El NIST (la agencia de normalización de EE. UU.) incluye una referencia del SSDF para el software de código abierto entre las medidas que está barajando, pero, a fecha de octubre de 2026, aún no la ha publicado.
¿Qué son los ejemplos de aplicación hipotéticos en el SSDF?
En el Marco de Desarrollo Seguro de Software (SSDF), los ejemplos de implementación hipotéticos son herramientas, procesos o métodos de referencia que podrían ayudar a llevar a cabo una tarea. El NIST, el organismo estadounidense encargado de las normas, afirma que no es obligatorio utilizar ningún ejemplo ni combinación concreta, y que no son las únicas opciones disponibles.
¿Certifica el NIST algo en el marco del SSDF?
El NIST, la agencia estadounidense encargada de las normas, publica el Marco de Desarrollo de Software Seguro (SSDF) a modo de guía, y los materiales del SSDF no describen ningún programa de certificación. El formulario de certificación federal admite tanto la autocertificación del fabricante como una evaluación realizada por terceros, y la Oficina de Gestión y Presupuesto (OMB) ya no exige la presentación de dicho formulario en todo el ámbito gubernamental.
