Teste de Penetração em Cada Deploy com o AWS Continuum

O problema com as ferramentas tradicionais de segurança no pipeline

A maioria das ferramentas de segurança que se encaixam em um pipeline de Integração Contínua/Entrega Contínua (CI/CD) — como análise estática (SAST), análise de composição de software (SCA) e scanners dinâmicos (DAST) — identificam problemas potenciais com base em padrões e assinaturas conhecidas. Elas mostram onde olhar, mas não confirmam se algo é de fato explorável.

Essa confirmação sempre veio de testes de penetração periódicos, realizados fora do ciclo de entregas — tipicamente uma vez por trimestre. O resultado prático: deploys feitos entre esses engagements chegam à produção sem que ninguém tenha validado se as mudanças introduziram uma brecha real.

É exatamente esse gap que o AWS Continuum para testes de penetração (anteriormente chamado de AWS Security Agent) propõe resolver. O serviço usa agentes de IA para encontrar e confirmar vulnerabilidades exploráveis em aplicações em execução, e pode ser configurado como um gate automático no pipeline de CI/CD.

Como funciona o gate de pentest no pipeline

A ideia central é simples: após cada deploy em ambiente de staging, o pipeline chama o Continuum para executar um teste de penetração automaticamente limitado à mudança recém-implantada. Se o resultado estiver acima de um limiar de severidade configurado, a promoção para produção é bloqueada.

O fluxo completo funciona assim: o pipeline faz o deploy em staging, o gate se autentica na conta AWS via OpenID Connect (OIDC) e aciona o Continuum, que executa o teste no ambiente de staging. O gate aguarda o resultado e decide se a promoção segue ou é bloqueada. Toda a lógica de teste roda no lado do servidor, dentro da conta AWS — nenhum código de pentest é executado no runner do CI/CD.

O padrão descrito pela AWS é compatível com quatro plataformas principais de CI/CD: GitHub Actions, GitLab CI/CD, Bitbucket Pipelines e Azure DevOps Pipelines.

Por que limitar o escopo à mudança importa

O que torna o gate viável para rodar em cada deploy é justamente o escopo reduzido. O Continuum determina o intervalo de commits — o head é o commit sendo avaliado, e o base é o último commit que já passou pelo gate — e testa apenas o que mudou. Isso mantém o teste rápido e econômico o suficiente para ser parte do pipeline, e não de um calendário trimestral.

Cada execução retorna uma de três decisões de escopo:

• In scope (dentro do escopo): a mudança alterou a superfície de ataque — os findings são avaliados contra o limiar de severidade configurado.
• Scoped out (fora do escopo): a mudança estava no escopo, mas nada relevante para segurança foi alterado — o pipeline passa.
• Scope conflict (conflito de escopo): a mudança ficou fora do escopo configurado e não foi testada — você decide se isso bloqueia ou não.

Para entender os detalhes de como o intervalo de commits é calculado e validado, a AWS disponibilizou a documentação Como a integração de pipeline determina o escopo do teste.

Configurando o gate: três passos

Passo 1: Configurar o teste de penetração

O primeiro passo é uma configuração única: verificar o domínio alvo, criar um teste de penetração no Agent Space, habilitar o modo CI/CD e conectar o repositório. Conforme descrito em Antes de começar, é necessário anotar o Agent Space ID (prefixo as-…) e o ID do teste de penetração (prefixo pt-…), pois ambos serão usados na configuração do gate.

Passo 2: Criar a role IAM

A autenticação usa federação via OIDC em vez de chaves de acesso armazenadas. O provedor de CI/CD emite um token de curta duração identificando o pipeline, e o AWS Security Token Service (AWS STS) o troca por credenciais temporárias quando o pipeline assume uma role do Gerenciamento de Identidade e Acesso (IAM) criada pelo time.

Sem chaves de acesso de longa duração armazenadas como variáveis no CI/CD, elimina-se o vetor de vazamento de credenciais mais comum em pipelines. A segurança do gate depende de duas políticas: a trust policy da role IAM (quais pipelines podem assumir a role) e a permissions policy (o que o pipeline pode fazer após assumir a role).

Para os JSONs exatos das políticas, URLs de OIDC por provedor e o formato do sub claim, a AWS recomenda seguir as referências de Escopo da trust policy para seu pipeline e Conceder permissões de menor privilégio.

Um detalhe importante: repositórios GitHub criados ou renomeados a partir de 15 de julho de 2026 emitem um sub claim imutável com IDs numéricos — é necessário confirmar o sub exato que o pipeline emite antes de escrever a política.

Passo 3: Adicionar o gate step ao pipeline

A etapa é conceitualmente a mesma em todos os provedores — apenas a sintaxe varia. A AWS recomenda fixar a integração a uma versão imutável (tag de release, SHA de commit ou versão de componente fixada) para que uma mudança upstream não altere o que roda no pipeline.

Antes de confiar no gate em produção, o recomendado é executá-lo uma vez em modo dry-run. Esse modo verifica autenticação, região e resolução do repositório sem iniciar um teste de penetração de fato. Se a validação falhar, o step falha imediatamente — o que faz com que erros de configuração apareçam cedo. Os valores padrão da integração estão documentados em Padrões da integração.

Exemplo prático: GitHub Actions

O workflow abaixo ilustra a topologia de três jobs que faz o gate funcionar: deploy faz o deploy em staging, security-pentest executa o gate, e deploy-prod promove para produção. Como deploy-prod declara needs: [security-pentest], o GitHub pula a produção sempre que o gate falha.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false
      - run: ./deploy.sh staging

  security-pentest:
    needs: [deploy]
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: write
      actions: read
      deployments: read
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/my-pentest-gate-role
          aws-region: us-west-2
          role-duration-seconds: 7200
      - uses: aws-actions/aws-continuum-run-pentest@v1
        with:
          agent-space-id: as-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
          pentest-id: pt-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
          severity-threshold: HIGH
          on-scope-conflict: block
          timeout-minutes: "45"

  deploy-prod:
    needs: [security-pentest]
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false
      - run: ./deploy.sh production

Dois pontos merecem atenção especial nesse exemplo. Primeiro, a permissão contents: write permite que o gate avance o marcador de baseline que ele mantém como referência no repositório — sem acesso de escrita, cada execução testaria um intervalo mais amplo do que o necessário. Segundo, o role-duration-seconds: 7200 no step de credenciais precisa ser maior que a duração do teste de penetração; o AWS STS rejeita uma requisição que exceda o máximo permitido pela role em vez de reduzi-la automaticamente — portanto, a duração máxima de sessão da role deve ser configurada para pelo menos (timeout + 10) x 60 segundos.

Rollout gradual: do modo relatório ao bloqueio real

Três configurações independentes determinam se o step falha, cada uma cobrindo um cenário diferente: severity-threshold (o que acontece com os findings), on-scope-conflict (o que acontece quando a mudança não foi testada) e fail-on-infrastructure-error (o que acontece quando o job não conseguiu rodar). Relaxar uma não afeta as outras.

A abordagem recomendada é introduzir o gate em modo relatório primeiro — definindo o threshold como NONE para que o teste rode e publique findings sem bloquear o pipeline. Após observar o que ele encontra por um ou dois ciclos de release, o threshold é ajustado para HIGH.

Há uma ressalva crítica nessa estratégia: uma execução que passa — incluindo execuções em modo relatório — avança o baseline. Os commits daquele intervalo são registrados como aprovados e não serão re-testados quando o threshold for ajustado. Se o gate rodar em modo relatório por um mês e depois for configurado para HIGH, ele avaliará apenas os commits após a última execução em modo relatório — não revisará o que já foi aprovado. Para forçar uma reavaliação de um intervalo já aprovado, é possível sobrescrever os SHAs de head e base usando os parâmetros base-commit-sha e head-commit-sha.

Outro padrão que merece atenção: fail-on-infrastructure-error vem configurado como false por padrão (falha aberta). Para pipelines onde a promoção exige aprovação de segurança, a recomendação é definir como true desde o início. Para entender como o baseline avança em cada provedor, a documentação O que avança o baseline e por que isso importa traz a matriz completa.

Atenção especial ao GitLab

No GitLab CI/CD, uma variável de pipeline substitui o valor definido no .gitlab-ci.yml. Isso significa que qualquer pessoa com permissão para rodar um pipeline poderia fornecer uma variável que reduz o threshold, ativa o dry-run ou relaxa o tratamento de erros — e o gate obedece à variável, não ao arquivo de configuração. A recomendação é restringir quem pode sobrescrever variáveis nas configurações de CI/CD do projeto antes de confiar no gate para segurar um release.

Proteção de credenciais no runner

As credenciais temporárias e o token OIDC são sensíveis durante toda a duração do step. Três práticas são essenciais:

• Manter o rastreamento de debug e verbose desativado para steps que lidam com credenciais — modos de shell-trace (como o CI_DEBUG_TRACE do GitLab) ecoam argumentos de comandos no log do job em texto puro.
• Não persistir credenciais de controle de versão no workspace — definir persist-credentials: false no step de checkout para que um token não seja gravado na configuração .git do runner.
• Não expor o token a steps não confiáveis — conceder permissão de token OIDC apenas aos jobs que precisam, e não executar código não confiável (como builds de forks) em um job que pode ler o token.

Expandindo para múltiplas contas AWS

O exemplo usa uma única conta para simplificar. Na prática, os ambientes de staging e produção frequentemente ficam em contas AWS separadas. O padrão se expande de forma limpa: cria-se a role IAM de gate na conta onde o teste de penetração e o Agent Space residem — a conta de segurança. O pipeline assume essa role via OIDC independentemente de qual conta de workload ele está fazendo deploy, mantendo uma única role bem delimitada em vez de cópias ou chaves de longa duração em cada conta.

Para orientações mais amplas sobre o AWS Security Agent — incluindo testes contra ambientes não produtivos, validação de findings gerados por IA e IAM — a AWS disponibilizou o documento Melhores práticas de segurança para o AWS Continuum.

Limpeza após os testes

Quem seguir os tutoriais de cada provedor para experimentar o gate deve concluir a seção de limpeza correspondente: remover o ambiente de staging da aplicação de exemplo, a role IAM e o provedor de identidade OIDC e, se criados especificamente para o walkthrough, o teste de penetração e os Agent Spaces dedicados. Isso evita cobranças contínuas e retira do ar a aplicação de exemplo intencionalmente vulnerável.

Conclusão

Limitar o escopo dos testes de penetração à mudança deployada é o que torna viável usá-los como gate por deploy, em vez de um exercício trimestral. As decisões-chave para quem for implementar são:

• Quão rigoroso: começar em modo relatório (NONE), mas lembrar que o baseline avança — apagar o marcador ao apertar o threshold.
• Como falhar: definir fail-on-infrastructure-error como true para qualquer coisa que exija aprovação de segurança.
• Como limitar a trust: fixar o sub claim o mais estreitamente que a realidade de deploy permitir.
• Onde colocar a role: uma role em uma conta de segurança, assumida pelo pipeline de workloads via OIDC.

Para construir o gate do início ao fim em cada plataforma, a AWS disponibilizou tutoriais específicos:

• Tutorial: Gate em deploy GitHub Actions com teste de penetração com escopo
• Tutorial: Gate em deploy GitLab CI/CD com teste de penetração com escopo
• Tutorial: Gate em deploy Bitbucket Pipelines com teste de penetração com escopo
• Tutorial: Gate em deploy Azure DevOps com teste de penetração com escopo

Para os conceitos e referência completa, consulte Executar testes de penetração a partir do pipeline de CI/CD.

Fonte

Penetration testing every deployment with AWS Continuum (https://aws.amazon.com/blogs/security/penetration-testing-every-deployment-with-aws-continuum/)