
Ao falar sobre fornecedores que alegam não ter recursos para corrigir uma vulnerabilidade conhecida e explorável em poucos dias, o diretor do FedRAMP afirmou categoricamente que não os quer no mercado federal. Depois de quase duas décadas construindo e autorizando sistemas para clientes federais, não me lembro da última vez que um funcionário do FedRAMP traçou uma linha tão clara. É a linha certa e já deveria ter sido traçada há muito tempo.
O alerta de Waterman não foi totalmente inesperado, pois ele citou diretamente o recente incidente da Hugging Face, no qual modelos de IA operando em um ambiente de teste fechado encontraram uma falha desconhecida, escaparam do ambiente e usaram credenciais roubadas para acessar um sistema de produção antes que alguém percebesse. A lição é a que a comunidade de fornecedores precisa ouvir. Os ataques agora se movem mais rápido do que os ciclos de atualização, que normalmente são feitos por humanos, conseguem acompanhar, e um programa de conformidade baseado em revisões periódicas não os detectará.
Os comentários de Waterman representam um desafio direto à forma como muitos fornecedores de software para o governo ainda estão organizados, com a segurança funcionando como uma camada de revisão separada que avalia o trabalho depois de entregue, em vez de em conjunto com ele. Existe uma versão da autorização FedRAMP que trata a conformidade como um mero exercício burocrático. Uma equipe de segurança redige as políticas, enquanto uma equipe de engenharia separada desenvolve o código, e um Plano de Ações e Marcos (PAIR), o documento formal do governo para rastrear problemas de segurança em aberto, é revisado trimestralmente, quando alguém se lembra de analisá-lo. Waterman mencionou isso diretamente, afirmando que os fornecedores não atenderão às expectativas do governo se a equipe de conformidade estiver separada dos engenheiros que desenvolvem e mantêm o produto.
Os requisitos de detecção e resposta a vulnerabilidades do FedRAMP 20x são específicos. Espera-se que os provedores comecem a reduzir o risco de vulnerabilidades graves expostas à internet em dois a quatro dias, dependendo da gravidade. O estado de segurança do sistema deve ser verificado pelo menos a cada três dias. No cenário atual, isso significa responder às descobertas dentro de prazos rígidos, e não apenas quando o próximo ciclo de lançamento for concluído. Nada disso é viável em um cronograma trimestral. Só é viável se a equipe que desenvolve o produto for a mesma que corrige as vulnerabilidades de segurança.
A autorização contínua exige entrega contínua. Se sua infraestrutura for definida como código, seus contêineres de software forem verificados a cada build e seu pipeline de implantação puder enviar uma correção para produção no mesmo dia em que uma descoberta crítica for detectada, então você não estará escolhendo entre agilidade e conformidade. O pipeline se torna parte do próprio controle de segurança.
Verificação automatizada e frequente
Os ambientes de produção precisam ser verificados regularmente, com as descobertas encaminhadas diretamente para a equipe de engenharia responsável pela correção, e não para uma fila que um analista de conformidade revisa semanas depois.
O pipeline de implantação como sistema de registro para gerenciamento de mudanças. Ferramentas modernas de implantação automatizada não são obstáculos aos requisitos federais de controle de mudanças. Quando configuradas corretamente, elas geram o rastro de evidências exato exigido por esses requisitos.
Remediação orientada por prazos, não por calendário. Descobertas críticas são tratadas dentro de prazos rigorosos. Se um fornecedor não puder manter esse ritmo, a conversa precisa acontecer antes da entrada em produção do sistema, e não depois.
Os fornecedores que terão dificuldades com o FedRAMP 20x são aqueles que tratam a segurança como uma barreira no final do processo. Aqueles que tiverem sucesso tratarão o próprio pipeline como o controle, onde cada alteração de código é analisada, cada contêiner é verificado e cada correção é enviada pelo mesmo caminho automatizado que cada novo recurso.
A orientação prática resultante do evento do mês passado é direta. Audite seu cronograma de aplicação de patches agora mesmo! Se o seu processo para mover uma correção crítica da fase de descoberta para a produção leva mais de dois a quatro dias, essa lacuna precisa ser fechada antes que a aplicação do FedRAMP 20x se torne ainda mais rigorosa.
Esse não é um problema futuro. É um problema atual, e o incidente da Hugging Face é a prova mais clara até agora de por que isso importa.
A autorização FedRAMP, construída sobre uma base moderna de entrega automatizada, não é apenas mais rápida de se obter. É a única versão de autorização que resistirá a ameaças que se movem na velocidade das máquinas.
Hemant Baidwan é o Diretor de Segurança da Informação da Knox Systems, onde lidera a estratégia de cibersegurança corporativa e o desenvolvimento de plataformas de segurança nativas da nuvem e orientadas por IA. Anteriormente, atuou como CISO e Diretor Adjunto Interino de Informação no Departamento de Segurança Interna dos EUA (DHS), onde foi responsável por proteger um dos maiores e mais complexos ambientes federais civis.
