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
- Os provedores Rev5 mantêm o POA&M antigo até adotarem as regras de vulnerabilidade do FedRAMP para 2026, que passarão a ser obrigatórias a partir de 7 de dezembro de 2026.
- Um problema detectado no scanner que seja corrigido antes do prazo de vencimento não precisa ser registrado no POA&M antigo, e um problema já listado é encerrado assim que a comprovação da correção estiver pronta.
- A aplicação de patches de rotina na biblioteca dispensa a aprovação da agência, conforme o Manual de Procedimentos antigo, e a notificação, conforme as regras de 2026.
- Um componente corrigido que ainda é sinalizado por um scanner não possui um status claro de acordo com as definições do FedRAMP para 2026.
Se você é um provedor de serviços em nuvem (CSP) que oferece componentes de código aberto, uma correção em um deles pode alterar o que está previsto no seu plano de ação e marcos (POA&M). O guia antigo não exige que você liste uma vulnerabilidade detectada por um scanner que você corrija antes do prazo de vencimento. Uma vulnerabilidade já listada pode passar para o status “Fechada” assim que as ações corretivas forem aplicadas e as evidências de mitigação estiverem prontas para verificação por terceiros.
A página antiga do FedRAMP sobre POA&M agora está marcada como “apenas para referência”, e suas regras de vulnerabilidade da Classe C da Revisão 5 (Rev5) de 2026 não incluem nenhuma regra de POA&M para provedores. Até que você adote essas regras, que passarão a ser obrigatórias em 7 de dezembro de 2026, você ainda mantém o POA&M antigo. Então, o que uma correção altera no status de um item, quem verifica o novo status e qual processo de mudança se aplica, antes e depois da transição? As respostas estão em documentos diferentes, e nenhum deles aborda uma correção retroativa.
Um componente corrigido está em conformidade com as regras de entrada e encerramento do FedRAMP, mas os documentos deixam duas lacunas: se um mantenedor de código aberto é considerado um fornecedor e qual é o status do componente enquanto um scanner ainda o sinaliza.
A situação atual do POA&M do FedRAMP
De acordo com o processo Rev5 antigo, você mantém o POA&M no modelo do FedRAMP. O guia antigo para esse modelo, o Guia de Preenchimento do Modelo POA&M (versão 2.2, 23 de novembro de 2021), descreve o POA&M como um registro das vulnerabilidades conhecidas e das deficiências de segurança do sistema, acompanhadas das ações corretivas planejadas. Você envia uma cópia atualizada mensalmente como parte do seu ciclo de monitoramento contínuo, e o responsável pela autorização (AO) da agência a analisa de acordo com o Manual de Monitoramento Contínuo antigo. Desde 24 de junho de 2026, o site antigo do FedRAMP descreve sua página do POA&M e o Manual como meras referências durante a transição para as regras de 2026.
As regras do FedRAMP relativas à Detecção e Resposta a Vulnerabilidades (VDR) e à Avaliação e Relatório de Vulnerabilidades (VER) foram abertas para adoção opcional em 4 de julho de 2026. Elas passarão a ser obrigatórias para os provedores da Rev5 em 7 de dezembro de 2026, e o período de carência termina em 7 de março de 2027. Os prazos para mitigação e correção começam quando o provedor avalia uma vulnerabilidade, e os provedores devem relatar as atividades de detecção e resposta a vulnerabilidades a todas as partes necessárias pelo menos uma vez por mês.
As regras citadas aqui são as versões da Classe C do FedRAMP. O FedRAMP afirma que a Classe C abrange a maioria dos objetivos de segurança de nível Baixo e Moderado, e os provedores certificados na Classe B ou D devem verificar as regras da respectiva classe. Nas regras da Classe C da Rev5, a única regra relativa a POA&M é “Manter Planos de Ação e Marcos da Agência” (VER-AGM-MAP), e ela se dirige às agências. Ela estabelece que elas DEVEM utilizar o que você relatar para manter os POA&Ms de seus próprios programas de segurança quando a política da agência assim o exigir. O FedRAMP define “DEVEM” como uma regra da qual uma parte pode se afastar por motivos válidos, desde que documente a decisão, e “DEVEM” como um requisito absoluto. O resumo do FedRAMP sobre as alterações de 2026 afirma que os POA&Ms “foram totalmente eliminados”. Qualquer POA&M sob as regras de 2026 é de responsabilidade exclusiva da agência, elaborado a partir de seus relatórios.
Como um item entra e sai do POA&M
De acordo com o guia antigo, o prazo determina se uma constatação do scanner chega ao POA&M do FedRAMP durante o monitoramento contínuo. Você a lista assim que ela estiver vencida (30, 90 ou 180 dias a partir da constatação, dependendo da gravidade). Constatações provenientes de outras fontes, como testes de penetração e entrevistas, são incluídas independentemente de estarem ou não vencidas. O mesmo vale para cada item com uma solicitação de desvio — o formulário que você envia à sua AO para um falso positivo, um ajuste de risco ou um requisito operacional. Uma nota de rodapé indica que qualquer acordo de nível de serviço ou preferência da AO ainda se aplica, e qualquer um deles pode exigir a listagem de todos os riscos em aberto.
De acordo com o guia, um item pode ser transferido para a planilha “Fechado” assim que você tiver aplicado todas as ações corretivas e tiver “evidências de mitigação” prontas para inspeção. Uma organização de avaliação terceirizada (3PAO) — termo antigo que as definições de 2026 substituem por “avaliador” — verifica as evidências durante as avaliações iniciais e periódicas, e sua AO pode solicitá-las a qualquer momento. Um item também pode ser transferido para lá quando sua AO aprovar uma solicitação de desvio por falso positivo. As dependências de fornecedores, que aguardam a correção por parte do fornecedor, e os requisitos operacionais, que a página POA&M antiga descreve como constatações que não podem ser corrigidas, permanecem na planilha “Aberto”.
Observação: O guia antigo indica que os falsos positivos identificados no Relatório de Avaliação de Segurança (SAR), comprovados por evidências de apoio, como um relatório de verificação sem problemas, não precisam ser incluídos no POA&M.
| Palco | Documentos antigos | Regras de 2026 | Base |
|---|---|---|---|
| Entra | Resultados do scanner que já estão vencidos. Outros resultados, estejam eles vencidos ou não. Itens com solicitações de revisão. | Um relatório mensal sobre as atividades de detecção e resposta a vulnerabilidades, destinado a todas as partes envolvidas. Nenhuma regra da norma 2026 exige que os provedores mantenham um POA&M. | Guia de sistemas legados §3; VER-TFR-MHR e VER-RPT-VDT (2026, OBRIGATÓRIO) |
| Quando nenhuma solução dá certo | As dependências de fornecedores e os requisitos operacionais permanecem em aberto. | Uma vulnerabilidade que não seja, ou que não se preveja que seja, totalmente mitigada ou corrigida no prazo de 192 dias a partir da avaliação é classificada como vulnerabilidade aceita. | Página antiga do POA&M (apenas para referência); VER-TFR-MAV (2026, OBRIGATÓRIO) |
| Encerra | Ações corretivas aplicadas com evidência de mitigação ou um falso positivo aprovado pela AO. | Não há nenhum status de encerramento definido. “Corrigido” (neutralizado ou eliminado, não mais detectado) é o estado final, com uma disposição final no relatório. | Guia de sistemas legados §2.2; Definições de 2026; VER-RPT-VDT (2026, OBRIGATÓRIO); VDR-CSO-RES |
| Verificado por | Um 3PAO, durante as avaliações iniciais e periódicas. O escopo da avaliação anual também abrange itens encerrados, dependências de fornecedores e solicitações de desvio. O AO aprova os falsos positivos. | As regras do Rev5 para VDR e VER da Classe C não mencionam ninguém especificamente. Uma avaliação independente anual abrange todas as regras aplicáveis. | Guia do sistema antigo §2.2; página da Avaliação Anual do sistema antigo; VDR e VER (2026); IVV-CSO-FIA (2026, OBRIGATÓRIO) |
| Mantido por | O CSP, com a AO realizando revisões mensais. | Órgãos, para seus próprios programas. | Manual de Referência, Visão Geral; VER-AGM-MAP (2026, RECOMENDADO) |
O que um componente corrigido altera
Neste artigo, um componente corrigido é uma biblioteca ou pacote que você implanta depois que um mantenedor, fornecedor ou outra parte disponibiliza uma correção. Não se trata de um termo do FedRAMP.
O registro e o encerramento são eventos distintos no guia antigo. Se você implementar uma correção antes que o prazo de uma vulnerabilidade detectada pelo scanner tenha expirado, o guia não exige que seja feito um registro para ela. Se o item já estiver listado, a correção implementada conta como uma de suas ações corretivas, e o encerramento segue as duas etapas previstas no guia.
A dependência de um fornecedor segue um cronograma diferente. A página POA&M legada a vincula a um fornecedor a jusante, como o fabricante de um produto comercial pronto para uso (COTS), cuja correção ainda não está disponível. Uma dependência de fornecedor de alto risco ainda precisa ser mitigada para um nível moderado por meio de controles compensatórios no prazo de 30 dias. Assim que o fornecedor disponibilizar a correção, o guia inicia o período de correção a partir dessa data, solicita que você registre a data de lançamento e permite que você substitua a data de conclusão programada.
A página antiga do POA&M também recomenda apresentar evidências das interações com os fornecedores sobre o status das correções, como notificações e trocas de e-mails. Esse é um tipo diferente de evidência daquelas relacionadas à mitigação que encerram um item.
A implantação da correção também é uma mudança. O Playbook legado classifica as mudanças em rotineiras recorrentes, adaptativas e transformativas. Ele classifica patches menores e incrementais, sem alterações que causem quebra de compatibilidade — incluindo patches de rotina em bibliotecas — como mudanças rotineiras recorrentes que não exigem revisão e aprovação da AO. Atualizações em bibliotecas com alterações conhecidas que causam quebra de compatibilidade são um exemplo de mudança adaptativa, que, por sua vez, exige essa revisão e aprovação.
As regras de Notificação de Mudança Significativa (SCN) de 2026 mantêm esses três tipos. De acordo com a regra “Avaliar Mudanças” (SCN-CSO-EVA), você avalia cada possível mudança significativa para determinar seu tipo. A regra “Sem Requisitos de Notificação” (SCN-RTR-NNR) estabelece que os provedores NÃO DEVEM enviar notificações formais para mudanças recorrentes de rotina. O FedRAMP atribui à expressão “NÃO DEVE” a mesma flexibilidade que à expressão “DEVE”. Seus exemplos ainda incluem a aplicação de patches de rotina em bibliotecas. De acordo com a regra “Requisitos de Notificação” (SCN-ADP-NTF), a notificação deve ser enviada no prazo de 10 dias úteis após a conclusão de uma alteração adaptativa. As regras da SCN serão obrigatórias para os provedores da Rev5 a partir de 1º de janeiro de 2027.
O que os documentos deixam em aberto
A responsabilidade recai sobre você, independentemente de quem elabore a correção. A regra de Resposta a Vulnerabilidades (VDR-CSO-RES) atribui ao provedor a responsabilidade de rastrear, mitigar e corrigir as vulnerabilidades detectadas. A regra de Detecção de Vulnerabilidades (VDR-CSO-DET) inclui o monitoramento da cadeia de suprimentos entre as formas pelas quais um provedor as detecta; portanto, você também deve detectar as vulnerabilidades que vêm com um componente.
Quando se está aguardando a correção de outra pessoa, os documentos legados informam o status de dependência do fornecedor, mas nem o guia nem a página POA&M especificam se um mantenedor de código aberto é considerado um fornecedor. Se for o caso, uma vulnerabilidade que ainda aguarda a correção do mantenedor pode permanecer aberta, com verificações mensais. Caso contrário, ela fica vencida como qualquer outra descoberta do scanner. Essa é a primeira lacuna.
Um componente corrigido cuja correção não altere o número da versão pode continuar aparecendo nos resultados da verificação após sua implantação. A documentação da Red Hat sobre retroportabilidade de segurança explica o motivo: algumas ferramentas de verificação e auditoria determinam se um componente está vulnerável com base exclusivamente no número da versão. Essas ferramentas sinalizam um componente como vulnerável quando uma correção proveniente de uma versão mais recente é aplicada a uma versão mais antiga.
Nas definições do FedRAMP de 2026, uma vulnerabilidade corrigida é neutralizada ou eliminada e não é mais detectada. Uma vulnerabilidade totalmente mitigada apresenta risco insignificante, mas ainda é detectada. Um falso positivo é uma vulnerabilidade detectada que não está realmente presente e nunca esteve. O guia antigo vincula o encerramento à evidência de mitigação, enquanto as regras de 2026 mantêm a mitigação e a correção separadas (VDR-CSO-RES).
Observação: a definição de falsos positivos do FedRAMP também exclui vulnerabilidades corrigidas e totalmente mitigadas.
Considere um componente corrigido que ainda é sinalizado por um scanner. De acordo com essas definições, ele não é considerado corrigido enquanto for detectado, e não se trata de um falso positivo, pois a vulnerabilidade já existia antes da correção. A expressão “totalmente mitigado” é a que mais se aproxima em termos de redação, mas nenhum dos documentos citados neste artigo afirma isso para uma correção que não altera o número da versão.
O guia antigo também deixa o status em aberto. Você pode encerrar um item caso haja evidência de correção ou solicitar ao seu AO que aprove um falso positivo. O guia não especifica qual das opções se aplica a um componente corrigido que o scanner ainda sinaliza. O mesmo problema ocorre na entrada: uma falha que o scanner continua sinalizando pode ficar vencida, mesmo que você já a tenha corrigido.
Essa é a segunda lacuna. Antes de fazer a mudança, pergunte ao seu AO ou avaliador qual status eles esperam para esse componente no POA&M antigo e nos seus relatórios de vulnerabilidade de 2026. Pergunte também se eles consideram um mantenedor de código aberto como um fornecedor.
Obter uma correção sem precisar esperar pelo responsável pela manutenção
O SecureChain, da TuxCare, analisa o código-fonte de pacotes de código aberto em busca de malware, recompila-os a partir desse código em ambientes isolados e bloqueia os pacotes que não passam na inspeção antes que cheguem ao seu ambiente. Sob um acordo de nível de serviço, o SecureChain aplica patches nos componentes ativos. Para versões que os mantenedores originais não oferecem mais suporte, o Endless Lifecycle Support (ELS) faz o backport de correções para vulnerabilidades de gravidade crítica, alta, média e baixa para as versões em uso. Juntos, o SecureChain e o ELS abrangem JavaScript, Python, Java, Go, PHP e Rust. Os registros do SecureChain sobre o que ele fornece incluem proveniência de Nível 3 do Supply-chain Levels for Software Artifacts (SLSA), uma lista de materiais de software (SBOM) e dados do Vulnerability Exploitability eXchange (VEX). Os dados do VEX podem indicar que um pacote já contém a correção para uma vulnerabilidade. Isso fornece ao seu AO ou avaliador um registro para verificar quando um scanner ainda sinalizar o pacote.
Se você não souber de onde virá a correção para um componente quando seu mantenedor deixar de fornecê-la, ou quais vulnerabilidades esse componente trouxe para o seu serviço, veja como o SecureChain para Software de Código Aberto aborda ambas as questões.
Perguntas frequentes
O que é um POA&M nos documentos do FedRAMP?
Um plano de ação e marcos (POA&M) é, conforme o Guia de Preenchimento do Modelo de POA&M do FedRAMP (versão 2.2, 23 de novembro de 2021), um registro das vulnerabilidades e deficiências de segurança conhecidas de um sistema, acompanhado das ações corretivas planejadas por um provedor de serviços em nuvem (CSP). O FedRAMP marcou sua página antiga do POA&M como sendo apenas para referência desde 24 de junho de 2026.
Quem é responsável pela manutenção e revisão de um POA&M?
No Manual de Monitoramento Contínuo (Playbook) antigo, o provedor de serviços em nuvem (CSP) envia mensalmente um plano de ação e marcos (POA&M) atualizado, e o responsável pela autorização da agência o analisa. O FedRAMP classificou o Manual como sendo apenas para referência desde 24 de junho de 2026. De acordo com a regra VER-AGM-MAP das regras de Avaliação e Relatórios de Vulnerabilidades de 2026, as agências DEVEM (é recomendado que) mantenham seus próprios POA&Ms quando suas políticas de segurança assim o exigirem.
O que o relatório de vulnerabilidades de um provedor deve incluir de acordo com as regras de 2026?
A regra VER-RPT-VDT das normas de Avaliação e Relato de Vulnerabilidades do FedRAMP, com vigência a partir de 7 de dezembro de 2026, especifica o que um provedor deve relatar sobre cada vulnerabilidade detectada. Entre os exemplos estão o momento e a origem da detecção, a acessibilidade pela Internet, a provável explorabilidade, o dano estimado às agências (a classificação N de Impacto Potencial na Agência) e a disposição final. As vulnerabilidades aceitas — que não são, ou não se espera que sejam, totalmente mitigadas ou corrigidas no prazo de 192 dias a partir da avaliação — são listadas separadamente.
Quando se aplicam as regras do FedRAMP de 2026 relativas a mudanças significativas?
A adoção opcional das regras de Notificação de Mudanças Significativas do FedRAMP, contidas nas Regras Consolidadas para 2026, teve início em 4 de julho de 2026. Para os provedores da Revisão 5 (Rev5), essas regras passam a ser obrigatórias a partir de 1º de janeiro de 2027, e o período de carência termina em 1º de junho de 2027. As regras relativas a vulnerabilidades seguem seus próprios prazos.
O que as solicitações e notificações de alterações significativas revelam sobre as vulnerabilidades relacionadas?
Uma solicitação de mudança significativa do sistema legado lista o item relacionado ao plano de ação e marcos (POA&M) quando a mudança aborda um risco conhecido, de acordo com o Manual de Monitoramento Contínuo do sistema legado, que o FedRAMP agora classifica como sendo apenas para referência. De acordo com a regra SCN-CSO-INF das regras de Notificação de Mudanças Significativas de 2026, uma notificação deve incluir a vulnerabilidade relacionada, se aplicável, entre outros detalhes exigidos.
