Aula 15 – Auditoria e Testes de Segurança 🔍

Como saber se todas as defesas que construímos nas aulas anteriores realmente funcionam? Nesta aula vamos aprender a testar, auditar e monitorar a segurança de um sistema antes que um atacante o faça por você.

🕵️ Pentest x Auditoria x Bug Bounty

Abordagem	Quem faz	Objetivo
Teste de Penetração (Pentest)	Time contratado, com escopo e prazo definidos	Simular um ataque real e reportar vulnerabilidades
Auditoria de Segurança	Interno ou terceirizado	Revisar processos, configurações e conformidade (ex: LGPD)
Bug Bounty	Pesquisadores independentes, continuamente	Recompensar quem encontrar e reportar vulnerabilidades

Autorização é obrigatória

Testar a segurança de um sistema sem autorização explícita e por escrito do proprietário é crime, mesmo com boas intenções. Sempre trabalhe dentro de um escopo formalmente autorizado.

🔬 SAST x DAST: Duas Formas de Analisar Código

graph TD
    A["Análise de Segurança de Software"] --> B["SAST - Static Application Security Testing"]
    A --> C["DAST - Dynamic Application Security Testing"]
    B --> D["Analisa o CÓDIGO FONTE, sem executar"]
    C --> E["Analisa a APLICAÇÃO RODANDO, como um atacante externo"]

	SAST	DAST
Quando roda	Durante o desenvolvimento (CI/CD)	Aplicação já em execução
Encontra	Padrões de código inseguro (ex: SQL concatenado)	Vulnerabilidades exploráveis de fora (ex: XSS real)
Exemplo de ferramenta	SonarQube, Bandit (Python)	OWASP ZAP, Burp Suite

📋 Gestão de Dependências (SCA)

Boa parte das vulnerabilidades reais não está no seu código — está nas bibliotecas de terceiros que você usa.

$ # Verificando vulnerabilidades conhecidas em dependencias Python $ pip install pip-audit $ pip-audit $ Found 2 known vulnerabilities in 1 package $ Name Version ID Fix Versions $ requests 2.25.0 GHSA-j8r2-6x86 2.31.0

SCA = Software Composition Analysis

Ferramentas como pip-audit, npm audit e o próprio Dependabot do GitHub automatizam essa verificação, alertando quando uma dependência tem vulnerabilidade conhecida (catalogada em bases como o CVE).

📊 Logging e Monitoramento

Detectar um ataque em andamento (ou já ocorrido) depende de registros bem feitos.

O que registrar em logs de segurança: 1. Tentativas de login (sucesso e falha), com data/hora e IP de origem. 2. Mudanças em permissões e dados sensíveis. 3. Erros de aplicação que possam indicar tentativa de exploração (ex: muitos erros 500 seguidos).

Nunca logue dados sensíveis

Um erro comum: logar a senha digitada em uma tentativa de login falha "para debug". Isso viola a LGPD (Aula 14) e cria um novo ponto de vazamento — nunca registre senhas, tokens ou dados sensíveis em logs.

📝 Exercícios de Fixação

Básico: Qual a diferença entre um pentest e uma auditoria de segurança?
Básico: Por que testar a segurança de um sistema sem autorização é crime, mesmo com boas intenções?
Intermediário: Explique a diferença entre SAST e DAST com um exemplo de vulnerabilidade que cada um encontraria melhor.
Intermediário: Por que dependências desatualizadas são consideradas um risco de segurança, mesmo que seu código próprio esteja correto?
Desafio: Pesquise o que é o "CVE" (Common Vulnerabilities and Exposures) e como consultar vulnerabilidades conhecidas de uma biblioteca específica.

🚀 Mini-Projeto: Checklist de Auditoria

Objetivo: Criar e aplicar um checklist básico de segurança em um projeto real (seu ou de um colega).

Monte um checklist com pelo menos 8 itens, cobrindo temas das aulas anteriores (ex: "senhas com hash+salt?", "HTTPS em produção?", "dependências atualizadas?", "logs não guardam dados sensíveis?").
Aplique o checklist em um projeto real.
Para cada item que falhar, documente o risco e uma sugestão de correção.
Rode pip-audit ou npm audit no projeto e inclua os resultados no relatório.

Ir para Aula 16