🚀 Capítulo 20: Projeto Final Parte 2: Relatório (Tema: Mr. Robot)
NOTE
Este capítulo finaliza o curso de Desenvolvimento Seguro. Elliot Alderson precisa entregar o veredito final sobre a segurança da E Corp. Salve o mundo digital!
1. 🎯 Objetivo da Aula
Consolidar as vulnerabilidades encontradas na auditoria em um relatório formal e estruturado, aprendendo a comunicar riscos de segurança tanto para desenvolvedores quanto para diretores da empresa.
2. 🏢 O Cenário Prático (Seu Desafio)
Você concluiu a análise das 4 descobertas no capítulo anterior. Agora, a diretoria da E Corp precisa do seu Veredito Final.
- Eles não entendem termos técnicos como “SQL Injection” ou “SCA”.
- Eles querem saber: “O nosso sistema está seguro para ir ao ar ou não?“.
- Eles querem saber o que a empresa precisa fazer no futuro para não cometer esses erros de novo.
Seu desafio é escrever a conclusão do relatório de forma que um diretor de empresa entenda o perigo e autorize o investimento em segurança!
🧠 Fundamentos: A Teoria Traduzida
Um relatório de segurança profissional possui duas partes principais:
- Sumário Executivo (Para Diretores): Linguagem simples, foca no impacto financeiro e na imagem da empresa. Não usa termos técnicos.
- Detalhes Técnicos (Para Programadores): Linguagem técnica, mostra as linhas de código com erro e como corrigi-las (o que fizemos no Cap. 19).
4. 📖 Exemplo Guiado: O Sumário Executivo
Veja como traduzir os problemas técnicos para a diretoria:
- O que o técnico diria: “Encontramos falhas de SQLi no login e hardcoded secrets no arquivo config.”
- O que o diretor precisa ler: “Identificamos falhas críticas que permitem que criminosos roubem todo o banco de dados de clientes e acessem as contas financeiras da empresa. O sistema NÃO deve ir ao ar até que essas falhas sejam corrigidas.”
5. 🛠️ Prática Obrigatória 1: O Veredito
Com base nas 4 falhas graves que vimos no capítulo anterior (Login vulnerável, Docker como root, Senha no GitHub e Biblioteca com vírus):
- Qual é o seu veredito oficial para a diretoria da empresa? O sistema pode ser lançado hoje ou deve ser bloqueado?
- Escreva uma frase de justificativa para o seu veredito usando a linguagem que um diretor entenderia.
6. 🛠️ Prática Obrigatória 2: Olhando para o Futuro
Para evitar que a E Corp cometa os mesmos erros no próximo projeto, você deve sugerir a adoção de uma cultura moderna de segurança.
- Qual o nome da filosofia que aprendemos no Capítulo 02 que diz que devemos trazer a segurança para o início do projeto?
- Qual o nome do movimento que integra Desenvolvimento, Operações e Segurança?
7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)
- Faça o Commit: No GitHub Desktop, digite a mensagem (ex:
Finaliza Capítulo 20 Seguranca) e clique em Commit to main. - Envie para a Nuvem (Push): Clique em Push origin.
8. 📂 Estrutura de Pastas
mod_12_desenvolvimento_seguro/
├── capitulos/
│ ├── capitulo_20_projeto_p2.md
│ └── codigos/
│ └── cap20/
│ └── conclusao_auditoria.txt💡 Checkpoint de Lógica
Parabéns por chegar até aqui! A segurança é uma jornada contínua. Um sistema seguro hoje pode se tornar vulnerável amanhã se uma nova falha for descoberta. Continue sempre estudando e praticando!
10. 🔥 Desafio de Fixação
Crie um resumo de 3 linhas dizendo qual foi o aprendizado mais importante que você teve neste curso de Desenvolvimento Seguro.
🔑 Gabarito de Código/Fórmulas
Gabarito da Prática 1:
- Bloqueado (O sistema está extremamente vulnerável).
- “O sistema possui falhas críticas que expõem os dados dos nossos clientes e chaves financeiras na internet. Lançar o sistema hoje traria um risco inaceitável de prejuízo financeiro e danos à marca da empresa.” Gabarito da Prática 2:
- Shift Left.
- DevSecOps.