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
- Desde el 13 de julio de 2026, las licitaciones en el ámbito de la defensa pueden exigir únicamente autoevaluaciones de nivel 1 o nivel 2, mientras que la fase 2 sigue suspendida.
- Ninguno de los 110 requisitos del Nivel 2 menciona el código abierto, pero el software es un activo, por lo que los paquetes de código abierto instalados en los sistemas incluidos en el ámbito de aplicación se tratan como el resto.
- Hay cuatro requisitos que deben cumplir: inventario, software instalado por el usuario, análisis de vulnerabilidades y corrección de fallos.
- Tres de ellos son requisitos de cinco puntos, por lo que cualquier deficiencia en cualquiera de ellos no puede aplazarse mediante un plan de acción y hitos.
Los requisitos de cumplimiento de la Certificación del Modelo de Madurez en Ciberseguridad (CMMC) no establecen ninguna exigencia específica respecto al código abierto. Sin embargo, los 110 requisitos que establece el CMMC para los contratistas que manejan información no clasificada controlada (CUI) siguen afectando a los paquetes de código abierto de su compilación. Esto sigue siendo así incluso después de que el Pentágono suspendiera la Fase 2 del programa CMMC el 13 de julio de 2026, el paso que habría convertido la evaluación por parte de terceros en una condición para la adjudicación de los contratos correspondientes. Esos mismos 110 requisitos siguen siendo la base para las autoevaluaciones.
Qué abarcan los requisitos de cumplimiento de la CMMC
El CMMC tiene tres niveles. El nivel que te corresponde depende de la información de que se trate y de los requisitos establecidos en tu contrato o licitación.
| Nivel | Información | Requisitos | ¿Quién evalúa? |
|---|---|---|---|
| Nivel 1 | Información sobre contratos federales (FCI) | 15 requisitos básicos del Reglamento Federal de Adquisiciones | Tú, mediante una autoevaluación anual |
| Nivel 2 | CUI | 110 requisitos de la norma SP 800-171, revisión 2, del Instituto Nacional de Estándares y Tecnología (NIST) | Usted, o una organización de evaluación externa del CMMC (C3PAO), cuando así lo exija la convocatoria (suspensa por el momento) |
| Nivel 3 | CUI en determinados programas | 24 requisitos seleccionados de la norma NIST SP 800-172, además de los del Nivel 2 | La Agencia de Gestión de Contratos de Defensa (DCMA) |
Los 110 requisitos del Nivel 2 abarcan 14 categorías, desde el control de acceso hasta la integridad de los sistemas y de la información.
Situación actual de los requisitos de cumplimiento de la CMMC en 2026
La norma del Suplemento del Reglamento Federal de Adquisiciones de Defensa (DFARS) que incorpora el CMMC a los contratos entró en vigor el 10 de noviembre de 2025, lo que marcó el inicio de la Fase 1. En el marco de la Fase 1, el Departamento de Defensa (DoD) incluye, cuando procede, el requisito de realizar una autoevaluación de Nivel 1 o Nivel 2 como condición para la adjudicación del contrato.
La fase 2, cuyo plazo vencía el 10 de noviembre de 2026, habría añadido las evaluaciones de nivel 2 realizadas por los C3PAO como condición para la adjudicación. El 13 de julio de 2026, el director de información del Departamento de Defensa la suspendió. Los gestores de programas ahora solo pueden exigir autoevaluaciones de nivel 1 o nivel 2, y los contratos que ya prevean una evaluación realizada por una C3PAO o por el Gobierno deberán modificarse en el próximo periodo de opción o cambio administrativo.
La normativa del programa en sí no se ha revisado desde que se comunicó la suspensión mediante notas informativas, por lo que sigue describiendo las cuatro fases originales. Los cambios se publican en la página web sobre el CMMC del director de sistemas de información del Departamento de Defensa.
Por ahora, los 110 requisitos constituyen el punto de encuentro, y el código abierto se integra a través de ellos.
Lo que establece la norma sobre los componentes de código abierto
Los 110 requisitos de Nivel 2 son los que figuran en la norma NIST SP 800-171, Revisión 2, y la normativa del programa establece que son idénticos. Desde entonces, el NIST ha sustituido la Revisión 2 por la Revisión 3, pero el CMMC sigue utilizando la Revisión 2, al igual que la guía de evaluación del Departamento de Defensa (DoD). En la práctica, esto significa que la versión de los requisitos que se aplica a sus paquetes de código abierto es el texto de la Revisión 2, y no el de la Revisión 3.
Cada uno de los 110 requisitos va acompañado de dos elementos en los documentos del NIST y del Departamento de Defensa (DoD): un conjunto de objetivos de evaluación (una lista de verificación de las condiciones que deben cumplirse para que el requisito se considere cumplido) y una explicación (texto explicativo que describe la intención, pero que no constituye en sí mismo un requisito).
La guía de evaluación de Nivel 2 pide a quienes realizan la autoevaluación que utilicen los mismos criterios que emplearía un evaluador externo y que no consideren lo que dice el personal en las entrevistas como prueba de lo que realmente hace el sistema. La sección de puntuación de la norma establece el criterio de las pruebas: los borradores, los documentos de trabajo y las políticas no aprobadas no cuentan. En el caso del código abierto, eso significa que un borrador de inventario o una política de escaneo que nadie haya aprobado no cuenta como prueba.
Ninguna de las 110 declaraciones de requisitos menciona el código abierto ni hace referencia a las listas de materiales de software (SBOM), la procedencia o la cadena de suministro. El software se incluye a través de las definiciones. En el CMMC, el software es un activo, por lo que los paquetes de código abierto de un sistema incluido en el ámbito de la evaluación están sujetos a los mismos requisitos que el resto del software de dicho sistema. Lo que determina que un sistema entre en el ámbito de aplicación es lo que hace con la CUI: los activos que la procesan, almacenan o transmiten se evalúan en función de todos los requisitos del Nivel 2. El ámbito de aplicación también incluye los activos que protegen esos sistemas, como los cortafuegos y los servicios de identidad. Un servidor de compilación o una estación de trabajo de desarrollador que nunca entre en contacto con la CUI puede quedar fuera de dicho ámbito, lo cual es la decisión sobre el alcance que el requisito relativo al software instalado por el usuario determinará más adelante. La guía de alcance del Departamento de Defensa (DoD) ofrece un desglose completo.
El riesgo de la cadena de suministro se menciona en dos requisitos de nivel 3, pero el nivel 3 es un nivel independiente con su propia evaluación dirigida por el Gobierno, por lo que ninguno de esos requisitos se aplica en el nivel 2.
Cuatro prácticas que abarcan tu árbol de dependencias
Mantén un inventario de lo que hay en el sistema (CM.L2-3.4.1). Debes mantener una lista del hardware y el software que componen cada sistema incluido en el ámbito de aplicación, incluidos los números de versión, y mantenerla actualizada a medida que el sistema cambie. El software de código abierto entra en juego aquí porque los paquetes de tu aplicación, incluidos aquellos incorporados indirectamente por otros paquetes, son software con números de versión. Si no figuran en la lista, esta está incompleta.
Controla lo que instalan los usuarios (CM.L2-3.4.9). Necesitas una política que establezca qué software pueden instalar los usuarios, una forma de hacerla cumplir y una forma de comprobar qué se ha instalado. El texto explicativo del NIST indica que la política puede prohibir el software «de origen desconocido o sospechoso», lo que es lo más cercano que el Nivel 2 llega a preguntar de dónde procede el software. Esa referencia al «origen» es una orientación, por lo que no puede utilizarse en tu contra por sí sola. El requisito en sí mismo —una política sobre lo que se instala, su aplicación y un registro de lo que se ha instalado— no es opcional, y si tu entorno de compilación se encuentra dentro del alcance de la evaluación, los paquetes que los desarrolladores añaden al mismo pueden considerarse instalaciones como cualquier otra.
Realiza análisis de vulnerabilidades de forma periódica (RA.L2-3.11.2). Debes analizar los sistemas y las aplicaciones con la frecuencia que tú mismo definas y ejecutar análisis adicionales cuando se anuncien nuevas vulnerabilidades. Los paquetes de código abierto de tus aplicaciones forman parte de lo que se analiza.
En conjunto, los requisitos relativos al inventario, al software instalado por el usuario y al análisis de vulnerabilidades abarcan lo que contiene tu compilación, lo que se permite incluir en ella y qué vulnerabilidades conocidas presenta. El cuarto requisito, la corrección oportuna de los fallos (SI.L2-3.14.1), se refiere a lo que ocurre una vez que se detecta una vulnerabilidad.
Por qué la corrección oportuna de fallos requiere una cifra que tú mismo definas
La norma SI.L2-3.14.1 establece que se deben identificar, notificar y corregir las fallas del sistema de manera oportuna, pero ni en el requisito, ni en el texto explicativo del NIST, ni en la guía de evaluación del Departamento de Defensa se especifica cuánto tiempo se considera «oportuno». Los tres documentos dejan en tus manos la fijación de un plazo, y el propio ejemplo de la guía indica un número concreto de días en función de la gravedad del fallo. Lo que tienes que demostrar es que has definido un plazo y que lo has cumplido.
Si no se cumple un plazo de forma habitual, queda constancia de ese retraso y, sin un plazo definido, no es posible completar la lista de verificación de la evaluación.
El caso más complicado es el de un componente que ya nadie mantiene, porque no se va a recibir ninguna corrección del desarrollador original. La guía considera que los parches aplicados, los cambios de configuración y las soluciones provisionales o medidas de mitigación son formas de corregir un fallo, por lo que dispones de más de una vía. Puedes sustituir el componente, pasar a una serie de versiones más reciente, implementar una solución alternativa o conseguir que se aplique una corrección a la versión que utilizas, y cada una de estas opciones deja un rastro diferente. La sustitución o la actualización suponen que existe un sustituto o una serie más reciente y que tu código puede admitir el cambio, por lo que la actualización no siempre es una opción, sobre todo cuando el componente se encuentra en un nivel profundo del árbol.
Qué puede y qué no puede cubrir un POA&M
Una evaluación da lugar a uno de estos tres resultados para cada requisito («CUMPLIDO», «NO CUMPLIDO» o «no aplicable») y a un estado general. El estado «definitivo» significa que se cumplen todos los requisitos. El estado «condicional» significa que aún quedan algunas deficiencias y que te has comprometido a subsanarlas.
La metodología de puntuación de la norma asigna 1, 3 o 5 puntos a cada requisito en función del daño potencial que podría causar una deficiencia. Se parte de 110 puntos y se pierden puntos por cada requisito que no se haya cumplido. De los cuatro requisitos que se aplican a tus paquetes de código abierto, tres (inventario, análisis de vulnerabilidades y corrección de fallos) valen cinco puntos cada uno, mientras que el software instalado por el usuario vale un punto.
Un plan de acción y hitos (POA&M) te permite dejar algunas deficiencias sin resolver tras una evaluación, y el artículo 170.21 del reglamento del programa lo limita de forma estricta. Solo se obtiene el estatus «Condicional» —el que permite un POA&M— con una puntuación mínima de 88 sobre 110.
Solo se pueden incluir en el plan los requisitos que valgan un punto, salvo el requisito de cifrado, que normalmente vale cinco puntos, pero que puede incluirse cuando se le asigna una puntuación de tres porque el cifrado utilizado no está validado según las Normas Federales de Procesamiento de la Información (FIPS). La norma también excluye del plan seis requisitos específicos, independientemente de la puntuación: el requisito relativo al plan de seguridad del sistema, dos que se refieren a las conexiones externas y a la información pública, y tres requisitos de acceso físico.
El hecho de dejar una brecha en el plan no modifica su resultado, que sigue siendo «NO CUMPLIDO» hasta que se resuelva.
Cualquier elemento que se incluya en el plan debe cerrarse y confirmarse en un plazo de 180 días; de lo contrario, el estado «Condicional» caducará. Ese plazo de 180 días para el cierre se aplica tanto a la autoevaluación de nivel 2 como a la evaluación realizada por terceros.
El inventario, el análisis de vulnerabilidades y la corrección de fallos son requisitos de cinco puntos, por lo que ninguno de ellos puede incluirse en el plan: o bien se cumplen en el momento de la evaluación o bien no se obtiene el estado «Condicional». El software instalado por el usuario es un requisito de un punto, por lo que una deficiencia en este aspecto puede incluirse en el plan siempre que la puntuación global siga siendo de al menos 88. Aun así, se considera «NO CUMPLIDO» y debe subsanarse en un plazo de 180 días.
Nota: El plan de acción operativo previsto en CA.L2-3.12.2 es un documento independiente. La norma lo define como un registro de las vulnerabilidades y deficiencias temporales y de cómo se van a subsanar, sin que se le asigne ningún plazo, y no es lo mismo que un POA&M de evaluación. El plazo de 180 días corresponde al POA&M.
Requisitos de cumplimiento de la CMMC para contratistas y pequeñas empresas
La norma del programa se aplica a los adjudicatarios de contratos y subcontratos del Departamento de Defensa (DoD) que procesan, almacenan o transmiten información clasificada (FCI) o información controlada (CUI) en el desempeño de su trabajo, y se extiende a los subcontratistas que realizan las mismas actividades. Los gestores de programas del DoD determinan el nivel CMMC para cada contratación en función de la información implicada y la importancia crítica del programa, por lo que dos empresas del mismo tamaño pueden acabar teniendo niveles diferentes. Dentro del Nivel 2, los 110 requisitos constituyen una lista única para todos.
La cuestión del tamaño queda patente en el propio razonamiento del Departamento de Defensa. El comunicado del 13 de julio, en el que se suspendía la Fase 2, indicaba que la revisión del departamento tiene como objetivo reducir las barreras para las pequeñas empresas y las empresas no tradicionales. Hasta que dicha revisión dé lugar a cambios, el régimen de autoevaluación es la medida de alivio vigente.
Dónde encaja SecureChain
SecureChain, de TuxCare, ofrece paquetes de código abierto que se someten a un proceso de verificación antes de llegar a tus manos y para los que se proporcionan parches mientras los utilices. Funciona como fuente única para JavaScript, Python, Java, Go, Rust y PHP.
Cada paquete se compila desde el código fuente en entornos aislados y se comprueba que no contenga malware ni código sospechoso; cualquier elemento que no supere la inspección se bloquea antes de que llegue a tu entorno. Los componentes activos se actualizan mediante un acuerdo de nivel de servicio. Cuando finaliza el mantenimiento del desarrollador original, el servicio Endless Lifecycle Support (ELS) sigue proporcionando correcciones para los componentes que ya no reciben mantenimiento.
Además, genera registros sobre lo que entrega, incluyendo la procedencia según el estándar «Supply-chain Levels for Software Artifacts» (SLSA) de nivel 3, una SBOM y datos del «Vulnerability Exploitability eXchange» (VEX).
Qué te pedirán que muestres
En el CMMC no aparece por ningún lado la expresión «código abierto». Sin embargo, cuando evalúes tu inventario de sistemas, los resultados de tus análisis y el registro de lo que se ha corregido y cuándo, todos los paquetes de código abierto de tus aplicaciones deben aparecer en cada uno de ellos. Si hoy no puedes aportar esos tres elementos para un paquete, esa es la carencia que debes subsanar en primer lugar.
PREGUNTAS FRECUENTES
¿Cuáles son los requisitos de cumplimiento de la CMMC?
El programa de Certificación del Modelo de Madurez en Ciberseguridad (CMMC) establece los requisitos de seguridad para los contratistas del sector de la defensa que manejan información de contratos federales (FCI) o información no clasificada controlada (CUI). El nivel 1 abarca 15 requisitos básicos; el nivel 2, los 110 requisitos de la norma SP 800-171, revisión 2, del Instituto Nacional de Estándares y Tecnología (NIST); y el nivel 3 añade 24 requisitos seleccionados de la norma SP 800-172.
¿Cuándo será obligatorio cumplir con la normativa CMMC en 2026?
Depende del contrato. Desde el 10 de noviembre de 2025, las nuevas licitaciones del Departamento de Defensa pueden exigir autoevaluaciones de nivel 1 o nivel 2 como condición para la adjudicación en el marco del programa de Certificación del Modelo de Madurez en Ciberseguridad (CMMC). La fase 2, que habría introducido evaluaciones de nivel 2 realizadas por terceros el 10 de noviembre de 2026, está suspendida desde el 13 de julio de 2026.
¿Cuáles son los requisitos de cumplimiento de la CMMC para las pequeñas empresas?
Las pequeñas empresas se enfrentan a los mismos requisitos que el resto de contratistas de su nivel. La normativa del programa establece los requisitos en función del tipo de información que se maneja, y el Nivel 2 consiste en una lista de 110 requisitos aplicables a todos. El anuncio del Departamento de Defensa de julio de 2026, en el que se suspendía parte del programa, indicaba que su revisión tiene como objetivo reducir las barreras para las pequeñas empresas y las empresas no tradicionales.
¿El nivel 2 del CMMC exige registros de procedencia de código abierto?
No. En el programa de Certificación del Modelo de Madurez en Ciberseguridad (CMMC), ninguno de los 110 requisitos del Nivel 2 menciona el código abierto ni la procedencia. En el apartado dedicado al software instalado por el usuario, CM.L2-3.4.9, se indica que las instalaciones prohibidas pueden incluir software de procedencia desconocida o sospechosa, pero se trata de un texto explicativo. El riesgo de la cadena de suministro se menciona en dos requisitos del Nivel 3.
¿Pueden un plan de acción y los hitos cubrir la corrección de defectos?
No es posible. Un plan de acción y los hitos solo pueden incluir requisitos de un punto, salvo una excepción relacionada con el cifrado, y la corrección de fallos (SI.L2-3.14.1) se puntúa con cinco puntos según la norma del programa. Además, el plan debe obtener una puntuación mínima de 88 sobre 110 y debe completarse en un plazo de 180 días; de lo contrario, el estado «Condicional» caducará.
¿Cómo se mantiene el cumplimiento de la CMMC tras una evaluación?
En el marco del programa de Certificación del Modelo de Madurez en Ciberseguridad (CMMC), un responsable de certificación —la persona con autoridad para certificar el cumplimiento de la empresa— debe confirmar dicho cumplimiento de forma continua cada año. La certificación de Nivel 2 tiene una validez de tres años antes de que sea necesaria una nueva evaluación, mientras que las autoevaluaciones de Nivel 1 se repiten anualmente.
