Guia Completo de Relatório de Pentest: Estrutura, CVSS, Evidências e Recomendações Já leu

Introdução ao Relatório de Pentest

Um relatório de teste de penetração (pentest) é muito mais que um documento técnico — é a ponte entre a realidade técnica das vulnerabilidades encontradas e as decisões de negócio que o cliente precisará tomar. Durante minha carreira, vi muitos relatórios tecnicamente perfeitos serem ignorados simplesmente porque não comunicavam o risco de forma clara e acionável. A estrutura de um relatório bem feito não é apenas sobre estar bonito; é sobre garantir que cada achado seja compreendido, priorizado e remediado corretamente.

O objetivo deste artigo é ensinar você a estruturar um relatório de pentest profissional, utilizando a metodologia CVSS (Common Vulnerability Scoring System) para classificação de risco, apresentando evidências sólidas e fornecendo recomendações práticas. Vamos passar pelos componentes que distinguem um relatório amador de um relatório que abre portas em organizações e garante contratações futuras.

Estrutura Base de um Relatório de Pentest

Anatomia do Documento

Um relatório de pentest deve ser dividido em seções que façam sentido para públicos diferentes. O executivo quer números e contexto de risco; o gerente de TI quer detalhes técnicos e passos para remediar; o desenvolvedor quer compreender exatamente o que aconteceu. Um bom relatório atende a todos simultaneamente.

A estrutura mínima que você deve seguir é: Sumário Executivo, Escopo e Metodologia, Descobertas Críticas, Resultados Detalhados, Recomendações Gerais, e Apêndices Técnicos. Cada seção tem um propósito específico e deve ser escrita com objetivos diferentes em mente. O sumário executivo, por exemplo, nunca deve exceder 2 páginas e deve responder: qual era o risco? O que foi encontrado? Qual é a próxima ação?

# Relatório de Teste de Penetração
**Cliente:** Acme Corporation  
**Data do Teste:** 2024-01-15 a 2024-01-19  
**Período de Relatório:** 2024-01-25  
**Testador Responsável:** João Silva (OSCP #12345)  

## Sumário Executivo
Durante o período de 5 dias, foram identificadas **3 vulnerabilidades críticas**, 
**7 vulnerabilidades altas** e **12 vulnerabilidades médias** no escopo definido. 
O risco geral é **CRÍTICO** e requer atenção imediata nas próximas 30 dias.

**Achados Críticos:**
- SQL Injection em painel administrativo (CVSS 9.8)
- Autenticação bypass via JWT malformado (CVSS 9.1)
- Exposição de credenciais em arquivo .env (CVSS 9.3)

**Prazo Recomendado para Remediação:** Imediato (críticas), 30 dias (altas), 90 dias (médias)

---

Escopo e Metodologia

Esta seção define exatamente o que foi testado e como foi testado. Não deixe espaço para interpretações. Inclua: endereços IP ou domínios específicos, aplicações web testadas, servidores internos ou externos, técnicas utilizadas (e quais NÃO foram utilizadas por restrições do cliente), datas exatas, e nomes das pessoas que realizaram os testes.

Detalhe a metodologia que você seguiu — OWASP Testing Guide, NIST SP 800-115, ou sua própria abordagem estruturada. Liste as ferramentas utilizadas de forma resumida (Burp Suite, Nessus, Metasploit, etc.) e esclareça que alguns testes podem ter impacto no ambiente de produção. Se você não testou algo específico (como testes de carga ou testes de negação de serviço), mencione explicitamente para evitar expectativas não cumpridas.

Sistema CVSS: Classificação Objetiva de Risco

O que é CVSS e por que usar?

CVSS (Common Vulnerability Scoring System) é um padrão da indústria mantido pelo FIRST (Forum of Incident Response and Security Teams). Ele permite classificar vulnerabilidades de forma objetiva e consistente, removendo a subjetividade. A versão atual é CVSS v3.1, e ela fornece um score de 0 a 10, onde 10 é a vulnerabilidade mais grave possível.

Você precisa entender que CVSS NÃO é sobre o impacto no seu cliente específico — é sobre o potencial técnico de dano. Se uma vulnerabilidade CVSS 9.0 existe em um servidor com dados não sensíveis, ela ainda é CVSS 9.0. O contexto (risco do negócio) vem depois e é responsabilidade da sua análise descritiva, não do score numérico.

Calculando CVSS v3.1

O CVSS v3.1 é composto de três grupos de métricas: Base (características da vulnerabilidade em si), Temporal (quanto tempo a exploração existe, se há patches disponíveis) e Environmental (como afeta especificamente aquele cliente). Você DEVE aprender a usar a calculadora oficial do FIRST, mas compreender a lógica também é crítico.

A métrica Base possui oito fatores: Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S), Confidentiality (C), Integrity (I) e Availability (A). Cada um tem valores que se combinam em uma fórmula matemática gerando um score final. Não tente decorar a fórmula — use a calculadora — mas entenda cada métrica.

# Exemplo: Script em Python para validar CVSS vectors
# Utilizando a biblioteca cvss (pip install cvss)

from cvss import CVSS3

# Exemplo 1: SQL Injection em painel administrativo
# AV:N (qualquer um pela rede)
# AC:L (pouca complexidade de ataque)
# PR:N (sem privilégios)
# UI:N (sem interação do usuário)
# S:U (scope não alterado)
# C:H (confidencialidade comprometida — pode ler dados)
# I:H (integridade comprometida — pode modificar dados)
# A:H (disponibilidade comprometida — pode derrubar o serviço)

sql_injection = CVSS3("CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H")
print(f"SQL Injection Score: {sql_injection.scores()}")
# Saída esperada: (9.8, 9.8) → Score 9.8 = CRÍTICO

# Exemplo 2: Validação fraca de JWT (sem assinatura verificada)
# Menos grave que SQL Injection porque requer privilégios administrativos
jwt_bypass = CVSS3("CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L")
print(f"JWT Bypass Score: {jwt_bypass.scores()}")
# Saída esperada: (8.7, 8.7) → Score 8.7 = ALTO

# Exemplo 3: Exposição de informações de versão do servidor
# Muito menos grave — informação de reconhecimento apenas
version_disclosure = CVSS3("CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N")
print(f"Version Disclosure Score: {version_disclosure.scores()}")
# Saída esperada: (5.3, 5.3) → Score 5.3 = MÉDIO

# Interpretação de scores
def interpret_cvss_score(score):
    if score >= 9.0:
        return "CRÍTICO - Remediar imediatamente"
    elif score >= 7.0:
        return "ALTO - Remediar em 30 dias"
    elif score >= 4.0:
        return "MÉDIO - Remediar em 90 dias"
    elif score >= 0.1:
        return "BAIXO - Considerar remediação"
    else:
        return "NENHUM - Não requer ação"

print(f"\nInterpretação: {interpret_cvss_score(9.8)}")
print(f"Interpretação: {interpret_cvss_score(8.7)}")
print(f"Interpretação: {interpret_cvss_score(5.3)}")

Este script demonstra como três vulnerabilidades reais recebem scores diferentes. Note que a SQL Injection, sendo mais crítica, recebe 9.8 (mais grave que o bypass de JWT que recebe 8.7). A exposição de versão, apenas informativa, recebe 5.3. Este é o poder do CVSS: objetividade e comparabilidade.

Tabela de Classificação de Severidade

Apresentação de Evidências: Do Técnico ao Convincente

Por que Evidências Importam

Uma vulnerabilidade sem evidência é apenas uma acusação. Você pode dizer "o servidor é vulnerável a SQL Injection", mas se não demonstrar como explorou isso, o cliente pode questionar sua conclusão. Evidências sólidas não apenas comprovam a vulnerabilidade — elas educam o cliente sobre o risco real e não teórico.

A melhor evidência é uma screenshot ou um vídeo curto mostrando o ataque acontecendo. Complementado com o payload exato utilizado, o resultado obtido, e a análise do que isso significa. Nunca use evidências que possam expor dados sensíveis reais (senhas, cartões de crédito, números de identificação). Se a vulnerabilidade permite roubar dados, demonstre que você PODE roubar dados, não que você ROUBOU dados reais.

Estruturando Evidências em Relatórios

Para cada vulnerabilidade, você deve incluir: Título Descritivo, CVSS Score, Descrição Técnica, Como Reproduzir (Passo a Passo), Screenshots/Vídeo, Payload Utilizado, Por que é um Risco, Prova do Conceito (PoC).

Aqui está um exemplo real de como estruturar uma vulnerabilidade:

### Vulnerabilidade #1: SQL Injection no Campo de Login

**Severidade:** CRÍTICO (CVSS 9.8)  
**CWE:** CWE-89 (SQL Injection)  
**OWASP Top 10:** A03:2021 – Injection  

**Descrição:**
O formulário de login não sanitiza a entrada do usuário antes de utilizá-la 
em uma consulta SQL. Um atacante pode injetar código SQL para bypassar 
a autenticação ou extrair dados do banco de dados.

**Como Reproduzir:**
1. Navegue até https://alvo.com/login
2. No campo de e-mail, insira: `admin' OR '1'='1' --`
3. No campo de senha, insira: qualquer valor
4. Clique em "Login"
5. Resultado: Você está autenticado como administrador

**Payload Utilizado:**
```sql
admin' OR '1'='1' --

A sequência ' fecha a string do e-mail, OR '1'='1' torna a condição
sempre verdadeira, e -- comenta o resto da query SQL.

Screenshot da Exploração:
[Aqui seria incluída uma imagem mostrando a tela de login com o payload
e a mensagem de sucesso]

Código Vulnerável Identificado:
No arquivo /app/auth.php linha 42:

$email = $_POST['email'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE email = '$email' AND password = '$password'";
$result = mysqli_query($conn, $query);

Por que é um Risco:
- Um atacante pode fazer login como qualquer usuário sem conhecer a senha
- Dados sensíveis podem ser extraídos via UNION-based SQL Injection
- A integridade dos dados pode ser comprometida com UPDATE/DELETE
- Conformidade (LGPD, PCI-DSS) pode ser violada

Recomendação:
Utilize Prepared Statements (queries parametrizadas) para toda a entrada
do usuário. Exemplo seguro:

$email = $_POST['email'];
$password = $_POST['password'];

$stmt = $conn->prepare("SELECT * FROM users WHERE email = ? AND password = ?");
$stmt->bind_param("ss", $email, $password);
$stmt->execute();
$result = $stmt->get_result();

Veja como este exemplo não apenas relata a vulnerabilidade — ele fornece o contexto para que o desenvolvedor a corrija corretamente. Isso é excelência em relatórios.

## Recomendações: Do Achado à Solução

### Diferença Entre Recomendação Técnica e Remediação

Uma recomendação vaga ("Melhorar a segurança do banco de dados") não ajuda ninguém. Uma remediação clara e testada ("Usar bcrypt com salt para armazenar senhas, mínimo 12 rounds") é acionável. Durante meus anos praticando pentest, aprendi que quanto mais específica a recomendação, maior a chance dela ser implementada corretamente na primeira tentativa.

Toda recomendação deve incluir: **O que fazer**, **Por que fazer**, **Como fazer**, **Tempo estimado**, e **Como validar que foi feito corretamente**. Se você não conseguir responder essas cinco questões sobre uma recomendação, ela não está pronta para um relatório profissional.

### Exemplos de Boas Recomendações

```markdown
## Recomendações por Vulnerabilidade

### Para SQL Injection (Crítico)

**Recomendação:**
Implementar Prepared Statements em 100% das queries que utilizam entrada 
do usuário.

**Por que:**
SQL Injection é uma das técnicas mais antigas e efetivas de ataque. 
Prepared Statements separam dados de código SQL, impedindo que dados 
possam ser interpretados como comando.

**Como Implementar:**
1. Faça um inventário de todas as queries SQL do sistema
2. Priorize as que recebem entrada do usuário
3. Converta cada uma para Prepared Statement
4. Teste com payloads de SQL Injection conhecidos
5. Revise com um segundo desenvolvedor

**Exemplo (PHP com mysqli):**
```php
// ❌ INSEGURO
$email = $_POST['email'];
$result = mysqli_query($conn, "SELECT * FROM users WHERE email = '$email'");

// ✅ SEGURO
$email = $_POST['email'];
$stmt = $conn->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $email);
$stmt->execute();
$result = $stmt->get_result();

Tempo Estimado:
- Análise: 8 horas
- Implementação: 40 horas
- Testes: 16 horas
- Total: 64 horas

Como Validar:
1. Execute scanner SAST (SonarQube, Checkmarx) configurado para SQL Injection
2. Realize teste manual com Burp Suite fuzzing os parâmetros
3. Execute suite de testes automatizados que incluam payloads SQL Injection
4. Realize um novo pentest focado em SQL Injection em 2 semanas

Para Exposição de Credenciais (Crítico)

Recomendação:
Remover arquivo .env do repositório Git e implementar gestão de
secrets com segurança.

Por que:
Se o arquivo .env foi commitado, mesmo que deletado depois, ele permanece
no histórico do Git e pode ser recuperado. Credenciais em repositórios públicos
são encontradas automaticamente por bots em minutos.

Como Implementar:
1. Imediatamente: Revogar todas as credenciais expostas
2. Configurar .gitignore para nunca commitar arquivos .env
3. Implementar gestão de secrets (AWS Secrets Manager, HashiCorp Vault, ou Azure Key Vault)
4. Todos os deployments devem ler secrets de um sistema centralizado, não de arquivos
5. Adicionar hook pre-commit para impedir commits com senhas

Implementação com AWS Secrets Manager (Python):

import boto3
import json

# Configuração
client = boto3.client('secretsmanager', region_name='us-east-1')

# Armazenar secret
def store_secret(secret_name, secret_value):
    try:
        response = client.create_secret(
            Name=secret_name,
            SecretString=json.dumps(secret_value)
        )
        print(f"Secret armazenado: {response['ARN']}")
        return response
    except client.exceptions.ResourceExistsException:
        # Secret já existe, fazer update
        response = client.update_secret(
            SecretId=secret_name,
            SecretString=json.dumps(secret_value)
        )
        print(f"Secret atualizado: {response['ARN']}")
        return response

# Recuperar secret
def get_secret(secret_name):
    try:
        response = client.get_secret_value(SecretId=secret_name)
        if 'SecretString' in response:
            return json.loads(response['SecretString'])
        else:
            return response['SecretBinary']
    except Exception as e:
        print(f"Erro ao recuperar secret: {e}")
        return None

# Uso na aplicação
if __name__ == "__main__":
    # Armazenar credenciais
    db_credentials = {
        "host": "db.example.com",
        "user": "app_user",
        "password": "senha_super_secreta_123"
    }
    store_secret("prod/database", db_credentials)

    # Recuperar credenciais em tempo de execução
    creds = get_secret("prod/database")
    print(f"Conectando ao banco: {creds['host']}")

Tempo Estimado:
- Setup do sistema de secrets: 16 horas
- Integração na aplicação: 24 horas
- Testes: 8 horas
- Total: 48 horas

Como Validar:
1. Verificar que nenhum arquivo .env existe no repositório Git
2. Fazer um git log --full-history -- .env e confirmar que arquivo não é recuperável
3. Confirmar que a aplicação inicia corretamente lendo de secrets
4. Testar fallback/erro gracioso se a aplicação não conseguir acesso aos secrets

### Recomendações Gerais por Categoria

Além das recomendações específicas por vulnerabilidade, inclua uma seção de recomendações estratégicas que o cliente possa implementar ao longo do tempo:

```markdown
## Recomendações Gerais de Segurança

### 1. Implementar Programa de SAST (Static Application Security Testing)
**Impacto:** Reduz vulnerabilidades de código em até 60%  
**Ferramentas Recomendadas:** SonarQube (gratuito), Checkmarx, Veracode  
**Timeline:** Implementação em 2-4 semanas, análise contínua dali em diante

### 2. Treinamento de Segurança para Desenvolvedores
**Impacto:** Previne classes inteiras de vulnerabilidades  
**Recomendado:** OWASP Top 10, Secure Coding em sua linguagem principal  
**Timeline:** 16-24 horas de treinamento inicial, refresh anual

### 3. Testes de Penetração Regulares
**Impacto:** Identifica vulnerabilidades antes do atacante  
**Frequência:** Mínimo anual, idealmente semestral para aplicações críticas  
**Escopo:** Aumentar gradualmente (web, API, infraestrutura, testes sociais)

### 4. Patch Management Process
**Impacto:** Fecha brechas conhecidas e exploradas  
**Timeline:** Patches críticos em 7 dias, patches altos em 30 dias  
**Validação:** Testar patches em ambiente de staging antes de produção

---

Conclusão

Ao estruturar um relatório de pentest, lembre-se que você está comunicando risco para pessoas diferentes com contextos diferentes. O executivo quer saber se deveria se preocupar; o desenvolvedor quer saber como corrigir; o gerente de TI quer um plano de ação. Um relatório profissional satisfaz todos simultaneamente, com clareza e precisão.

Os três pontos críticos que você deve levar consigo são: Primeiro, CVSS não é subjetivo — aprenda a calculadora e use-a corretamente. Um score bem atribuído é uma arma poderosa para priorização de remediação. Segundo, evidências substituem teorias — uma screenshot de uma exploração bem-sucedida comunica risco de forma que nenhuma descrição técnica consegue. Terceiro, recomendações vagas não se tornam ações — seja específico até o ponto em que o cliente possa validar que a correção foi implementada.

Relatórios excelentes abrem portas profissionais. Clientes que recebem relatórios claros, bem estruturados e com recomendações acionáveis não apenas confiam em você — eles o contratam novamente e o indicam para outros.

Referências

• FIRST CVSS Calculator & Documentation: https://www.first.org/cvss/v3.1/
• OWASP Testing Guide (OTG): https://owasp.org/www-project-web-security-testing-guide/
• NIST Special Publication 800-115: https://csrc.nist.gov/publications/detail/sp/800-115/final
• CWE/SANS Top 25: https://cwe.mitre.org/top25/
• OWASP Top 10 2021: https://owasp.org/Top10/