Neste post, vamos abordar:

  • 📜 Policies-as-Code com CloudFormation Guard e Open Policy Agent
  • 🔍 SAST com Amazon Inspector Code e ferramentas externas
  • 👀 Observabilidade com CloudWatch, X-Ray e integração com Security Hub
  • 🛠️ Exemplos de fluxo prático para aplicar esses conceitos

1. Policies-as-Code: segurança como código

Definir políticas de segurança como código é um pilar do DevSecOps moderno. Isso garante que:

  • Todo recurso criado esteja conforme os padrões definidos
  • A validação ocorra antes do deploy
  • Possamos versionar e auditar as regras aplicadas

Ferramentas comuns:

  • AWS Config + Config Rules – Audita automaticamente o estado da infraestrutura.
  • CloudFormation Guard – Valida templates CloudFormation antes de aplicar.
  • OPA (Open Policy Agent) – Permite aplicar políticas a múltiplas fontes (Terraform, Kubernetes, etc.).
  • Terraform Sentinel – Para quem usa Terraform Enterprise.

Exemplo prático: validando que buckets S3 devem estar com blockPublicAccess habilitado com Cfn-Guard

[rule.s3_block_public_access]
    let bucket = Resources.*[ Type == "AWS::S3::Bucket" ]
    bucket.Properties.PublicAccessBlockConfiguration.BlockPublicAcls == true
    bucket.Properties.PublicAccessBlockConfiguration.BlockPublicPolicy == true

2. SAST: detecção de vulnerabilidades no código-fonte

O que é SAST?

SAST (Static Application Security Testing) analisa o código sem executar a aplicação, em busca de padrões inseguros, credenciais hardcoded, uso de libs vulneráveis e outras falhas.

Ferramentas recomendadas:

  • Amazon Inspector Code – Nativo da AWS, escaneia código direto no PR.
  • Semgrep – Open source, rápido e personalizável.
  • SonarQube – Análise de qualidade e segurança de código.
  • Horusec – Projetado para ambientes CI/CD, open source brasileiro.

Exemplo: integração do Amazon Inspector no CodePipeline

Build:
  Actions:
    - Name: CodeScan
      ActionTypeId:
        Category: Build
        Provider: CodeBuild
      Configuration:
        ProjectName: InspectorCodeScan

3. Observabilidade: vendo além do erro

Você precisa mais do que logs. Precisa entender quem acessou o quê, quando e por que.

Ferramentas-chave:

  • AWS CloudWatch – Logs, métricas e alarmes.
  • AWS X-Ray – Rastreia chamadas entre serviços. (Aqui pode ser NewRelic, DataDog, ou qqr serviço que faça o rastrerio de chamadas)
  • Security Hub – Centraliza achados de segurança de serviços como GuardDuty, Inspector, IAM Access Analyzer etc.
  • CloudTrail – Registro detalhado de chamadas à API da AWS.

Exemplo prático: correlacionando eventos

  1. Lambda falha em acessar um bucket S3
  2. CloudWatch detecta erro e envia log
  3. X-Ray mostra latência anormal
  4. CloudTrail indica falha de permissão no IAM
  5. Security Hub aponta política mal configurada

Resultado: você entende o contexto completo e age rápido.

4. Fluxo DevSecOps na prática

Git Push →
| CI → (SAST, linters)
| CD → (validação IaC com OPA/Cfn-Guard)
| Deploy → (Lambda, ECS, etc)
| Pós-deploy →
   - Monitoramento com CloudWatch
   - Tracing com X-Ray
   - Alertas no Security Hub

Conclusão

DevSecOps na AWS é possível com ferramentas nativas e open source. Com pequenas mudanças no seu pipeline, dá pra:

  • Reduzir exposição de vulnerabilidades
  • Automatizar validações
  • Ter visibilidade do que realmente está acontecendo

Comece pequeno, valide uma ferramenta por vez e vá acoplando segurança ao seu pipeline — sem travar a entrega de valor.

Recursos Adicionais