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 manual del Programa Federal de Gestión de Riesgos y Autorizaciones (FedRAMP), revisión 5 (Rev5), exige a los proveedores que suban mensualmente un plan de acción actualizado y los hitos correspondientes.
- Las normas consolidadas de FedRAMP para 2026 fijan el 7 de diciembre de 2026 como fecha de entrada en vigor de las nuevas normas sobre vulnerabilidades, con un plazo de gracia que finaliza el 7 de marzo de 2027.
- Una incidencia sin resolver permanece en los informes mensuales del proveedor hasta que se solucione, y la normativa de 2026 exige que se clasifique como vulnerabilidad aceptada si no se mitiga o soluciona por completo en un plazo de 192 días desde su evaluación.
- Las imágenes base, las dependencias fijadas y los componentes abandonados hacen que sigan apareciendo los mismos problemas de código abierto hasta que alguien modifique la compilación.
- Un equipo de plataforma puede programar la actualización de las imágenes base, evaluar los problemas recurrentes y decidir con antelación qué medidas tomar respecto a los componentes para los que no existe una solución en el código fuente original.
La supervisión continua de FedRAMP (ConMon) exige que los proveedores de servicios en la nube suban cada mes un plan de acción y hitos (POA&M) actualizado. Cada vulnerabilidad específica cuenta con su propia entrada en dicho plan. Si un componente de su compilación sigue presentando un hallazgo pendiente, dicho hallazgo suele mantenerse en el POA&M del mes siguiente. Esa es la ruta de la Revisión 5 (Rev5) descrita en el Manual de supervisión continua de FedRAMP, el Programa Federal de Gestión de Riesgos y Autorizaciones.
Un hallazgo que se repite cada mes vuelve a poner ante los revisores la misma opción de código abierto, y eso es lo que el título entiende por «replantear». En la vía Rev5, el Manual de estrategias orienta las reuniones ConMon interinstitucionales hacia los elementos vencidos, las dependencias de proveedores y cualquier aspecto que requiera la aceptación del riesgo. Los evaluadores también validan las solicitudes de desviación y las dependencias de proveedores en cada evaluación anual. Según las normas de FedRAMP para 2026, una deficiencia que no se haya mitigado o subsanado por completo 192 días después de la evaluación deberá clasificarse como vulnerabilidad aceptada, con una explicación por escrito de los motivos. A partir de 2027, cada agencia cliente también recibirá un resumen trimestral de las vulnerabilidades aceptadas.
Las normas de FedRAMP para 2026 también establecen que los proveedores deben diseñar sus servicios de forma que, por defecto, se reduzca el riesgo de vulnerabilidad. En el caso de los componentes de código abierto, esto implica seleccionar qué se incluye en la compilación, y es el equipo de la plataforma el que toma esas decisiones.
Cómo funciona la supervisión continua de FedRAMP mes a mes
En la ruta Rev5 (Playbook versión 1.0, 17 de noviembre de 2025), el proveedor analiza los sistemas operativos, las aplicaciones web y las bases de datos al menos una vez al mes. A continuación, carga el POA&M y el inventario actualizados, además de los archivos de análisis sin procesar cuando así lo exijan sus acuerdos con las agencias. El responsable autorizado de la agencia revisa el POA&M y aprueba las solicitudes de desviación, en las que se pide a la agencia que trate un hallazgo como un falso positivo, un ajuste de riesgo o un requisito operativo.
Las Normas Consolidadas de FedRAMP para 2026 (CR26) entraron en vigor el 24 de junio de 2026. Dos de sus conjuntos de normas, «Detección y respuesta ante vulnerabilidades» y «Evaluación y notificación de vulnerabilidades», abarcan las clases B a D de Rev5 y las clases B y C de 20x, la vía de certificación más reciente de FedRAMP. Algunos plazos dependen tanto de la vía como de la clase. La adopción anticipada se abrió el 4 de julio de 2026. Los nuevos solicitantes deben cumplir con los conjuntos de normas a partir del 7 de diciembre de 2026. Los proveedores actuales deben adoptarlas antes de esa fecha o se enfrentarán a un plan de medidas correctivas. El 7 de marzo de 2027 finaliza el periodo de gracia y FedRAMP revocará la certificación a los proveedores que no lo hayan hecho.
| Artículo | Manual de Rev5, versión 1.0 | Normas relativas a la vulnerabilidad CR26, a partir del 15 de octubre de 2026 | Fundamentos |
|---|---|---|---|
| Escaneo y verificación | Los sistemas operativos, las aplicaciones web y las bases de datos se analizan al menos una vez al mes. | Los proveedores de clase C y D de Rev5 deben verificar y validar los recursos basados en máquinas al menos una vez al mes (los proveedores de clase B también deberían hacerlo). Los proveedores de clase C de 20x deben hacerlo cada tres días. | Requisitos FedRAMP |
| Informe mensual | Actualización de POA&M y del inventario | La actividad relacionada con las vulnerabilidades se comunica al menos una vez al mes en un formato coherente y legible para el ser humano. Los informes también resumen toda la actividad registrada desde el informe anterior (Rev. 5, clases B a D). | Requisitos FedRAMP |
| Hallazgos sin resolver | Se registran como partidas POA&M. Las solicitudes de desviación deben ser aprobadas por la agencia. | Debe marcarse como vulnerabilidad aceptada, con una explicación, si no se ha mitigado o subsanado por completo, o no se va a mitigar o subsanar por completo, en un plazo de 192 días a partir de la evaluación. | Orientaciones del manual de estrategias de la oficina del programa; requisito CR26 (OBLIGATORIO) |
¿A dónde van a parar las conclusiones pendientes tras el primer informe?
En la vía Rev5, las deficiencias sin resolver se registran en el POA&M junto con un plan de corrección, y el proveedor puede presentar una solicitud de excepción para que la agencia tome una decisión al respecto. Un elemento del POA&M que dependa de un proveedor anterior se registra como una dependencia del proveedor.
Para un proveedor con más de un cliente de agencia, el Manual describe una reunión colaborativa mensual de ConMon. Se indica que no resulta práctico abordar todos los puntos del POA&M, especialmente aquellos que el proveedor prevé resolver dentro de los plazos establecidos por FedRAMP. El debate debe centrarse en los puntos vencidos, las dependencias de proveedores y las solicitudes de desviación, sobre todo aquellas que requieran la aceptación de riesgos. Por lo tanto, cualquier incidencia que permanezca pendiente tras su fecha límite debe plantearse ante todas las agencias del grupo.
Según las Normas Consolidadas de FedRAMP para 2026: FedRAMP recomienda que las agencias revisen únicamente las vulnerabilidades vencidas y aceptadas con una calificación «N» de impacto potencial en la agencia superior a 2, a menos que el proveedor recomiende medidas de mitigación o que el servicio se encuentre en un sistema federal de mayor riesgo. La calificación N, que va de N0 a N5, es la estimación del proveedor sobre el alcance del daño que la explotación podría causar a las agencias que utilizan el servicio. Por lo general, las vulnerabilidades aceptadas solo deben revisarse cuando se añaden o cuando cambia el uso que hace de ellas la agencia.
Las normas de 2026 también limitan el tiempo durante el que un proveedor puede mantener abierta una incidencia mientras planifica su corrección. Debe clasificar como «vulnerabilidad aceptada» cualquier vulnerabilidad que no se haya mitigado o corregido por completo, o que no vaya a mitigarse o corregirse por completo, en un plazo de 192 días desde la evaluación. A partir de ese momento, cada informe mensual explica el motivo, si la vulnerabilidad es accesible desde Internet, si es probable que pueda ser explotada y su calificación N actual.
| Resultado | Lo que dicen las normas | Fundamentos |
|---|---|---|
| Mitigación parcial | Reduce el riesgo sin eliminar la vulnerabilidad. Cuando no sea posible una mitigación o corrección total, los proveedores deben actuar de forma inmediata, progresiva y constante. | Nota orientativa de FedRAMP (RECOMENDADO) |
| Mitigación total | Reduce el riesgo a un nivel insignificante, pero la vulnerabilidad sigue existiendo hasta que se solucione. | Nota orientativa de FedRAMP |
| Remediación | Elimina por completo la vulnerabilidad. | Nota orientativa de FedRAMP |
| Vulnerabilidad confirmada | Etiqueta para una vulnerabilidad que el proveedor no tiene intención de mitigar o corregir por completo. Es obligatoria cuando una vulnerabilidad no se haya mitigado o corregido por completo, o no vaya a mitigarse o corregirse por completo, en un plazo de 192 días desde la evaluación. El proveedor debe explicar el motivo. | Definición; requisito (OBLIGATORIO) |
| Falso positivo | Los proveedores deben evaluar las vulnerabilidades detectadas para determinar si se trata de falsos positivos. | Recomendación (DEBERÍA) |
Aceptar una observación traslada la decisión sobre el riesgo a sus clientes: cada organismo decide si sigue utilizando el servicio con la observación pendiente, y FedRAMP solicita a los organismos que hagan un seguimiento de esa decisión en su propio POA&M.
¿Por qué siguen apareciendo una y otra vez las mismas conclusiones sobre el software libre?
En el caso de los sistemas en contenedores, el Playbook exige un identificador único de activo para cada clase de imagen de contenedor y vincula cada contenedor de producción a su imagen de origen. También establece que la aplicación de parches de software debe realizarse en la imagen de sustitución, nunca directamente en el entorno de producción. Por lo tanto, un paquete vulnerable en una imagen base suele aparecer en todos los contenedores creados a partir de ella, y la solución habitual es crear una nueva imagen. Hasta que alguien actualice la imagen, el conjunto de paquetes suele permanecer igual, y el problema persiste.
Las dependencias fijadas se comportan de la misma manera. Un archivo de bloqueo mantiene una biblioteca en la versión que hayas elegido, por lo que una biblioteca con un aviso abierto permanece en esa versión hasta que alguien la modifique. En el caso de un componente que se mantiene activamente, la solución es una versión corregida del desarrollador original que alguien incorpore posteriormente a tu compilación. Actualizar conlleva sus propios riesgos, y nuestra entrada sobre por qué «simplemente actualizarlo» es un mal consejo de seguridad lo explica con detalle.
Cuando el desarrollador original deja de dar soporte a un componente, pueden seguir revelándose nuevas vulnerabilidades en él, pero normalmente no se publica una versión corregida. La vulnerabilidad permanece entonces abierta hasta que se sustituya el componente o alguien aplique un parche a la versión que se utiliza, incluso después de que el plazo de 192 días obligue a asignarle la etiqueta «aceptada». Es raro que un servicio se limite a un solo lenguaje, por lo que los componentes abandonados pueden acumularse en varios ecosistemas a la vez.
Lo que los escáneres no te cuentan sobre un paquete
Los resultados del análisis se basan en vulnerabilidades conocidas. El manual de procedimientos exige que los hallazgos legibles por máquina incluyan el número de referencia de Vulnerabilidades y Exposiciones Comunes (CVE) para cualquier vulnerabilidad que figure en la Base de Datos Nacional de Vulnerabilidades. Las normas de 2026 indican que las directrices anteriores de FedRAMP se centraban generalmente en vulnerabilidades de tipo CVE y dejaban sin abordar otros tipos, y la lista de reglas de detección incluye la supervisión de la cadena de suministro entre las técnicas que utilizan los proveedores.
Los escáneres y otras herramientas de supervisión continua de FedRAMP que utiliza un proveedor informan sobre el contenido de la compilación. Es posible que un paquete que haya sido manipulado o compilado a partir de una fuente distinta de su código fuente público no aparezca como un hallazgo CVE, y que un paquete malicioso no tenga ningún CVE en absoluto. Una lista de materiales de software (SBOM) presenta el mismo punto ciego: un componente puede aparecer en la lista con precisión y, aun así, haber sido manipulado. Ambos describen lo que llegó, pero ninguno indica si debería haber llegado.
Qué puede cambiar la ingeniería de plataformas antes del próximo informe
Si eres el responsable de la compilación en el marco de un ciclo de supervisión continua de FedRAMP, puedes modificar el contenido del próximo informe cambiando lo que se incluye en dicha compilación.
Según las Normas Consolidadas de FedRAMP para 2026: los proveedores deben evaluar las vulnerabilidades por grupos lógicos de recursos afectados, y las normas de detección y respuesta de FedRAMP se aplican entonces a cada grupo, en lugar de a cada instancia.
Empieza por programar las actualizaciones de las imágenes base. Planifícalas de manera que las imágenes reconstruidas estén en producción antes de tu análisis mensual, para que cualquier corrección en la imagen base actualizada aparezca en el siguiente informe. Según la regla de agrupación, un paquete vulnerable en una sola imagen base puede considerarse como una única agrupación, aunque aparezca en varios contenedores.
Calcula cuántas incidencias se repiten antes de argumentar a favor de su corrección. Toma tus tres últimos informes y cuenta las incidencias que aparecen en los tres. Eso muestra, a grandes rasgos, qué parte del trabajo mensual es trabajo pendiente y ofrece a quien financia el trabajo un motivo para actuar. A continuación, clasifica por separado las incidencias recurrentes y las nuevas antes de la clasificación por prioridad, ya que las nuevas requieren un análisis independiente y es fácil pasarlas por alto entre las ya conocidas.
Cuando un componente no disponga de una solución por parte del proveedor, decide antes de que se cumplan los 192 días si lo vas a sustituir, aplicar un parche a la versión que utilizas o aceptar la vulnerabilidad.
Incluye las dependencias transitivas en tu inventario de paquetes, ya que los paquetes que eliges directamente son solo una parte de lo que se distribuye.
Los errores que se repiten una y otra vez tienen su origen en la compilación, y lo que los soluciona es un cambio en la misma.
El papel de SecureChain en el ciclo de vida de los paquetes
SecureChain es el producto de TuxCare destinado a los paquetes de código abierto de tu compilación. En el caso de los paquetes que cubre, los recompila desde el código fuente en entornos aislados y con acceso restringido, y los analiza en busca de malware y código sospechoso, impidiendo que cualquier elemento que no supere las pruebas llegue a tu entorno. Cada paquete incluye una certificación de procedencia SLSA de nivel 3, una SBOM y una declaración VEX. Los paquetes que aún reciben mantenimiento se supervisan en busca de nuevas vulnerabilidades CVE y se parchean en virtud de un acuerdo de nivel de servicio. Cuando los mantenedores originales dejan de hacerlo, TuxCare adapta las correcciones críticas y de alta gravedad a las versiones exactas que estás ejecutando. La cobertura abarca JavaScript, Python, Java, Go y PHP.
Si tu informe mensual sigue incluyendo componentes que el desarrollador original ha dejado de corregir, consulta qué cubre SecureChain.
PREGUNTAS FRECUENTES
¿Qué es ConMon en FedRAMP y qué datos se comunican cada mes?
En FedRAMP, el programa federal de autorización de servicios en la nube de EE. UU., la supervisión continua (ConMon) abarca la presentación de informes de seguridad periódicos por parte del proveedor una vez que se ha autorizado su servicio. En la vía de la Revisión 5 (Rev5), los proveedores de servicios en la nube analizan mensualmente los sistemas operativos, las aplicaciones web y las bases de datos, y envían un plan de acción y hitos (POA&M) actualizado, así como un inventario, de acuerdo con el Manual de supervisión continua (versión 1.0).
¿Informan de las vulnerabilidades de la misma manera los proveedores de Rev5 y 20x?
En virtud de su Normativa Consolidada para 2026, FedRAMP exige a los proveedores de la Revisión 5 (Rev5) y a los proveedores 20x de las clases B y C que informen sobre la actividad relacionada con las vulnerabilidades al menos una vez al mes y que marquen como «aceptada» cualquier vulnerabilidad que no se haya mitigado o subsanado por completo en un plazo de 192 días desde su evaluación. La periodicidad de las verificaciones varía según la vía y la clase. Los proveedores de la Clase C de Rev5 deben verificar y validar los recursos basados en máquinas al menos una vez al mes, mientras que los proveedores de la Clase C de 20x deben hacerlo cada tres días.
¿Qué es una vulnerabilidad aceptada en FedRAMP?
Según sus normas de 2026, FedRAMP considera que una vulnerabilidad es «aceptada» cuando el proveedor no tiene intención de mitigarla o subsanarla por completo. Esta calificación también es obligatoria cuando 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. Los proveedores deben informar de los motivos por los que se acepta cada vulnerabilidad, junto con su accesibilidad desde Internet, la probabilidad de que sea explotable y el impacto estimado en la agencia.
¿Qué es una solicitud de excepción en FedRAMP?
En FedRAMP, un proveedor de la Revisión 5 (Rev5) puede presentar una solicitud de excepción en la que pida a la agencia que considere un hallazgo como un falso positivo, un ajuste de riesgo o un requisito operativo. El Manual de supervisión continua establece que las agencias aprueban estas solicitudes y que los evaluadores las validan durante la evaluación anual.
¿Las inspecciones de FedRAMP distinguen los paquetes de código abierto del resto del software?
FedRAMP no clasifica los hallazgos según su condición de código abierto ni en el Manual de supervisión continua ni en las normas de vulnerabilidad de 2026. El Manual vincula los hallazgos a los activos del inventario y a las imágenes de contenedores, y la norma de detección de 2026 incluye la supervisión de la cadena de suministro como una de las técnicas. Para rastrear el origen de un hallazgo, es necesario realizar un análisis por cuenta propia.
¿Cuándo entrarán en vigor las normas sobre vulnerabilidades de FedRAMP para 2026?
FedRAMP abrió la posibilidad de adoptar de forma opcional sus normas sobre vulnerabilidades de 2026 el 4 de julio de 2026. Los nuevos solicitantes deberán cumplirlas a partir del 7 de diciembre de 2026. Los proveedores actuales deberán adoptarlas antes de esa fecha y, a más tardar, el 7 de marzo de 2027; de lo contrario, FedRAMP revocará la certificación.
