🚀 Capítulo 11: Análise Estática de Segurança (SAST) (Tema: Minority Report)
NOTE
Este capítulo utiliza a temática de Minority Report para explicar o SAST. Prever o crime (o bug) antes que ele aconteça é o superpoder da análise estática!
1. 🎯 Objetivo da Aula
Compreender o que é SAST (Static Application Security Testing), entendendo como ferramentas automatizadas podem prever vulnerabilidades no código-fonte antes mesmo dele ser executado.
2. 🏢 O Cenário Prático (Seu Desafio)
No filme Minority Report, a polícia usa os “Precogs” (videntes) para prever assassinatos antes que eles aconteçam. Os policiais chegam ao local e prendem o criminoso antes dele puxar o gatilho.
- O crime ainda não aconteceu na realidade.
- Mas ele já existia no “código” do futuro.
No desenvolvimento de software, o SAST é o nosso Precog. Ele lê o seu código-fonte (as linhas de texto) sem rodar o programa e avisa: “Se você deixar essa linha assim, um hacker vai conseguir invadir o sistema usando SQL Injection!“. Seu desafio é ouvir os alertas dos Precogs e corrigir o código antes do crime acontecer!
3. 🧠 Fundamentos: A Teoria Traduzida
SAST (Static Application Security Testing) é um método de teste que analisa o código-fonte (ou o código compilado) para encontrar falhas de segurança.
🔍 Como ele funciona?
O SAST não executa o programa. Ele funciona como um corretor ortográfico super avançado. Ele conhece milhares de padrões de código inseguro (regras) e varre o seu arquivo procurando por eles.
⚖️ Prós e Contras:
- Prós:
- Shift Left puro: Encontra o erro enquanto o programador ainda está digitando.
- Cobertura de 100%: Ele lê todas as linhas de todos os arquivos.
- Não precisa de um ambiente de testes rodando.
- Contras:
- Falsos Positivos: Às vezes ele acha que um código é perigoso, mas o programador sabe que naquele contexto está seguro.
- Não pega falhas que só acontecem quando o sistema está rodando de verdade (como erros de configuração do servidor).
4. 📖 Exemplo Guiado: O Alerta do Precog
Imagine que você escreveu este código em JavaScript:
let senha = "123456_super_secreta"; // Hardcoded secret!A ferramenta de SAST vai ler essa linha e gerar um alerta imediatamente:
🚨 ALERTA SAST: “Hardcoded password detected on line 1. Never store secrets in source code.” (Senha fixada no código detectada. Nunca guarde segredos no código-fonte).
O robô previu que se essa senha for para o GitHub, qualquer um poderá ver!
5. 🛠️ Prática Obrigatória 1: Interpretando o Relatório
Você rodou uma ferramenta de SAST no seu projeto e ela gerou o seguinte relatório:
- Arquivo:
login.js - Linha: 45
- Severidade: Alta
- Descrição: “Potential SQL Injection due to string concatenation in database query.”
Com base no que aprendemos no Capítulo 06 (Inception):
- O que o programador fez de errado na linha 45?
- Como ele deve corrigir isso para o SAST parar de reclamar?
6. 🛠️ Prática Obrigatória 2: O Falso Positivo
A ferramenta de SAST acusou que o uso da função Math.random() para gerar a senha do usuário é inseguro (porque não é um gerador criptográfico forte). O programador diz: “Mas é só um jogo de teste, não precisa de segurança máxima”.
- Isso é um bug real ou um Falso Positivo?
- O programador deve ignorar o alerta ou mudar a função para seguir a boa prática mesmo sendo um jogo de teste?
7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)
- Faça o Commit: No GitHub Desktop, digite a mensagem (ex:
Finaliza Capítulo 11 Seguranca) e clique em Commit to main. - Envie para a Nuvem (Push): Clique em Push origin.
8. 📂 Estrutura de Pastas
mod_12_desenvolvimento_seguro/
├── capitulos/
│ ├── capitulo_11_sast.md
│ └── codigos/
│ └── cap11/
│ └── sast_report.json💡 Checkpoint de Lógica
Ferramentas de SAST famosas (como SonarQube, ESLint com plugins de segurança ou o próprio GitHub Code Scanning) são essenciais na esteira de CI/CD para bloquear códigos inseguros!
10. 🔥 Desafio de Fixação
Pesquise sobre ferramentas de SAST gratuitas para a linguagem de programação que você mais usa.
🔑 Gabarito de Código/Fórmulas
Gabarito da Prática 1:
- Ele juntou textos do usuário direto na consulta SQL (Concatenação).
- Ele deve mudar para usar Prepared Statements (Consultas Preparadas). Gabarito da Prática 2:
- É um bug real segundo as boas práticas, mas no contexto do programador (um jogo bobo) ele considera um falso positivo ou irrelevante.
- O ideal é mudar para seguir a boa prática (
crypto.getRandomValues), pois jogos de teste costumam virar sistemas de produção no futuro!