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
- Según las normas de FedRAMP para 2026, los plazos recomendados para la corrección oscilan entre 12 horas y 192 días, contados a partir de la evaluación de la vulnerabilidad por parte del proveedor.
- Los nuevos solicitantes deberán cumplir las normas de FedRAMP sobre vulnerabilidades de 2026 a partir del 7 de diciembre de 2026, y los proveedores actuales deberán adoptarlas a más tardar el 7 de marzo de 2027.
- Las vulnerabilidades que no se hayan mitigado o subsanado por completo en un plazo de 192 días desde su evaluación deberán clasificarse como vulnerabilidades aceptadas.
- Ningún plazo de corrección de FedRAMP se suspende cuando un responsable del mantenimiento de un proyecto de código abierto deja de publicar correcciones.
- Una vulnerabilidad que no se resuelve dentro del plazo previsto, aunque el proveedor siga teniendo la intención de mitigarla o subsanarla por completo, pasa a considerarse pendiente, y en cada informe mensual debe señalarse con una explicación.
FedRAMP establece plazos para mitigar o subsanar las vulnerabilidades de tu servicio, incluidas las de los paquetes de código abierto. Estos plazos siguen en vigor independientemente de que exista o no una solución.
Sin una solución, puedes mitigar las vulnerabilidades, pero estas seguirán apareciendo en tus informes mensuales hasta que se subsanen. Según las nuevas normas de FedRAMP, una vulnerabilidad que no se haya mitigado por completo (reducida a un riesgo insignificante) o subsanado en un plazo de 192 días tras su evaluación debe clasificarse como «vulnerabilidad aceptada». A continuación, deberás explicar en tus informes por qué se ha aceptado.
Esas nuevas normas, las Normas Consolidadas para 2026, sustituyen a los documentos anteriores de FedRAMP. Los proveedores actuales deben adoptar las normas sobre vulnerabilidades a más tardar el 7 de marzo de 2027.
El calendario de corrección de vulnerabilidades de FedRAMP antes y después de la normativa de 2026
FedRAMP clasificó sus documentos anteriores como «solo de referencia» el 24 de junio de 2026. En lo que respecta a las vulnerabilidades, los documentos que los sustituyen son dos conjuntos de normas incluidas en las Normas Consolidadas para 2026: «Detección y respuesta ante vulnerabilidades» (VDR) y «Evaluación y notificación de vulnerabilidades» (VER). Los proveedores que aún no hayan adoptado estas normas de 2026 seguirán aplicando los procesos anteriores durante el periodo de transición. Las normas de 2026 utilizan el término «certificación» donde los documentos anteriores utilizan el término «autorización».
En la página del Plan de Acción y Hitos (POA&M) anterior se indica que FedRAMP exige que las vulnerabilidades clasificadas como «críticas» o «altas» se subsanen en un plazo de 30 días desde su detección, las «moderadas» en un plazo de 90 días y las «bajas» en un plazo de 180 días. El Manual de supervisión continua anterior utiliza la puntuación base del Sistema Común de Puntuación de Vulnerabilidades (CVSS) para dicha clasificación.
Según la normativa de 2026, cada servicio certificado tiene una clase, que va desde la A —el nivel más bajo de garantía— hasta la D —el más alto—. El plazo para la corrección comienza en el momento de la evaluación. La evaluación debe realizarse en un plazo de 14 días desde la detección en el caso de la clase A, y en un plazo de 2 días en el caso de la clase D. La duración del plazo depende de la clase y de la calificación «N» que el proveedor asigne a la vulnerabilidad, una estimación del daño que su explotación podría causar a las agencias, desde N0 (extremadamente improbable que afecte a las agencias) hasta N5 (efectos devastadores en más de una agencia).
La duración también depende de si es probable que la vulnerabilidad sea explotable —es decir, que un posible atacante pueda utilizarla para causar daños— y de si es accesible desde Internet —es decir, que una carga útil procedente de Internet pueda activarla—. Las vulnerabilidades que cumplen ambos criterios reciben el plazo más corto. El VDR establece plazos únicamente para las clasificaciones N2 a N5, y deja las clasificaciones N0 y N1 a cargo de las operaciones rutinarias del proveedor.
| Artículo | Documentos históricos | Normativa de 2026 (VDR y VER) | Fundamentos |
|---|---|---|---|
| El plazo comienza el | Descubrimiento | La evaluación, que debe realizarse en un plazo de 14, 7, 5 o 2 días tras la detección, en el caso de las clases A, B, C y D | Página antigua de POA&M; VER-TFR-EVU |
| Duración del plazo | 30, 90 y 180 días según el nivel de riesgo | De 12 horas a 192 días según clase, habilitación N, explotabilidad y accesibilidad | Página antigua de POA&M; VDR-TFR-PVR |
| Fuerza | «FedRAMP exige» | «SHOULD» para los plazos; «MUST» para la etiqueta de vulnerabilidad aceptada | Página heredada de POA&M; VDR-TFR-PVR; VER-TFR-MAV |
| Valoración | Nivel de riesgo basado en el CVSS | Estimación de la calificación N del proveedor | Manual, página 6; VER-EVA-EPA |
Los plazos de corrección establecidos en la normativa de 2026 llevan la etiqueta «SHOULD». FedRAMP define «SHOULD» como una norma de la que un proveedor puede apartarse por motivos válidos, siempre que explique dicha decisión en su documentación de seguridad. Aun así, la notificación NTC-0014 de FedRAMP, de 16 de junio de 2026, califica estos plazos como máximos y señala que los proveedores deberían mitigar o corregir los problemas mucho más rápidamente.
Fechas de adopción y la directiva en la que se basan
La adopción se lleva a cabo proveedor por proveedor, según la página de plazos de la Revisión 5 de FedRAMP. Los nuevos solicitantes deberán adoptar ambos conjuntos de normas a partir del 7 de diciembre de 2026. Los proveedores actuales que no las hayan adoptado para esa fecha deberán presentar un plan de medidas correctivas, que incluya una notificación a todos los organismos, y FedRAMP revocará la certificación de la oferta si las normas siguen sin adoptarse para el 7 de marzo de 2027.
El 7 de diciembre coincide con la Directiva Operativa Vinculante (BOD) 26-04 de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), publicada el 10 de junio de 2026. La directiva es vinculante para los organismos civiles federales, que tienen hasta el 7 de diciembre para empezar a cumplir con su calendario de medidas correctoras, y se aplica a los proveedores a través de las normas y los contratos de FedRAMP. El calendario abarca desde 3 hasta 60 días. La NTC-0014 establece que los proveedores que cumplan con los requisitos de VDR y VER satisfacen los requisitos de la directiva.
Lo que dicen los documentos sobre un problema sin solución
Un hallazgo sin solución se gestiona de forma diferente en cada conjunto de documentos. Los documentos heredados lo denominan «dependencia de proveedor» (VD), que se aplica cuando un proveedor tiene que recurrir a un proveedor externo —como uno que suministra un producto comercial listo para usar— para obtener un parche que aún no está disponible. Una VD no es una solicitud de desviación (el tipo de solicitud heredado que una agencia aprueba para falsos positivos, ajustes de riesgo y requisitos operativos), por lo que no requiere aprobación.
Una vulnerabilidad (VD) permanece como partida pendiente, y el proveedor se pone en contacto con el proveedor de software al menos una vez al mes. Incluso si el proveedor de software no ofrece ningún parche, una vulnerabilidad de alto riesgo (aquella que se encuentra en el nivel heredado de «alto riesgo») debe mitigarse hasta alcanzar un nivel «moderado» mediante controles compensatorios en un plazo de 30 días.
Un requisito operativo se refiere a un hallazgo que no puede subsanarse, a menudo porque el sistema no funcionaría según lo previsto o porque un proveedor ha indicado que no ofrecerá una solución. FedRAMP no lo aprobará en el caso de un hallazgo de alto riesgo, aunque el proveedor sí puede mitigarlo.
La página heredada de POA&M utiliza el término «proveedor», pero no especifica si un mantenedor voluntario se considera como tal. Los conjuntos de reglas VDR y VER no utilizan en absoluto el término «dependencia de proveedor». El VDR establece que un proveedor que no pueda mitigar o subsanar por completo una vulnerabilidad debe mitigarla parcialmente de forma inmediata, progresiva y persistente.
Según la norma VDR-TFR-PVR, un proveedor cumple con un plazo al mitigar parcialmente, mitigar por completo o subsanar una vulnerabilidad para alcanzar una calificación «N» más baja dentro de dicho plazo. La norma NTC-0014 añade que, a efectos de la Directiva BOD 26-04, un proveedor puede mitigar una vulnerabilidad hasta que ya no sea automatizable ni accesible desde Internet, momento en el que la directiva no exige su subsanación completa.
VER exige la etiqueta de «vulnerabilidad aceptada» si una vulnerabilidad no se ha mitigado o subsanado por completo, o no se va a mitigar ni subsanar por completo, en un plazo de 192 días desde la evaluación. Cada informe incluye entonces la explicación del proveedor sobre los motivos por los que se ha aceptado, la accesibilidad y la explotabilidad de la vulnerabilidad, así como su calificación N actual.
Cuando los calendarios de lanzamiento de las fases iniciales coinciden con el reloj
Si se compara con el calendario de corrección de vulnerabilidades de FedRAMP, la «brecha de parches» es el periodo de tiempo de una incidencia durante el cual no hay ninguna corrección disponible. La página heredada de POA&M, el «Playbook», las normas sobre vulnerabilidades de 2026 y las definiciones de FedRAMP no mencionan a los mantenedores de software de código abierto ni si un proyecto sigue recibiendo nuevas versiones. VDR sí incluye la supervisión de la cadena de suministro entre las técnicas para detectar puntos débiles, por lo que lo que un paquete aporta a una compilación forma parte de lo que cabe esperar que un proveedor supervise. Más allá de lo mencionado anteriormente, esos documentos no especifican qué debe hacer un proveedor cuando el responsable del mantenimiento no va a corregir el hallazgo.
Supongamos que tu servicio cuenta con una certificación de Clase C y detecta un hallazgo el día 0 en un paquete de código abierto cuyos responsables ya no publican correcciones. Los proveedores de Clase C deben realizar una evaluación en un plazo de 5 días desde la detección; supongamos, por tanto, que la evaluación se lleva a cabo el día 5 y clasifica el hallazgo como N3.
| Cómo se lleva a cabo la evaluación | Plazo a partir de la evaluación | Día (si se evalúa el día 5) | Fundamentos |
|---|---|---|---|
| Probablemente vulnerable y accesible desde Internet | 16 días (deberían ser) | Día 21 | VDR-TFR-PVR, Clase C, N3 |
| Probablemente vulnerable, pero no accesible desde Internet | 32 días (deberían ser) | Día 37 | VDR-TFR-PVR, Clase C, N3 |
| No parece que se pueda aprovechar | 128 días (debería) | Día 133 | VDR-TFR-PVR, Clase C, N3 |
| Cualquiera de los tres, si no se ha mitigado o subsanado por completo (o no se prevé que se haga) en un plazo de 192 días a partir de la evaluación | Se requiere una etiqueta de vulnerabilidad aceptada tan pronto como se compruebe que la mitigación o corrección total no se llevará a cabo en un plazo de 192 días (obligatorio) | Tan pronto como el proveedor tenga conocimiento de ello y, a más tardar, el día 197 | VER-TFR-MAV |
El hecho de que los responsables del mantenimiento publiquen o no una corrección no modifica ninguna de esas cifras. La fila que se aplique depende de la evaluación del proveedor, y FedRAMP incluye una advertencia al respecto. Su nota sobre la norma de explotabilidad establece que los proveedores que califiquen habitualmente las vulnerabilidades como «poco probables de ser explotadas» sin una consideración minuciosa tienen más probabilidades de sufrir un impacto adverso si alguna de ellas es explotada. Añade que una subestimación imprudente o deliberada se tendrá en cuenta en contra de la certificación de un proveedor. Los proveedores también deben dar por hecho que la explotación puede automatizarse, a menos que dispongan de pruebas que demuestren lo contrario.
La directiva de la CISA permite que los cambios en los hechos modifiquen el calendario. Una de sus notas indica que desconectar un sistema de Internet lo traslada a una fila diferente de la tabla de la directiva. Sin embargo, las vulnerabilidades explotadas conocidas mantienen sus fechas límite. La VDR-TFR-KEV establece que los proveedores deben subsanarlas antes de las fechas límite indicadas en el catálogo de la CISA, incluso cuando estén totalmente mitigadas, y la NTC-0014 solo permite no hacerlo por razones técnicas válidas.
Un responsable de mantenimiento que siga publicando versiones puede proporcionar al proveedor algo que aplicar antes de que finalice el plazo. En cambio, quien haya dejado de hacerlo deja que el plazo siga corriendo sin nada que aplicar, y esa laguna puede hacerse patente en cualquier ecosistema de programación del que un servicio obtenga paquetes.
¿Qué ocurre cuando vence un plazo?
El «Playbook» anterior enumera ejemplos de factores desencadenantes entre los que las agencias pueden elegir. Cinco o más vulnerabilidades de alto impacto o elementos de POA&M que permanezcan sin subsanar durante más de 30 días requieren, como mínimo, una «Revisión detallada de los hallazgos», es decir, una solicitud para evaluar la deficiencia e informar de su causa y solución. Una vez que cinco o más superan la marca de los 60 días, la medida mínima es un plan de medidas correctivas de la agencia, que exige un análisis de la causa raíz y un plan de corrección formal. A partir de ahí, una agencia puede pasar a la suspensión o revocación de una autorización de funcionamiento (ATO), una medida que debe comunicar a FedRAMP.
El debate sobre el POA&M en la reunión colaborativa mensual de Playbook con las agencias debería centrarse en los asuntos pendientes, las dependencias de los proveedores y las solicitudes de desviación, de modo que cualquier incidencia que permanezca abierta tiende a volver a surgir.
Las páginas VDR y VER no especifican ninguna sanción por incumplir un plazo de nivel «SHOULD». El proveedor sigue estando obligado a justificar el incumplimiento, tal y como exige cualquier requisito «SHOULD», y la VER añade además la obligación de informar al respecto. Según las definiciones de FedRAMP, una vulnerabilidad se considera vencida cuando el proveedor tiene la intención de mitigarla o subsanarla por completo, pero no lo ha hecho, o no lo hará, dentro de los plazos recomendados u obligatorios. La etiqueta de «vulnerabilidad aceptada» abarca aquellas vulnerabilidades que el proveedor no tiene intención de mitigar o subsanar por completo, así como cualquier vulnerabilidad que haya superado el límite de 192 días. El VER exige que cada informe indique si una vulnerabilidad está vencida o es probable que lo esté, y que explique los motivos en caso afirmativo.
Aplicar parches a los paquetes cuando los responsables dejan de ocuparse de ellos
SecureChain, de TuxCare, recompila desde el código fuente los paquetes de código abierto que cubre en entornos aislados y reforzados, y analiza su código fuente en busca de malware conocido y patrones de código sospechosos. Todo lo que no supere el análisis queda excluido de tu entorno. Aunque los responsables del mantenimiento sigan publicando correcciones, SecureChain aplica parches a los paquetes en virtud de un acuerdo de nivel de servicio, utilizando las correcciones del desarrollador original cuando están disponibles y los parches de los ingenieros de TuxCare cuando estas no son suficientes.
Cuando el desarrollador original deja de publicar actualizaciones, TuxCare sigue aplicando parches al paquete, que posteriormente pasa automáticamente al programa de soporte de ciclo de vida indefinido (ELS), en el que los ingenieros de TuxCare adaptan las correcciones a las versiones que ya utilizas mientras sigas utilizando el paquete.
SecureChain también proporciona información sobre la procedencia, listas de materiales de software (SBOM) y datos del Vulnerability Exploitability eXchange (VEX), que ayudan a mostrar qué ha aportado un paquete a tu compilación. En conjunto, SecureChain y ELS cubren JavaScript, Python, Java, Go y PHP.
Si no sabes quién aplica los parches a un paquete una vez que sus responsables dejan de publicar correcciones, mientras sigue en marcha el plazo de FedRAMP, o qué ha aportado ese paquete a tu compilación, descubre cómo aborda SecureChain estas dos cuestiones.
PREGUNTAS FRECUENTES
¿Quién es responsable de las medidas correctoras en el marco de FedRAMP?
Según las Normas Consolidadas para 2026, el proveedor de servicios en la nube es el responsable: las normas de detección y respuesta ante vulnerabilidades exigen a los proveedores que realicen un seguimiento, mitiguen y corrijan todas las vulnerabilidades detectadas. El antiguo Manual de supervisión continua (versión 1.0, 17 de noviembre de 2025, ahora solo a título de referencia) también atribuye al proveedor la responsabilidad principal, y los funcionarios autorizados de la agencia revisan su Plan de acción y sus hitos mensuales.
¿Quién asigna la calificación que determina el plazo de FedRAMP?
En el manual de monitorización continua heredado, que ahora solo tiene carácter de referencia, la calificación de riesgo original es la puntuación base del Sistema Común de Puntuación de Vulnerabilidades (CVSS) de la versión 3 de la Base de Datos Nacional de Vulnerabilidades. Las normas de evaluación y notificación de vulnerabilidades de 2026 exigen que el proveedor estime el impacto potencial de una vulnerabilidad en la agencia mediante una calificación N, que va de N0 a N5.
¿Cuándo comienza el plazo para la corrección de deficiencias de FedRAMP?
La página «Plan de acción y hitos» (ya obsoleta, ahora solo a título informativo) cuenta 30, 90 o 180 días a partir del momento del descubrimiento, en función del nivel de riesgo. Las normas de «Detección y respuesta ante vulnerabilidades» de 2026 cuentan a partir de la evaluación, que, según las normas de «Evaluación y notificación de vulnerabilidades», debe realizarse tras la detección en un plazo de 14, 7, 5 o 2 días, dependiendo de la clase de certificación.
¿Qué disposiciones de FedRAMP se aplican a un hallazgo para el que no existe solución disponible?
La «dependencia del proveedor» y el «requisito operativo» son términos heredados de la página «Plan de acción y hitos». El primero se refiere a una vulnerabilidad que está a la espera de una corrección por parte del proveedor, y el segundo, a una vulnerabilidad que no puede subsanarse. Las normas de «Detección y respuesta ante vulnerabilidades» de 2026 recomiendan una mitigación parcial, y las normas de «Evaluación y notificación de vulnerabilidades» exigen la etiqueta de «vulnerabilidad aceptada» si no se produce una mitigación o subsanación completa en un plazo de 192 días desde la evaluación.
¿Qué se considera «corrigido» según las normas de FedRAMP para 2026?
Una vulnerabilidad corregida, según las definiciones de las Normas Consolidadas para 2026, es aquella que ha sido neutralizada o eliminada y ya no se detecta. Una vulnerabilidad totalmente mitigada sigue detectándose, pero su riesgo es insignificante. Las normas de detección y respuesta ante vulnerabilidades añaden que «mitigación» y «corrección» no son términos intercambiables.
¿Cómo denomina FedRAMP a una vulnerabilidad que no cumple con el plazo establecido?
Una vulnerabilidad se considera «atrasada» cuando el proveedor sigue teniendo previsto mitigarla o subsanarla por completo, pero ha incumplido, o va a incumplir, el plazo establecido. Si el proveedor no tiene previsto hacerlo, se considera entonces una vulnerabilidad «aceptada». Según las normas de evaluación y notificación de vulnerabilidades de 2026, cada informe debe señalar las vulnerabilidades que estén atrasadas o que probablemente se atrasen, acompañándolas de una explicación.
