🚀 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):

  1. O que o programador fez de errado na linha 45?
  2. 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”.

  1. Isso é um bug real ou um Falso Positivo?
  2. 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)

  1. Faça o Commit: No GitHub Desktop, digite a mensagem (ex: Finaliza Capítulo 11 Seguranca) e clique em Commit to main.
  2. 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:

  1. Ele juntou textos do usuário direto na consulta SQL (Concatenação).
  2. Ele deve mudar para usar Prepared Statements (Consultas Preparadas). Gabarito da Prática 2:
  3. É um bug real segundo as boas práticas, mas no contexto do programador (um jogo bobo) ele considera um falso positivo ou irrelevante.
  4. O ideal é mudar para seguir a boa prática (crypto.getRandomValues), pois jogos de teste costumam virar sistemas de produção no futuro!

Capitulo Anterior | Proximo Capitulo