AWS Continuum sai do preview fechado e passa a validar vulnerabilidades com exploits reais

O que mudou: Continuum sai do preview restrito

A AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → tornou o Continuum for Code Vulnerabilities disponível de forma geral (GA) nas regiões US East (N. Virginia) e US West (Oregon), segundo reportagem do InfoQ publicada em 6 de novembro de 2026. O serviço havia sido anunciado quatro meses antes, em preview fechado, ou seja, por volta de julho de 2026. A página de preços, que o anúncio oficial não menciona diretamente, revela um modelo cobrado tanto por linha de código protegida quanto por achado (finding) processado.

O serviço foi descrito pela arquiteta de soluções principal da AWS, Esra Kayabali, como uma ferramenta que encontra e valida vulnerabilidades de código, entregando correções como patches automatizáveis ou como pull requests nos repositórios conectados. Para isso, ele constrói um grafo de contexto a partir desses repositórios e do ambiente AWS ao redor, com um coletor opcional trazendo contexto de rede e de recursos de onde o código roda em produção.

Como a validação por exploit funciona na prática

Em vez de apenas ranquear achados por severidade, algo que scanners SAST/DAST tradicionais já fazem há anos, o Continuum tenta confirmar quais vulnerabilidades são de fato alcançáveis. Ele executa o exploit dentro de um sandbox isolado e anexa código de prova de conceito com os passos de reprodução, para que o time não precise reconstruir o ataque manualmente.

Cada achado recebe um "nível de evidência", que vai de um veredito comprovado por execução real até um veredito baseado em análise estática do caminho vulnerável. A saída final não é só um score de risco: é um attack path (caminho de ataque) e uma avaliação de blast radius (raio de impacto), segundo a descrição da AWS.

Swami Sivasubramanian, VP de Agentic AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → da AWS, e Christopher Rae, que lidera o go-to-market de segurança em IA na empresa, enquadraram o problema como volume, não como detecção. Sivasubramanian escreveu que a maioria das organizações com grandes bases de aplicações vê milhares de achados por dia; Rae foi mais direto:

A maioria deles vira ruído que não importa no seu ambiente.

Christopher Rae, líder de go-to-market de segurança em IA na AWSMost becomes noise that doesn't matter in your environment.

Quanto custa: dois componentes de cobrança

Para quem decide orçamento de AppSec aqui, o modelo de preço importa tanto quanto a feature. A cobrança do Continuum tem duas dimensões:

• Taxa de contexto: cobra por linhas de código protegidas por mês, começando em US$ 200 por milhão de linhas e caindo para US$ 100 por milhão acima de 10 bilhões de linhas.
• Taxa de inferência: US$ 10 por "unidade de inferência do Continuum", consumida conforme os achados são processados.

Os exemplos de cálculo divulgados pela AWS mostram como isso se comporta na prática. Uma base de 1 milhão de linhas com 100 vulnerabilidades, a uma unidade cada, fecha em US$ 1.200. Uma base de 100 milhões de linhas com 10 mil vulnerabilidades, a duas unidades cada, chega a US$ 218.200, sendo US$ 18.200 de contexto e US$ 200.000 de inferência, ou aproximadamente US$ 20 por achado validado.

Em resumo: os "milhares de achados por dia" que os dois executivos da AWS descrevem como problema de volume são exatamente o que a taxa por achado cobra. O discurso de marketing e a métrica de faturamento medem o mesmo trabalho a partir de pontas opostas.

O que o sandbox não resolve, segundo quem testou o anúncio

Ao responder o anúncio no LinkedIn, Bernardo Meireles Correa, engenheiro que trabalha com identidade de agentes e non-human identity na Avatier, elogiou o ranqueamento por explorabilidade, mas apontou dois pontos em aberto:

Uma prova em sandbox isolado diz que o código é explorável. Ela não diz que o caminho até ele existe no seu ambiente, e os achados que ela não consegue provar ainda precisam ir para algum lugar, ou silenciosamente viram a pilha dos "seguros".

Bernardo Meireles Correa, engenheiro de identidade de agentes (non-human identity) na AvatierA proof in an isolated sandbox says the code is exploitable. It does not say the path to it exists in your environment, and the findings it cannot prove still need somewhere to go, or they quietly become the safe pile.

O produto responde parcialmente à primeira objeção: o coletor opcional recolhe configuração de rede e de recursos da AWS para julgar a alcançabilidade (reachability), mas isso é uma etapa extra de configuração, não o padrão. A segunda objeção segue sem resposta: a AWS documenta o que acontece com achados que consegue provar, mas nada diz sobre o destino dos que não consegue.

Isso importa pra quem roda pipeline de CI/CD aqui: sem configurar o coletor, o Continuum perde justamente a parte que calcula se o caminho até o exploit existe no ambiente real, e sem essa configuração o valor da validação cai.

Autonomia é a próxima etapa, mas falta critério de aceite

Hoje, toda remediação começa em um modo no qual o Continuum propõe a correção e uma pessoa aprova antes dela ir ao ar, e o console avisa que um patch gerado não significa que o problema está resolvido. A AWS planeja permitir que o Continuum aplique classes de correção sozinho assim que critérios de confiança, como cobertura de testes e histórico de sucesso, forem atingidos.

Jorg Huser, CTO e ex-principal da AWS, questionou Rae sobre o que deveria destravar essa autonomia:

A mudança de aprovar cada merge para aprovar uma classe de correções merece seu próprio teste de aceitação. Do contrário, uma fila de revisão sobrecarregada pode virar o motivo para conceder mais autonomia. Eu gostaria de evidência de que a correção remove a vulnerabilidade e preserva o comportamento esperado da aplicação. O que qualificaria uma classe de correção para merge autônomo, e o que a mandaria de volta para revisão humana?

Jorg Huser, CTO e ex-principal da AWSThe move from approving each merge to approving a class of fixes deserves its own acceptance test. An overloaded review queue can otherwise become the reason to grant more autonomy. I'd want evidence that the fix removes the vulnerability and preserves expected application behavior. What would qualify a fix class for autonomous merging, and what would send it back to human review?

Continuum vs CodeMender: falta a prova de equivalência

O CodeMender, do Google, avança no ponto que a AWS ainda deixa em aberto. Ele também prova explorabilidade executando o exploit e também se recusa a aplicar patches sozinho, mas valida cada correção com um framework de LLM-as-judge que testa equivalência de programa, garantindo que o fix resolve a causa raiz.

sem alterar o comportamento pretendido da aplicação.

descrição do CodeMender, Googlewithout altering the application's intended behavior

É exatamente essa etapa, provar que a correção não muda o comportamento esperado da aplicação, que a própria ressalva do console do Continuum reconhece não fazer.

A confusão de nomes dentro da própria AWS

A sobreposição de produtos que o InfoQ já havia reportado em julho de 2026 continua visível na documentação. Na ocasião, o AWS Serverless Hero Yan Cui resumiu o problema:

Temos as mesmas capacidades, dois nomes de produto, e nenhuma clareza sobre qual você deveria usar.

Yan Cui, AWS Serverless Herowe have the same capabilities, two product names, and no clarity on which one you should use

Isso permanece verdade: o guia de usuário do Continuum cobre vulnerabilidades de código, mas remete quem procura pentest e threat modeling para um guia à parte, o "AWS Security Agent User Guide". Só a capacidade de vulnerabilidades de código chegou à disponibilidade geral; pentest continua precificado separadamente a US$ 50 por hora de tarefa, e threat modeling, anunciado em preview em junho de 2026, ainda não tem preço publicado.

O que muda pra quem constrói aqui

Para squads brasileiros, o pitch central do Continuum é reduzir fadiga de alerta: trocar lista infinita de achados de SAST/DAST por confirmação via exploit real mais PR pronto pra revisão. Isso tem custo e tem configuração: times sem o coletor opcional perdem justamente a parte que calcula alcançabilidade real no ambiente.

O preço por achado, cerca de US$ 20 nos exemplos divulgados, precisa entrar na conta ao lado do câmbio em reais antes de qualquer piloto. E a decisão de liberar correção automática sem revisão humana ainda não tem critério de aceite claro publicado, nem pela AWS, nem, por ora, por quem compete com ela.

Fonte: InfoQ