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
- O manual do Programa Federal de Gestão de Riscos e Autorizações (FedRAMP), Revisão 5 (Rev5), exige que os prestadores enviem mensalmente um plano de ação atualizado e os marcos a serem alcançados.
- As Regras Consolidadas do FedRAMP para 2026 estabelecem 7 de dezembro de 2026 como a data de adoção das novas regras relativas a vulnerabilidades, com o período de carência terminando em 7 de março de 2027.
- Uma falha não corrigida permanece nos relatórios mensais do provedor até que seja sanada, e as regras de 2026 exigem que ela seja classificada como uma vulnerabilidade aceita caso não seja totalmente mitigada ou sanada no prazo de 192 dias a partir da avaliação.
- Imagens base, dependências fixadas e componentes abandonados fazem com que as mesmas falhas de código aberto continuem aparecendo até que alguém altere a compilação.
- Uma equipe de plataforma pode programar a atualização das imagens base, avaliar os problemas recorrentes e decidir antecipadamente o que fazer em relação aos componentes para os quais não há correção no upstream.
O monitoramento contínuo do FedRAMP (ConMon) exige que um provedor de serviços em nuvem envie um plano de ação e marcos (POA&M) atualizado todos os meses. Cada vulnerabilidade específica recebe um item próprio nesse plano. Se um componente da sua versão ainda apresentar uma constatação pendente, essa constatação tende a permanecer no POA&M no mês seguinte. Esse é o caminho da Revisão 5 (Rev5) no Manual de Monitoramento Contínuo do FedRAMP, o Programa Federal de Gestão de Riscos e Autorizações.
Uma constatação que se repete mensalmente coloca a mesma opção de código aberto novamente à disposição dos revisores, e é isso que o título quer dizer com “reavaliar”. No caminho da Rev5, o Manual orienta que as reuniões ConMon, envolvendo várias agências, se concentrem em itens em atraso, dependências de fornecedores e tudo o que exija aceitação de risco. Os avaliadores também validam solicitações de desvio e dependências de fornecedores em cada avaliação anual. De acordo com as regras do FedRAMP para 2026, uma constatação que ainda não tenha sido totalmente mitigada ou corrigida 192 dias após a avaliação deve ser classificada como vulnerabilidade aceita, acompanhada de uma explicação por escrito do motivo. A partir de 2027, cada agência cliente também receberá um resumo das vulnerabilidades aceitas a cada trimestre.
As regras do FedRAMP para 2026 também determinam que os provedores devem projetar seus serviços de forma a reduzir o risco de vulnerabilidades por padrão. No caso de componentes de código aberto, isso significa escolher o que será incluído na sua compilação, e cabe à equipe de plataforma fazer essas escolhas.
Como funciona o monitoramento contínuo do FedRAMP mês a mês
Na trajetória Rev5 (Playbook versão 1.0, 17 de novembro de 2025), o provedor realiza varreduras em sistemas operacionais, aplicativos da web e bancos de dados pelo menos uma vez por mês. Em seguida, ele envia o POA&M e o inventário atualizados, além dos arquivos brutos das varreduras, quando seus contratos com a agência assim o exigirem. O responsável pela autorização da agência analisa o POA&M e aprova as solicitações de desvio, que pedem à agência para tratar uma constatação como um falso positivo, um ajuste de risco ou um requisito operacional.
As Regras Consolidadas do FedRAMP para 2026 (CR26) foram lançadas em 24 de junho de 2026. Dois de seus conjuntos de regras — Detecção e Resposta a Vulnerabilidades e Avaliação e Relatórios de Vulnerabilidades — abrangem as Classes B a D da Rev5 e as Classes B e C do 20x, a mais recente via de certificação do FedRAMP. Alguns prazos dependem tanto da via quanto da classe. A adoção antecipada teve início em 4 de julho de 2026. Novos candidatos devem seguir os conjuntos de regras a partir de 7 de dezembro de 2026. Os provedores existentes devem adotá-los até essa data ou enfrentarão um plano de ação corretiva. Em 7 de março de 2027, o período de carência termina, e o FedRAMP revoga a certificação dos provedores que não o tiverem feito.
| Item | Manual do Rev5 v1.0 | Regras relativas à vulnerabilidade CR26, a partir de 15 de outubro de 2026 | Base |
|---|---|---|---|
| Digitalização e verificação | Os sistemas operacionais, as aplicações web e os bancos de dados são verificados pelo menos uma vez por mês | Os provedores das Classes C e D da Rev5 devem verificar e validar os recursos baseados em máquinas pelo menos uma vez por mês (os provedores da Classe B devem fazer o mesmo). Os provedores da Classe C 20x devem fazê-lo a cada 3 dias. | Requisitos do FedRAMP |
| Relatório mensal | Atualização do POA&M e do estoque | A atividade relacionada a vulnerabilidades é relatada pelo menos mensalmente, em um formato consistente e de fácil compreensão. Os relatórios também resumem toda a atividade ocorrida desde o relatório anterior (Rev5, Classes B a D). | Requisitos do FedRAMP |
| Achados não esclarecidos | Registrados como itens POA&M. As solicitações de desvio precisam da aprovação da agência. | Deve ser marcada como uma vulnerabilidade aceita, acompanhada de uma explicação, caso não tenha sido ou não venha a ser totalmente mitigada ou corrigida no prazo de 192 dias a partir da avaliação. | Orientações do manual do escritório do programa; requisito CR26 (OBRIGATÓRIO) |
Para onde vão as conclusões não definidas após o primeiro relatório
No caminho Rev5, uma não conformidade não corrigida é acompanhada no POA&M com um plano de correção, e o prestador de serviços pode apresentar um pedido de desvio para que a agência tome uma decisão. Um item do POA&M que dependa de um fornecedor anterior é acompanhado como uma dependência de fornecedor.
Para um provedor com mais de um cliente de agência, o Manual descreve uma reunião colaborativa mensal do ConMon. Ele afirma que abordar todos os itens do POA&M não é prático, especialmente aqueles que o provedor espera resolver dentro dos prazos estabelecidos pelo FedRAMP. A discussão deve se concentrar em itens vencidos, dependências de fornecedores e solicitações de desvio, especialmente aquelas que exigem aceitação de risco. Portanto, uma constatação que permaneça em aberto após sua data de vencimento deve ser apresentada a todas as agências do grupo.
De acordo com as Regras Consolidadas do FedRAMP para 2026: o FedRAMP recomenda que as agências analisem apenas vulnerabilidades vencidas e aceitas com uma classificação “N” de Impacto Potencial para a Agência superior a 2, a menos que o provedor recomende medidas de mitigação ou que o serviço esteja em um sistema federal de risco mais elevado. A classificação N, que varia de N0 a N5, é a estimativa do provedor quanto à extensão dos danos que a exploração poderia causar às agências que utilizam o serviço. Vulnerabilidades aceitas geralmente precisam ser analisadas apenas quando são adicionadas ou quando o uso pela agência sofre alterações.
As regras de 2026 também limitam por quanto tempo um provedor pode manter uma descoberta em aberto enquanto planeja corrigi-la. Ele deve classificar qualquer vulnerabilidade que não seja, ou não venha a ser, totalmente mitigada ou corrigida no prazo de 192 dias a partir da avaliação como uma vulnerabilidade aceita. A partir daí, cada relatório mensal explica o motivo, se a vulnerabilidade é acessível pela internet, se é provável que seja explorável e sua classificação N atual.
| Resultado | O que dizem as regras | Base |
|---|---|---|
| Mitigação parcial | Reduz o risco sem eliminar a vulnerabilidade. Quando não for possível uma mitigação ou correção total, os provedores devem agir de forma imediata, progressiva e persistente. | Nota de orientação do FedRAMP (DEVE) |
| Mitigação total | Reduz o risco a um nível insignificante, mas a vulnerabilidade continua existindo até que seja corrigida. | Nota de orientação do FedRAMP |
| Remediação | Elimina totalmente a vulnerabilidade. | Nota de orientação do FedRAMP |
| Vulnerabilidade confirmada | Rótulo para uma vulnerabilidade que o provedor não pretende mitigar ou corrigir totalmente. Obrigatório quando uma vulnerabilidade não for, ou não venha a ser, totalmente mitigada ou corrigida no prazo de 192 dias a partir da avaliação. O provedor deve explicar o motivo. | Definição; requisito (DEVE) |
| Falso positivo | Os provedores devem avaliar as vulnerabilidades detectadas para determinar se se trata de falsos positivos. | Recomendação (DEVE) |
Aceitar uma constatação transfere a decisão sobre o risco para seus clientes: cada órgão decide se deseja continuar utilizando o serviço com a constatação em aberto, e o FedRAMP solicita que os órgãos registrem essa decisão em seu próprio POA&M.
Por que as mesmas conclusões sobre o código aberto continuam surgindo
Para sistemas em contêineres, o Playbook exige um identificador exclusivo de ativo para cada classe de imagem de contêiner e vincula cada contêiner de produção à sua imagem de origem. Ele também determina que a aplicação de patches de software deve ocorrer na imagem de substituição, nunca diretamente no ambiente de produção. Assim, um pacote vulnerável em uma imagem base tende a aparecer em todos os contêineres criados a partir dela, e a solução usual é criar uma nova imagem. Até que alguém faça um rebase, o conjunto de pacotes tende a permanecer o mesmo, e a vulnerabilidade continua presente.
As dependências fixadas funcionam da mesma maneira. Um arquivo de bloqueio mantém uma biblioteca na versão que você escolheu; assim, uma biblioteca com um aviso de vulnerabilidade em aberto permanece nessa versão até que alguém a altere. Para um componente mantido ativamente, a solução é uma versão corrigida do desenvolvedor original, que alguém então incorpora à sua compilação. A atualização traz seus próprios riscos, e nossa publicação sobre por que “basta atualizar” é um conselho de segurança inadequado aborda esse assunto.
Quando o desenvolvedor original deixa de oferecer suporte a um componente, novas vulnerabilidades ainda podem ser divulgadas a respeito dele, mas geralmente não há previsão de lançamento de uma versão corrigida. A vulnerabilidade permanece, então, em aberto até que o componente seja substituído ou alguém aplique um patch na versão que você utiliza, mesmo após o prazo de 192 dias forçar a atribuição do rótulo “aceita”. Um serviço raramente se limita a uma única linguagem de programação; assim, componentes abandonados podem se acumular em vários ecossistemas ao mesmo tempo.
O que os scanners não revelam sobre uma encomenda
A saída da varredura é baseada em vulnerabilidades conhecidas. O Playbook exige o número de referência do Common Vulnerabilities and Exposures (CVE) em resultados legíveis por máquina para qualquer vulnerabilidade listada no Banco de Dados Nacional de Vulnerabilidades. As regras de 2026 indicam que as orientações anteriores do FedRAMP geralmente se concentravam em vulnerabilidades do tipo CVE e deixavam outros tipos sem tratamento, e a lista de regras de detecção inclui o monitoramento da cadeia de suprimentos entre as técnicas utilizadas pelos provedores.
Os scanners e outras ferramentas de monitoramento contínuo do FedRAMP utilizadas por um provedor geram relatórios sobre o que está presente na compilação. Um pacote que tenha sido adulterado ou compilado a partir de uma fonte diferente de seu código-fonte público pode não aparecer como um resultado de CVE, e um pacote malicioso pode nem mesmo ter um CVE. Uma lista de materiais de software (SBOM) apresenta o mesmo ponto cego: um componente pode estar listado corretamente, mas ainda assim ter sido adulterado. Ambos descrevem o que chegou, mas nenhum deles indica se isso deveria ter acontecido.
O que a Engenharia de Plataforma pode mudar antes do próximo relatório
Se você for o responsável pela compilação submetida ao ciclo de monitoramento contínuo do FedRAMP, poderá alterar o conteúdo do próximo relatório modificando o que é incluído nessa compilação.
De acordo com as Regras Consolidadas do FedRAMP para 2026: os provedores devem avaliar as vulnerabilidades por agrupamentos lógicos de recursos afetados, e as regras de detecção e resposta do FedRAMP se aplicam, então, a cada agrupamento, e não a cada instância.
Comece agendando as atualizações das imagens base. Programe-as de forma que as imagens reconstruídas estejam em produção antes da sua verificação mensal, para que qualquer correção na imagem base atualizada apareça no próximo relatório. De acordo com a regra de agrupamento, um pacote vulnerável em uma única imagem base pode ser tratado como um único agrupamento, mesmo que apareça em vários contêineres.
Avalie quantas falhas se repetem antes de defender a necessidade de corrigi-las. Pegue seus três últimos relatórios e conte as falhas que aparecem em todos eles. Isso mostra, de forma aproximada, qual a parcela do trabalho mensal que é acumulada e fornece ao responsável pelo financiamento do trabalho uma base para agir. Em seguida, identifique separadamente as falhas recorrentes e as novas antes da triagem, já que as novas exigem uma avaliação nova e são fáceis de passar despercebidas entre itens já conhecidos.
Quando um componente não tiver uma correção disponível do fornecedor, decida, antes do prazo de 192 dias, se deve substituí-lo, aplicar um patch na versão que você utiliza ou aceitar a vulnerabilidade.
Inclua as dependências transitivas no inventário de pacotes, pois os pacotes que você escolheu diretamente representam apenas uma parte do que é fornecido.
Os problemas que sempre reaparecem têm origem na compilação, e é uma alteração nessa compilação que os resolve.
O papel do SecureChain no ciclo de vida do pacote
O SecureChain é o produto da TuxCare destinado aos pacotes de código aberto em sua compilação. Para os pacotes que abrange, ele os recompila a partir do código-fonte em ambientes isolados e altamente protegidos, inspecionando-os em busca de malware e código suspeito, impedindo que qualquer elemento com falha chegue ao seu ambiente. Cada pacote vem com atestado de proveniência SLSA Nível 3, SBOM e declaração VEX. Os pacotes que ainda recebem manutenção são monitorados quanto a novos CVEs e recebem correções por meio de um acordo de nível de serviço. Quando os mantenedores upstream interrompem a manutenção, a TuxCare faz o backport de correções críticas e de alta gravidade para as versões exatas que você está executando. A cobertura abrange JavaScript, Python, Java, Go e PHP.
Se o seu relatório mensal continuar apresentando componentes cujas correções foram descontinuadas pelo desenvolvedor original, verifique o que o SecureChain oferece.
Perguntas frequentes
O que é o ConMon no FedRAMP e o que é relatado mensalmente?
No FedRAMP, o programa federal dos EUA de autorização de serviços em nuvem, o monitoramento contínuo (ConMon) abrange os relatórios de segurança contínuos de um provedor após a autorização de seu serviço. Na trajetória da Revisão 5 (Rev5), os provedores de serviços em nuvem realizam varreduras mensais em sistemas operacionais, aplicativos da web e bancos de dados e enviam um plano de ação e marcos (POA&M) atualizado, bem como um inventário, de acordo com o Manual de Monitoramento Contínuo (versão 1.0).
Os provedores do Rev5 e do 20x relatam vulnerabilidades da mesma maneira?
De acordo com suas Regras Consolidadas para 2026, o FedRAMP exige que os provedores da Revisão 5 (Rev5) e os provedores 20x das Classes B e C relatem a atividade de vulnerabilidades pelo menos mensalmente e marquem como “aceita” qualquer vulnerabilidade que não tenha sido totalmente mitigada ou corrigida no prazo de 192 dias após a avaliação. A frequência das verificações varia de acordo com o caminho e a classe. Os provedores da Classe C da Rev5 devem verificar e validar os recursos baseados em máquinas pelo menos uma vez por mês, enquanto os provedores da Classe C 20x devem fazê-lo a cada 3 dias.
O que é uma vulnerabilidade aceita no FedRAMP?
De acordo com suas regras de 2026, o FedRAMP considera uma vulnerabilidade como aceita quando o provedor não tem a intenção de mitigá-la ou corrigi-la totalmente. Essa classificação também é exigida quando uma vulnerabilidade não for, ou não venha a ser, totalmente mitigada ou corrigida no prazo de 192 dias a partir da avaliação. Os provedores devem informar o motivo pelo qual cada vulnerabilidade é aceita, juntamente com sua acessibilidade pela internet, probabilidade de exploração e impacto estimado sobre a agência.
O que é uma solicitação de desvio no FedRAMP?
No FedRAMP, um provedor da Revisão 5 (Rev5) pode apresentar um pedido de desvio solicitando que a agência considere uma constatação como um falso positivo, um ajuste de risco ou um requisito operacional. O Manual de Monitoramento Contínuo estabelece que as agências aprovam esses pedidos e que os avaliadores os validam durante a avaliação anual.
As verificações do FedRAMP separam os pacotes de código aberto dos demais softwares?
O FedRAMP não classifica as constatações de acordo com o status de código aberto no Manual de Monitoramento Contínuo nem nas regras de vulnerabilidade de 2026. O Manual vincula as constatações aos ativos do inventário e às imagens de contêineres, e a regra de detecção de 2026 lista o monitoramento da cadeia de suprimentos como uma técnica. Rastrear a origem de uma constatação requer uma análise própria.
Quando entram em vigor as regras de vulnerabilidade do FedRAMP para 2026?
O FedRAMP iniciou a adoção opcional de suas regras de vulnerabilidade para 2026 em 4 de julho de 2026. Os novos candidatos deverão cumpri-las a partir de 7 de dezembro de 2026. Os prestadores já registrados devem adotar essas regras até essa data e, obrigatoriamente, até 7 de março de 2027; caso contrário, o FedRAMP revogará a certificação.
