Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- De acordo com as regras do FedRAMP para 2026, os prazos recomendados para correção variam de 12 horas a 192 dias, contados a partir da avaliação da vulnerabilidade pelo provedor.
- Os novos candidatos devem seguir as regras de vulnerabilidade do FedRAMP para 2026 a partir de 7 de dezembro de 2026, e os prestadores já registrados devem adotá-las até 7 de março de 2027, no máximo.
- As vulnerabilidades que não forem totalmente mitigadas ou corrigidas no prazo de 192 dias após a avaliação devem ser classificadas como vulnerabilidades aceitas.
- Nenhum prazo de correção do FedRAMP é suspenso quando um mantenedor de código aberto deixa de disponibilizar correções.
- Uma vulnerabilidade cujo prazo não seja cumprido, embora o provedor ainda pretenda mitigá-la ou corrigi-la totalmente, passa a ser considerada em atraso, e cada relatório mensal deve sinalizá-la com uma explicação.
O FedRAMP estabelece prazos para a mitigação ou correção de vulnerabilidades em seu serviço, incluindo aquelas presentes em pacotes de código aberto. Esses prazos continuam em vigor independentemente da existência ou não de uma correção.
Sem uma correção, é possível mitigar as vulnerabilidades, mas elas permanecerão em seus relatórios mensais até que sejam sanadas. De acordo com as novas regras do FedRAMP, uma vulnerabilidade que não seja totalmente mitigada (reduzida a um risco insignificante) ou sanada no prazo de 192 dias após sua avaliação deve ser classificada como vulnerabilidade aceita. Nesse caso, você deverá explicar em seus relatórios por que ela foi aceita.
Essas novas regras, as Regras Consolidadas para 2026, estão substituindo os documentos anteriores do FedRAMP. Os prestadores de serviços já registrados devem adotar as regras relativas a vulnerabilidades até 7 de março de 2027, no máximo.
Cronograma de correção de vulnerabilidades do FedRAMP antes e depois das regras de 2026
O FedRAMP classificou seus documentos antigos como meramente informativos em 24 de junho de 2026. No que diz respeito às vulnerabilidades, os documentos substitutos são dois conjuntos de regras contidos nas Regras Consolidadas para 2026: Detecção e Resposta a Vulnerabilidades (VDR) e Avaliação e Relatório de Vulnerabilidades (VER). Os provedores que ainda não adotaram essas regras de 2026 continuam seguindo os processos antigos durante a transição. As regras de 2026 utilizam o termo “certificação” onde os documentos antigos utilizavam “autorização”.
A página do Plano de Ação e Marcos (POA&M) antigo indica que o FedRAMP exige que as vulnerabilidades classificadas como Críticas ou Altas sejam corrigidas no prazo de 30 dias após a descoberta, as Moderadas no prazo de 90 dias e as Baixas no prazo de 180 dias. O Manual de Monitoramento Contínuo antigo utiliza a pontuação base do Sistema Comum de Pontuação de Vulnerabilidades (CVSS) para essa classificação.
De acordo com as regras de 2026, cada serviço certificado possui uma classe, que vai de A — o nível mais baixo de garantia — até D — o mais alto. O prazo para correção começa a partir da avaliação. A avaliação deve ocorrer no prazo de 14 dias após a detecção para a Classe A e no prazo de 2 dias para a Classe D. A duração desse prazo depende da classe e da classificação N que o provedor atribui à vulnerabilidade — uma estimativa do dano que a exploração poderia causar às agências, variando de N0 (extremamente improvável que afete as agências) a N5 (efeitos devastadores em mais de uma agência).
O prazo também depende da probabilidade de a vulnerabilidade ser explorável — ou seja, se um possível invasor poderia usá-la para causar danos — e se ela é acessível pela internet — ou seja, se uma carga maliciosa proveniente da internet poderia acioná-la. As vulnerabilidades que atendem a ambos os critérios recebem o prazo mais curto. O VDR define prazos apenas para as classificações N2 a N5, deixando as classificações N0 e N1 a cargo das operações de rotina do provedor.
| Item | Documentos antigos | Regras de 2026 (VDR e VER) | Base |
|---|---|---|---|
| O prazo começa em | Descoberta | A avaliação, que deve ocorrer dentro de 14, 7, 5 ou 2 dias após a detecção, para as Classes A, B, C e D | Página antiga do POA&M; VER-TFR-EVU |
| Duração do prazo | 30, 90 e 180 dias, por nível de risco | De 12 horas a 192 dias, por classe, habilitação N, explorabilidade e acessibilidade | Página antiga do POA&M; VDR-TFR-PVR |
| Força | “O FedRAMP exige” | “DEVE” para prazos, “DEVE” para o rótulo de vulnerabilidade aceito | Página antiga do POA&M; VDR-TFR-PVR; VER-TFR-MAV |
| Avaliação | Nível de risco com base no CVSS | Estimativa da classificação N do provedor | Manual, página 6; VER-EVA-EPA |
Os prazos para correção previstos nas regras de 2026 são marcados com a indicação “SHOULD”. O FedRAMP define “SHOULD” como uma regra da qual um provedor pode se afastar por motivos válidos, desde que justifique a decisão em sua documentação de segurança. Mesmo assim, o aviso NTC-0014 do FedRAMP, de 16 de junho de 2026, classifica esses prazos como máximos e afirma que os provedores devem mitigar ou corrigir as falhas muito mais rapidamente.
Datas de aprovação e a diretiva que as fundamenta
A adoção ocorre provedor por provedor, de acordo com a página de prazos da Rev5 do FedRAMP. Os novos candidatos devem adotar ambos os conjuntos de regras a partir de 7 de dezembro de 2026. Os provedores existentes que não tiverem adotado as regras até essa data precisarão apresentar um plano de ação corretiva, que inclua notificação a todas as agências, e o FedRAMP revogará a certificação da oferta caso as regras ainda não tenham sido adotadas até 7 de março de 2027.
O dia 7 de dezembro está alinhado com a Diretiva Operacional Vinculativa (BOD) 26-04 da Agência de Segurança Cibernética e de Infraestrutura (CISA), emitida em 10 de junho de 2026. A diretiva é vinculativa para as agências civis federais, que têm até 7 de dezembro para começar a cumprir seu cronograma de correção, e se aplica aos provedores por meio das regras e contratos do FedRAMP. O cronograma varia de 3 a 60 dias. A NTC-0014 estabelece que os provedores que seguirem o VDR e o VER atendem aos requisitos da diretiva.
O que os documentos revelam sobre uma constatação sem solução
Uma constatação sem correção é tratada de maneira diferente em cada conjunto de documentos. Os documentos antigos chamam isso de dependência de fornecedor (VD), que se aplica quando um prestador de serviços precisa contar com um fornecedor — como aquele que fornece um produto comercial pronto para uso — para obter um patch que ainda não está disponível. Uma VD não é uma solicitação de desvio (o tipo de solicitação antigo que uma agência aprova para falsos positivos, ajustes de risco e requisitos operacionais); portanto, não requer aprovação.
Uma vulnerabilidade (VD) permanece como item pendente, e o provedor entra em contato com o fornecedor pelo menos uma vez por mês. Mesmo na ausência de uma correção do fornecedor, uma vulnerabilidade de alto risco (aquela classificada no nível legado de alto risco) deve ser mitigada para o nível moderado por meio de controles compensatórios no prazo de 30 dias.
Um requisito operacional se refere a uma não conformidade que não pode ser corrigida, muitas vezes porque o sistema não funcionaria conforme o previsto ou porque um fornecedor afirmou que não oferecerá uma correção. O FedRAMP não aprovará um requisito operacional para uma não conformidade de alto risco, embora o provedor ainda possa mitigá-la.
A página antiga do POA&M utiliza o termo “fornecedor”, mas não especifica se um mantenedor voluntário se enquadra nessa categoria. Os conjuntos de regras VDR e VER não utilizam o termo “dependência de fornecedor” de forma alguma. O VDR afirma que um provedor que não consiga mitigar ou corrigir totalmente uma vulnerabilidade deve mitigá-la parcialmente de forma imediata, progressiva e persistente.
De acordo com a norma VDR-TFR-PVR, um provedor cumpre um prazo ao mitigar parcialmente, mitigar totalmente ou corrigir uma vulnerabilidade para alcançar uma classificação N mais baixa dentro desse prazo. A norma NTC-0014 acrescenta que, para os fins da BOD 26-04, um provedor pode mitigar uma vulnerabilidade até que ela não seja mais automatizável ou acessível pela internet; nesse momento, a diretiva não exige a correção total.
O VER exige a classificação de vulnerabilidade “aceita” caso uma vulnerabilidade não tenha sido, ou não venha a ser, totalmente mitigada ou corrigida no prazo de 192 dias a partir da avaliação. Cada relatório inclui, então, a explicação do provedor sobre o motivo da aceitação, a acessibilidade e a explorabilidade da vulnerabilidade, bem como sua classificação N atual.
Quando os cronogramas de lançamento da produção se alinham com o relógio
Quando comparada ao cronograma de correção de vulnerabilidades do FedRAMP, a lacuna de patch é a parcela do prazo de uma constatação durante a qual nenhuma correção está disponível. A página antiga do POA&M, o Playbook, as regras de vulnerabilidade de 2026 e as definições do FedRAMP não mencionam os mantenedores de código aberto nem se um projeto ainda recebe lançamentos. O VDR lista o monitoramento da cadeia de suprimentos entre as técnicas para identificar pontos fracos; portanto, o que um pacote traz para uma compilação faz parte do que se espera que um provedor monitore. Além do tratamento descrito acima, esses documentos não especificam o que um provedor deve fazer quando o mantenedor não pretende corrigir a falha identificada.
Suponha que seu serviço possua uma certificação de Classe C e detecte uma vulnerabilidade no dia 0 em um pacote de código aberto cujos mantenedores tenham deixado de lançar correções. Os provedores de Classe C devem realizar a avaliação no prazo de 5 dias após a detecção; digamos, então, que a avaliação seja concluída no dia 5 e classifique a vulnerabilidade como N3.
| Como será o resultado da avaliação | Prazo a partir da avaliação | Dia (se avaliado no 5º dia) | Base |
|---|---|---|---|
| Provavelmente suscetível a exploração e acessível pela internet | 16 dias (deveria) | Dia 21 | VDR-TFR-PVR, Classe C, N3 |
| Provavelmente suscetível a exploração, mas sem acesso à internet | 32 dias (deveria) | Dia 37 | VDR-TFR-PVR, Classe C, N3 |
| Provavelmente não é passível de exploração | 128 dias (deveria) | Dia 133 | VDR-TFR-PVR, Classe C, N3 |
| Qualquer um dos três, caso não seja (ou não se preveja que seja) totalmente mitigado ou sanado no prazo de 192 dias a partir da avaliação | É obrigatório atribuir um rótulo de vulnerabilidade aceito assim que ficar claro que a mitigação ou correção completa não ocorrerá dentro de 192 dias (obrigatório) | Assim que o prestador tomar conhecimento, e, o mais tardar, no 197º dia | VER-TFR-MAV |
O fato de os mantenedores eventualmente lançarem uma correção não altera nenhum desses números. A linha aplicável depende da avaliação do provedor, e o FedRAMP inclui um aviso a esse respeito. Sua nota sobre a regra de explorabilidade afirma que os provedores que classificam regularmente as vulnerabilidades como improváveis de serem exploradas sem uma análise cuidadosa têm maior probabilidade de sofrer um impacto adverso caso uma delas seja explorada. A subclassificação imprudente ou deliberada, acrescenta, prejudicará a certificação do provedor. Os provedores também devem presumir que a exploração pode ser automatizada, a menos que tenham evidências em contrário.
A diretiva da CISA permite que mudanças nos fatos alterem o cronograma. Uma de suas notas indica que retirar um sistema da internet o transfere para uma linha diferente na tabela da diretiva. No entanto, as vulnerabilidades exploradas conhecidas mantêm suas datas de vencimento. A VDR-TFR-KEV estabelece que os provedores devem corrigi-las até as datas de vencimento indicadas no catálogo da CISA, mesmo quando estiverem totalmente mitigadas, e a NTC-0014 permite que se abstenha de fazê-lo apenas por motivos técnicos válidos.
Um mantenedor que ainda esteja lançando versões pode fornecer ao provedor algo para ser aplicado antes do término do prazo. Aquele que parou de lançar deixa o prazo em andamento sem nada para ser aplicado, e essa lacuna pode aparecer em qualquer ecossistema de linguagem do qual um serviço obtenha pacotes.
O que acontece quando um prazo expira
O Playbook antigo lista exemplos de gatilhos que as agências podem escolher. Cinco ou mais vulnerabilidades de alto impacto ou itens POA&M que permaneçam sem correção por mais de 30 dias exigem, no mínimo, uma Revisão Detalhada das Conclusões — um pedido para avaliar a deficiência e relatar sua causa e solução. Quando cinco ou mais itens ultrapassarem o prazo de 60 dias, a medida mínima é a elaboração de um plano de ação corretiva pela agência, que exige uma análise da causa raiz e um plano formal de correção. A partir daí, a agência pode avançar para a suspensão ou revogação de uma Autorização para Operar (ATO), medida que deve ser comunicada ao FedRAMP.
A discussão sobre o POA&M na reunião colaborativa mensal do Playbook com as agências deve se concentrar em itens em atraso, dependências de fornecedores e solicitações de desvio, de modo que uma observação que permaneça em aberto tenda a ressurgir.
As páginas VDR e VER não especificam uma penalidade pelo descumprimento de um prazo de nível “SHOULD”. O provedor ainda precisa justificar o desvio, conforme exigido por qualquer requisito “SHOULD”, e o VER acrescenta a obrigação de relatar tal desvio. As definições do FedRAMP consideram uma vulnerabilidade em atraso quando o provedor pretende mitigá-la ou corrigi-la totalmente, mas não o fez — ou não o fará — dentro dos prazos recomendados ou exigidos. A classificação de vulnerabilidade “aceita” abrange vulnerabilidades que o provedor não pretende mitigar ou corrigir totalmente, bem como qualquer vulnerabilidade que tenha ultrapassado o limite de 192 dias. O VER exige que cada relatório indique se uma vulnerabilidade está vencida ou se é provável que venha a ficar vencida, e explique o motivo, caso seja esse o caso.
Aplicação de correções em pacotes após o fim das atividades dos mantenedores
O SecureChain, da TuxCare, recompila os pacotes de código aberto que abrange a partir do código-fonte em ambientes fortificados e isolados e analisa seu código-fonte em busca de malware conhecido e padrões de código suspeitos. Qualquer elemento que não passe na análise fica fora do seu ambiente. Embora os mantenedores continuem lançando correções, o SecureChain aplica patches nos pacotes sob um acordo de nível de serviço, utilizando correções do upstream quando disponíveis e patches dos engenheiros da TuxCare quando o upstream não for suficiente.
Quando o desenvolvedor original interrompe o lançamento de atualizações, a TuxCare continua aplicando correções ao pacote, que posteriormente passa automaticamente para o Suporte de Ciclo de Vida Ilimitado (ELS), com os engenheiros da TuxCare adaptando as correções para as versões que você já utiliza, enquanto você continuar usando o pacote.
O SecureChain também fornece informações de proveniência, listas de materiais de software (SBOMs) e dados do Vulnerability Exploitability eXchange (VEX), que ajudam a identificar o que um pacote trouxe para sua compilação. Juntos, o SecureChain e o ELS abrangem JavaScript, Python, Java, Go e PHP.
Se você não souber dizer quem aplica os patches em um pacote depois que seus mantenedores param de lançar correções, enquanto o prazo do FedRAMP continua correndo, ou o que esse pacote trouxe para sua compilação, veja como o SecureChain aborda essas duas questões.
Perguntas frequentes
Quem é responsável pela correção de falhas no âmbito do FedRAMP?
De acordo com as Regras Consolidadas para 2026, o provedor de serviços em nuvem é responsável: as regras de Detecção e Resposta a Vulnerabilidades exigem que os provedores rastreiem, mitiguem e corrijam todas as vulnerabilidades detectadas. O antigo Manual de Monitoramento Contínuo (versão 1.0, 17 de novembro de 2025, agora apenas para referência) também atribui ao provedor a responsabilidade principal, cabendo aos funcionários autorizados da agência revisar seu Plano de Ação e Marcos mensais.
Quem atribui a classificação que define o prazo do FedRAMP?
No Manual de Monitoramento Contínuo antigo, agora apenas para referência, a classificação de risco original é a pontuação básica do Sistema Comum de Pontuação de Vulnerabilidades (CVSS) da versão 3 do Banco de Dados Nacional de Vulnerabilidades (NVD). As regras de Avaliação e Relatório de Vulnerabilidades de 2026 exigem que o provedor estime o impacto potencial de uma vulnerabilidade na agência como uma classificação N, que varia de N0 a N5.
Quando começa a contagem regressiva para a correção de não conformidades do FedRAMP?
A página antiga “Plano de Ação e Marcos”, agora apenas para referência, contabiliza 30, 90 ou 180 dias a partir da descoberta, dependendo do nível de risco. As regras de Detecção e Resposta a Vulnerabilidades de 2026 contabilizam a partir da avaliação, que, segundo as regras de Avaliação e Relatório de Vulnerabilidades, deve ocorrer após a detecção em 14, 7, 5 ou 2 dias, dependendo da classe de certificação.
Quais termos do FedRAMP abrangem uma constatação para a qual não há correção disponível?
“Dependência do fornecedor” e “requisito operacional” são termos herdados da página “Plano de Ação e Marcos”. O primeiro se refere a uma vulnerabilidade que aguarda uma correção do fornecedor, e o segundo, a uma vulnerabilidade que não pode ser corrigida. As regras de “Detecção e Resposta a Vulnerabilidades” de 2026 recomendam a mitigação parcial, e as regras de “Avaliação e Relatórios de Vulnerabilidades” exigem a aplicação do rótulo de vulnerabilidade aceita caso a mitigação total ou a correção não ocorram dentro de 192 dias após a avaliação.
O que é considerado “corrigido” de acordo com as regras do FedRAMP para 2026?
Uma vulnerabilidade corrigida, segundo as definições das Regras Consolidadas para 2026, foi neutralizada ou eliminada e não é mais detectada. Uma vulnerabilidade totalmente mitigada ainda é detectada, mas seu risco é insignificante. As regras de Detecção e Resposta a Vulnerabilidades acrescentam que mitigação e correção não são conceitos intercambiáveis.
Como o FedRAMP denomina uma vulnerabilidade cujo prazo não foi cumprido?
Uma vulnerabilidade é considerada em atraso quando o provedor ainda planeja mitigá-la ou corrigi-la totalmente, mas já ultrapassou, ou irá ultrapassar, o prazo estabelecido. Se o provedor não tiver essa intenção, trata-se, então, de uma vulnerabilidade aceita. De acordo com as regras de Avaliação e Relatórios de Vulnerabilidades de 2026, cada relatório deve sinalizar uma vulnerabilidade que esteja em atraso ou que provavelmente ficará em atraso, acompanhada de uma explicação.
