📝 Relatório de Contribuição – Sprint 5

Disciplina: Gestão de Configuração e Evolução de Software

Equipe: OWASP (Times Blue e Red)

Período da Sprint: 19/11/2025 - 02/12/2025

1. Objetivos da Sprint

Blue Team

Consolidação da Estratégia de Defesa e Entrega Final (DevSecOps + Hardening)

Implementação Definitiva do Pipeline: Integrar o arsenal de ferramentas selecionado (Gitleaks, Semgrep, Pip-audit, Trivy) no ambiente oficial de CI/CD, garantindo a execução automatizada dos testes de segurança.
Documentação Técnica das Ferramentas: Criar documentação detalhada que explique como cada ferramenta mitiga riscos específicos da modelagem de ameaças, sua configuração na pipeline e critérios de severidade.
Endurecimento (Hardening): Realizar a revisão crítica das configurações da aplicação (Django) e da infraestrutura (Docker), aplicando correções para reduzir a superfície de ataque e adequar o projeto às boas práticas de segurança.
Análise e Governança: Consolidar todos os artefatos de segurança gerados ao longo do semestre (Modelagem de Ameaças, Relatórios de Vulnerabilidades e Proposta de WAF) em uma entrega única e estruturada via Pull Request.

Red Team

Produção de relatório no formato MITRE ATT&CK sobre XSS
Criação de guia de contribuição segura para Jinja2
Hardening de HTTP Security Headers (CSP, HSTS, X-Content-Type-Options) e consolidação de scripts reutilizáveis de PoC para o Red Team

2. Entregas Coletivas

Entrega	Status	Link/Referência	Observações
Relatório MITRE ATT&CK & Guia de Contribuição de Segurança para Jinja2	Concluído	Relatório & Guia de Contribuição	Red Team
Modelagem de Ameaças (DFD + STRIDE)	Concluído	issue	Blue Team
Documentação Técnica das Ferramentas de Segurança	Concluído	issue	Blue Team
Seleção e Definição do Arsenal de Segurança	Concluído	issue	Blue Team
Implementação do Pipeline DevSecOps (CI/CD)	Concluído	`[Link para Issue/.gitlab-ci.yml]`	Blue Team
Hardening de Infraestrutura, Governança de Pipeline e Proposta de WAF	Concluído	issue	Blue Team
Pull Request Master (Integração Total)	Concluído	PR	Blue Team
Hardening de HTTP Security Headers + Biblioteca de Scripts de PoC	Concluído	Issue #1512, MR #398, poc-scripts.md, Guia de Contribuição	Redução de risco (CVSS) e automação de testes de segurança
Documentação dos estudos realizados	Concluído	issue	Blue Team

3. Contribuições Individuais

Integrante	Contribuições	Links (PRs, Issues, Docs)	Observações
Mateus Vieira	Relatório MITRE ATT&CK da vulnerabilidade XSS	Relatório
Mateus Vieira	Guia de Contribuição de Segurança para Jinja2	MR #395
Ana Carolina Fialho	Documentação Técnica das Ferramentas de Segurança da Pipeline Blue Team	Issue #1506	Documentação detalhada de Gitleaks, Semgrep, pip-audit e Trivy
Miguel Arthur	Mapeamento de Arquitetura e Modelagem de Ameaças (DFD + STRIDE)	ISSUE #1508
Henrique Camelo Quenino	Hardening de HTTP Security Headers (CSP, HSTS, X-Content-Type-Options) e criação de biblioteca de scripts de PoC (XSS, SQLi, rate limiting, auditoria de headers)	Issue #1512, MR #398, poc-scripts.md, Guia de Contribuição	Foco em mitigação prática e automatização para o Red Team
Sebastián Héctor Zuzunaga Rosado	Documentação de estudos realizados para implementação da Pipeline	Issue #1509, Estudios_gerais.md, Estudos_seguranca

4. Maiores Avanços

Blue Team

1. Maturidade em DevSecOps (Do Zero ao Pipeline Ativo) O maior avanço desta sprint final foi transformar conceitos teóricos em uma esteira de defesa funcional. Saímos de um projeto sem verificações de segurança para um pipeline robusto que audita automaticamente: * Segredos (Gitleaks); * Código/SAST (Semgrep); * Dependências (Pip-audit); * Infraestrutura/IaC (Trivy).

2. Documentação Técnica de Ferramentas de Segurança Criamos uma documentação abrangente que conecta cada ferramenta implementada aos riscos específicos da modelagem de ameaças, incluindo: * Gitleaks → Mitigação de "Vazamento de Credenciais/Segredos" (risco Crítico) * Semgrep → Detecção de "Injeção de Código" como SQL Injection e XSS (risco Crítico) * pip-audit → Prevenção de exploração de vulnerabilidades em bibliotecas de terceiros * Trivy → Análise multifacetada (filesystem, container, configurações) para prevenir "Elevation of Privilege"

3. Hardening e Cultura de Prevenção Além de detectar falhas, a equipe avançou para a camada de prevenção (hardening). A revisão das configurações do Django e a refatoração do Dockerfile para rodar sem privilégios de root demonstraram uma compreensão profunda de como mitigar riscos na arquitetura, indo além do uso superficial de ferramentas.

4. Integração Total via "Master PR" Conseguimos superar a fragmentação das tarefas individuais. A criação de um Pull Request unificado consolidou a modelagem de ameaças, a implementação técnica, os relatórios de análise e a documentação das ferramentas, entregando uma solução de segurança completa e documentada para o projeto EJ-Platform.

Red Team

Relatório MITRE ATT&CK

Um relatório MITRE ATT&CK é um documento ou registro que organiza e descreve informações sobre técnicas, táticas e procedimentos (TTPs) utilizados por agentes maliciosos (hackers, malware, grupos de APTs) para atacar sistemas de informação. Ele se baseia na matriz MITRE ATT&CK, que é um framework amplamente utilizado em cibersegurança.

O relatório sobre a exploração da falha de XSS na ej-application pode ser encontrado aqui: Relatório

Guia de Contribuição Jinja2

O Guia de Contribuição foi criado para:

Padronizar implementações seguras com Jinja2 no projeto.
Alertar sobre o uso incorreto de filtros como |safe.
Reforçar a necessidade de validação e sanitização no backend.
Oferecer exemplos seguros e inseguros para comparação.
Estabelecer diretrizes mínimas para lidar com HTML dinâmico.

Guia de Contribuição

Hardening de HTTP Headers e Scripts de PoC

Foi implementado um conjunto de três headers de segurança (CSP, HSTS, X-Content-Type-Options) na ej-application, reduzindo o CVSS de 5.9 (Medium) para aproximadamente 2.0 (Low) ao mitigar vetores de XSS, downgrade de HTTPS e MIME sniffing. Além disso, foi criada a biblioteca poc-scripts.md, com scripts de PoC reutilizáveis para XSS refletido, SQL Injection, rate limiting e validação de headers, permitindo auditorias mais rápidas e consistentes pelo Red Team.

5. Maiores Dificuldades

Blue Team

Hardening em Aplicação Existente: Aplicar configurações de segurança estritas (como desativar DEBUG ou alterar permissões de usuário no Docker) gerou conflitos de compatibilidade, exigindo testes manuais para não quebrar funcionalidades do sistema.
Gestão de Falsos Positivos: A ferramenta de análise de dependências (pip-audit) apontou diversas vulnerabilidades em pacotes antigos, exigindo um esforço significativo de triagem manual para distinguir riscos reais de alertas não exploráveis.
Documentação Técnica Clara: Criar documentação que fosse técnica o suficiente para desenvolvedores implementarem as ferramentas, mas também clara para stakeholders entenderem o valor e funcionamento de cada solução de segurança.
Consolidação de Artefatos: Unificar entregas de naturezas muito distintas — diagramas visuais (DFD), código de pipeline (YAML), documentação técnica e relatórios de texto — em um único Pull Request coeso e organizado foi um desafio de documentação.

Red Team

Não houve dificuldades durante o processo de estudo e documentação

6. Lições Aprendidas

Blue Team

Segurança como Código (IaC): Aprendemos que a segurança não se limita ao código da aplicação; as configurações de infraestrutura (Dockerfile) e do framework (settings.py) são vetores críticos que exigem versionamento e auditoria contínua.
Documentação como Ponte entre Teoria e Prática: A elaboração da documentação técnica reforçou a importância de conectar explicitamente cada ferramenta de segurança aos riscos da modelagem de ameaças, criando uma narrativa clara sobre "por que" cada ferramenta foi escolhida e "como" ela mitiga riscos específicos.
O Valor do Shift-Left: A implementação do pipeline confirmou que identificar vulnerabilidades (como chaves vazadas) no momento do push é muito mais eficiente e menos custoso do que tentar remediar problemas em um software já construído.
Documentação é Governança: A necessidade de unificar o trabalho no PR final reforçou que, em segurança, a documentação técnica (por que escolhemos tal ferramenta, como mitigamos tal risco) é tão importante quanto a própria implementação para garantir a continuidade do projeto.
Critérios Claros de Aceitação: Estabelecer critérios baseados em severidade (Crítico → FAIL, Alto → FAIL, Médio → WARNING) automatiza a tomada de decisão na pipeline e alinha o time sobre o que realmente precisa ser corrigido imediatamente.

Red Team

Uso do MITRE ATT&CK para estruturar relatórios de vulnerabilidades
Como criar documentação de contribuição focada em segurança (Jinja2)
Importância de headers HTTP de segurança (CSP, HSTS, X-Content-Type-Options) como primeira camada de defesa em aplicações web
Benefícios de consolidar scripts automatizados de PoC para padronizar testes de segurança e apoiar o trabalho contínuo do Red Team