Diário de Bordo – Ana Carolina Madeira Fialho
Disciplina: Gerência de Configuração e Evolução de Software
Equipe: Blue Team
Comunidade/Projeto de Software Livre: OWASP (ej-application)
Sprint 5 – 19/11/2025 – 02/12/2025
Resumo da Sprint
Nesta sprint, o Blue Team focou na implementação e documentação de uma pipeline de segurança robusta para o projeto ej-application, seguindo uma abordagem DevSecOps. Minha contribuição principal foi a documentação detalhada das ferramentas de segurança implementadas (Gitleaks, Semgrep, pip-audit e Trivy), explicando como cada uma mitiga riscos específicos identificados na modelagem de ameaças. Trabalhei em conjunto com a equipe para estruturar a integração dessas ferramentas na pipeline CI/CD existente, definindo critérios de severidade baseados na classificação de riscos e estabelecendo um fluxo de resposta para os findings de segurança.
Atividades Realizadas
| Data | Atividade | Tipo (Código/Doc/Discussão/Outro) | Link/Referência | Status |
|---|---|---|---|---|
| 20/11 | Reunião de alinhamento do Blue Team para divisão de tarefas finais | Discussão | – | Concluído |
| 24/11 | Pesquisa e estudo aprofundado das ferramentas de segurança (Gitleaks, Semgrep, pip-audit, Trivy) | Estudo | – | Concluído |
| 28/11 | Documentação das ferramentas de segurança: explicação, configuração e integração | Doc | – | Concluído |
| 30/11 | Testes e validação dos conceitos documentados na pipeline do projeto | Análise/Teste | – | Concluído |
| 01/12 | Documentação para o formato de Diário de Bordo | Doc | – | Concluído |
Maiores Avanços
- Documentação Estrutural: Criei uma documentação clara que conecta cada ferramenta de segurança a um risco específico da modelagem de ameaças (ex: Gitleaks → "Vazamento de Credenciais").
- Integração Prática: Documentei como integrar as ferramentas em um novo estágio (
security) dentro da pipeline GitLab CI/CD existente, incluindo exemplos de configuração YAML. - Critérios Operacionais: Estabeleci critérios de aceitação baseados em severidade (Crítico, Alto, Médio, Baixo) para automatizar a resposta da pipeline (FAIL, WARNING, PASS).
- Visão de Processo: Defini um fluxo de resposta a findings (Detecção → Triagem → Correção → Verificação → Documentação), promovendo uma cultura de melhoria contínua em segurança.
Maiores Dificuldades
- Garantir Clareza: Assegurar que a documentação fosse compreensível não apenas para a equipe técnica, mas também para stakeholders que precisam entender o valor e o funcionamento das ferramentas de segurança.
Aprendizados
- DevSecOps na Prática: Compreendi na prática como integrar verificações de segurança de forma automatizada e contínua no fluxo de desenvolvimento (pipelines CI/CD).
- Ferramentas Especializadas: Aprofundei meu conhecimento no propósito e funcionamento de ferramentas específicas como o Semgrep (para padrões de código) e o Trivy (para análise multifacetada).
- Documentação como Ferramenta: Percebi a importância da documentação não apenas como registro, mas como um guia para a operação e manutenção do processo de segurança, facilitando a tomada de decisão baseada em severidade.