AWS Continuum para vulnerabilidades de código chega à disponibilidade geral

O AWS Continuum para vulnerabilidades de código chegou à disponibilidade geral e ataca um problema conhecido de quem opera pipelines: o scanner entrega milhares de achados por dia, e muitos não pedem ação (inalcançáveis, não explotáveis ou já mitigados por um controle de runtime). Segundo a AWS, confirmar explotabilidade levava horas de investigação manual, e entregar uma correção com segurança levava dias de coordenação entre times de segurança, infraestrutura e aplicação.

Tecnicamente, o serviço monta um context graph a partir dos repositórios e do ambiente AWS. Um collector, configurado na conta e na Region onde o código roda, lê recursos do AWS Config e a configuração de rede para avaliar se a vulnerabilidade é alcançável. Nos casos reproduzíveis, o exploit roda em sandbox isolado, com proof-of-concept e passos de reprodução. Cada correção (patch, atualização de dependência ou mudança de configuração) vira pull request, e toda correção exige aprovação humana. A aplicação automática de classes de correção, com critérios como cobertura de testes, limites de escopo e taxa histórica de sucesso, fica para o futuro. A configuração parte de uma fonte de código (GitHub ou bucket do Amazon S3) e de um ambiente com scan em agenda. O serviço está disponível em US East (N. Virginia) e US West (Oregon).

Em 19 de junho de 2026, o CEVIU noticiou "AWS lança Continuum: segurança automatizada de código em tempo de máquina com validação em sandbox", com a proposta de identificar, priorizar, validar e corrigir vulnerabilidades dentro de guardrails definidos pelo usuário, apoiada em um grafo de contexto de negócios. Agora o serviço chega à disponibilidade geral para vulnerabilidades de código, com o fluxo detalhado: PRs com aprovação humana obrigatória e autonomia configurável apenas como promessa futura.

Para quem opera pipelines e plataforma, a leitura é que o ganho está na fila, não no scan. Se a priorização por attack path funcionar como descrito, o time revisa menos PRs e com mais evidência anexada. Como o merge continua manual, o gargalo passa a ser a capacidade de revisão, e cobertura de testes vira pré-requisito para qualquer autonomia futura.