O que é análise de código (SAST)?
Quando falamos em SAST (Static Application Security Testing), estamos falando de análise de código sem execução. Ou seja, ele lê seu código e aponta potenciais falhas como:
- Uso de funções ou bibliotecas com CVEs conhecidas.
- Falta de validação de entrada (o clássico caminho para injeção SQL/XSS).
- Exposição de dados sensíveis como senhas hardcoded.
- Más práticas de autenticação/autorização.
- Má configuração de infraestrutura como código (IAM Policies mal feitas, buckets S3 públicos, etc.).
O que o Amazon Inspector faz de diferente?
Antes ele já era conhecido por escanear EC2, containers, Lambda, mas agora ele entra no começo do ciclo de desenvolvimento.
Principais pontos:
- Conecta direto com GitHub, CodeCommit e repositórios Git.
- Escaneia código durante o pull request.
- Integração nativa com Security Hub e IAM.
- Não precisa configurar infraestrutura adicional de scanners.
- Trabalha com linguagens como Python, JavaScript, Java, e outras.
🛡️ Comparativo com outras ferramentas de SAST
| Ferramenta | Tipo | Linguagens | Integração nativa AWS | Governança IAM |
|---|---|---|---|---|
| Amazon Inspector (code) | SAST | Node, Python, Java (foco inicial) | ✅ Sim | ✅ IAM nativo |
| CodeQL (GitHub) | SAST/SDLC | Alta cobertura | ❌ | 🔶 Parcial |
| SonarQube | SAST/Qualidade | Ampla | ❌ | 🔶 Parcial |
| Checkov (IaC) | SAST para IaC | Terraform, CloudFormation | ✅ via CLI | 🔶 Parcial |
O grande diferencial do Inspector é justamente a integração nativa com o IAM, CloudTrail, Security Hub e outras peças do ecossistema AWS.
Exemplos práticos de uso
Exemplo 1 - Time desenvolvendo microserviço em NodeJS
Um time cria um novo microserviço exposto em API Gateway. O pipeline deles é:
- Código em GitHub.
- Pipeline automatizado via CodePipeline.
O Amazon Inspector Code Security é integrado no pull request:
- Toda PR roda uma análise SAST automática.
- Caso detecte alguma função insegura (
eval(),child_process.exec()), ele marca o PR como falha. - O resultado do scan vai para o Security Hub onde o time de segurança monitora.
Exemplo 2 - Time de dados usando scripts Python
Um time de dados armazena dados sensíveis e processa muitos arquivos.
- O código fica em CodeCommit.
- Pipeline usa CodeBuild.
O Inspector Code Security identifica quando um script puxa secret diretamente via string literal e também quando há dependências desatualizadas com CVEs críticas.
Assim, eles conseguem corrigir antes de rodar o pipeline completo.
Exemplo 3 - Equipe multi-conta usando AWS Organizations
Empresa com múltiplas contas (dev, stage, prod), habilita o Amazon Inspector Code Security via Organizations.
- Integra todos repositórios CodeCommit.
- Regras de bloqueio de PR configuradas apenas em produção.
- Time de segurança visualiza tudo centralizado no Security Hub.
Como isso encaixa no fluxo do time?
- No GitHub ou CodeCommit: feedback imediato no PR.
- No CI/CD: bloqueio automático quando falhas são críticas.
- No pós-produção: findings visíveis via Security Hub.
O time de Dev vê o problema onde faz sentido: direto na análise de código. O time de Segurança tem visibilidade sem depender de revisões manuais.
Dicas rápidas de uso eficiente
- Use regras diferentes por branch. Exemplo: branch main bloqueia PRs com falhas críticas, branch de feature apenas gera alerta.
- Combine com GuardDuty para runtime, pegando comportamentos anômalos depois do deploy.
- Mantenha o CodeBuild apenas com lint e testes unitários, usando o Inspector Code Security só no PR, para deixar builds mais rápidos.
- Sempre configure IAM com permissões mínimas e use Service Control Policies para ambientes multi-conta.