Pular para conteúdo

Desenvolvimento Seguro 🛡️

Proteja aplicações desde a concepção do código. Aprenda a pensar como atacante para se defender como profissional — fundamentos de segurança, mecanismos de defesa, pentest controlado e as práticas que todo desenvolvedor precisa dominar.

Foco do Curso

Metodologia: Aprendizado prático combinando teoria de segurança da informação, laboratórios de pentest controlado e aplicação direta do OWASP Top 10 em cenários reais.

🎯 O Que Você Vai Aprender

  • Fundamentos de Segurança

    Entenda ameaças, engenharia social, malware e como avaliar riscos com uma Política de Segurança da Informação.

    Ir para Módulo 1

  • Mecanismos de Defesa

    Domine firewalls, IDS/IPS, criptografia, assinatura digital e autenticação segura.

    Ver Módulo 2

  • Pentest Controlado

    Pratique scanners, enumeração e exploração controlada em ambiente de laboratório.

    Ver Pentest

  • Segurança Web e LGPD

    Aplique o OWASP Top 10, proteja aplicações web e entenda privacidade e legislação.

    Ver Módulo 4

📚 Jornada de Aprendizado (16 Aulas)

O curso é estruturado em seis módulos, dos fundamentos teóricos à prática de pentest e conformidade legal.

🧱 Módulo 1: Fundamentos e Ameaças (Aulas 01-04)

🔒 Módulo 2: Mecanismos de Segurança (Aulas 05-08)

🕵️ Módulo 3: Prática (Aulas 09-11)

🌐 Módulo 4: Segurança Web (Aulas 12-13)

⚖️ Módulo 5: Ética e Legislação (Aulas 14-15)

🏆 Módulo 6: Projeto Final (Aula 16)

Começar Minha Jornada em Segurança

Plano de Ensino 🧭

Curso: Desenvolvimento Seguro
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de Desenvolvimento Seguro.
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 Fundamentos de Segurança da Informação ️ Teoria, Prática Guiada, Quiz e Exercícios
02 Ameaças e Engenharia Social ️ Teoria, Prática Guiada, Quiz e Exercícios
03 Malware e Tipos de Ataques Teoria, Prática Guiada, Quiz e Exercícios
04 Análise de Riscos e PSI Teoria, Prática Guiada, Quiz e Exercícios
05 Firewall, IDS e IPS Teoria, Prática Guiada, Quiz e Exercícios
06 Criptografia e Assinatura Digital Teoria, Prática Guiada, Quiz e Exercícios
07 Autenticação e Autorização Teoria, Prática Guiada, Quiz e Exercícios
08 Segurança em Redes Teoria, Prática Guiada, Quiz e Exercícios
09 Introdução ao Pentest Teoria, Prática Guiada, Quiz e Exercícios
10 Scanners e Enumeração Teoria, Prática Guiada, Quiz e Exercícios
11 Exploração Controlada Teoria, Prática Guiada, Quiz e Exercícios
12 OWASP Top 10 Teoria, Prática Guiada, Quiz e Exercícios
13 Proteções para Aplicações Web ️ Teoria, Prática Guiada, Quiz e Exercícios
14 LGPD e Privacidade Teoria, Prática Guiada, Quiz e Exercícios
15 Cultura Hacker (Ética e Carreira) Teoria, Prática Guiada, Quiz e Exercícios
16 Projeto Integrador Teoria, Prática Guiada, Quiz e Exercícios
17 Análise Estática (SAST) e Dinâmica (DAST) de Código Teoria, Prática Guiada, Quiz e Exercícios
18 Mitigação de Vulnerabilidades OWASP Top 10 Teoria, Prática Guiada, Quiz e Exercícios
19 Gestão Segura de Segredos e Certificados em CI/CD Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: Pipeline DevSecOps Autônomo Hardened Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de Desenvolvimento Seguro.
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Aulas do Curso

Bem-vindo à seção de aulas! Aqui você encontra todo o conteúdo do curso organizado em 5 módulos estruturados.

📚 Módulos do Curso

Módulo 1 – Fundamentos e Ameaças

Aula 01 - Fundamentos de Segurança da Informação 🛡️

Objetivo

Objetivo: Compreender os pilares que sustentam toda a segurança da informação (Confidencialidade, Integridade e Disponibilidade) e entender por que segurança é processo, não produto.

1. O que é Segurança da Informação? 🧐

Segurança da Informação é o conjunto de práticas, tecnologias e políticas que protegem dados contra acesso não autorizado, alteração indevida ou indisponibilidade.

Segurança não é algo que você "compra e instala uma vez" — é um processo contínuo de avaliação, defesa e resposta.

2. A Tríade CIA (CID) 🔺

Todo conceito de segurança parte de três pilares:

Pilar O que significa Exemplo de violação
Confidencialidade Só quem tem permissão acessa a informação Vazamento de senha em texto claro
Integridade A informação não é alterada sem autorização Um invasor altera o valor de uma transferência
Disponibilidade A informação está acessível quando necessário Um ataque DDoS derruba um site 
graph TD
    A[Segurança da Informação] --> B[Confidencialidade]
    A --> C[Integridade]
    A --> D[Disponibilidade]

3. Segurança vs Desenvolvimento: Onde Elas se Encontram 🔗

Neste curso, o foco é Desenvolvimento Seguro: em vez de "adicionar segurança no final", você vai aprender a pensar em segurança desde a primeira linha de código.

  • Shift Left: quanto mais cedo no ciclo de desenvolvimento você pensa em segurança, mais barato é corrigir problemas.
  • Security by Design: a arquitetura do sistema já nasce considerando ameaças, não é um "adicional" depois.

4. Quem são os Adversários? 🎭

  1. Script kiddies: usam ferramentas prontas, sem entender profundamente como funcionam.
  2. Hackers individuais: buscam desafio, reconhecimento ou ganho financeiro pequeno.
  3. Grupos criminosos organizados: ransomware, roubo de dados em massa.
  4. Insiders: funcionários ou ex-funcionários com acesso legítimo que abusam dele.
  5. Atores estatais (APT): grupos altamente sofisticados, ligados a governos.

5. Mini-Projeto: Mapeando Ativos 🗂️

Escolha um sistema que você conhece bem (um app que usa, ou um projeto seu):

  1. Liste os "ativos" de informação envolvidos (dados de usuário, senhas, pagamentos, etc.).
  2. Para cada ativo, classifique: qual pilar da CID é mais crítico para ele (confidencialidade, integridade ou disponibilidade)?
  3. Justifique sua resposta em 1-2 frases por ativo.

6. Exercício de Fixação 🧠

  1. Explique com suas palavras a diferença entre confidencialidade e integridade, usando um exemplo do seu dia a dia.
  2. O que significa "Shift Left" em segurança?
  3. Cite dois perfis diferentes de adversário e suas motivações.

Próxima Aula: Como esses adversários realmente atacam? Ameaças e Engenharia Social 🎭

Aula 02 - Ameaças e Engenharia Social 🕵️

Objetivo

Objetivo: Entender a diferença entre ameaça, vulnerabilidade e risco, e reconhecer as técnicas de engenharia social mais usadas para comprometer sistemas através das pessoas.

1. Ameaça x Vulnerabilidade x Risco 🧩

Termo Definição Exemplo
Ameaça Algo com potencial de causar dano Um invasor, um vírus
Vulnerabilidade Uma fraqueza que pode ser explorada Senha fraca, software desatualizado
Risco Probabilidade de uma ameaça explorar uma vulnerabilidade Chance real de invadir com senha fraca

Risco = Ameaça × Vulnerabilidade × Impacto. Reduzir qualquer um dos três reduz o risco total.

2. Engenharia Social: o Elo Mais Fraco 🎭

A engenharia social explora a psicologia humana, não falhas técnicas — é frequentemente o vetor de ataque mais eficaz que existe.

  • Phishing: e-mails falsos imitando bancos, empresas ou colegas.
  • Spear Phishing: phishing direcionado a uma pessoa específica, com dados personalizados.
  • Pretexting: criar uma história falsa ("sou do suporte técnico") para obter informações.
  • Baiting: deixar um pendrive infectado "esquecido" para que alguém o conecte por curiosidade.
graph TD
    A[Atacante pesquisa a vítima] --> B[Cria pretexto convincente]
    B --> C[Contata a vítima]
    C --> D{Vítima cai no golpe?}
    D -- Sim --> E[Credenciais comprometidas]
    D -- Não --> F[Ataque falha]

3. Sinais de um E-mail de Phishing 🚩

  1. Domínio do remetente ligeiramente diferente do oficial (paypa1.com em vez de paypal.com).
  2. Senso de urgência exagerado ("sua conta será bloqueada em 1 hora!").
  3. Links cujo destino real (visível ao passar o mouse) não bate com o texto exibido.
  4. Erros de português ou formatação estranha em comunicações de empresas grandes.

4. Por que Desenvolvedores São Alvos Específicos 👨‍💻

Times de desenvolvimento têm acesso privilegiado a código-fonte, credenciais de infraestrutura e sistemas de produção — o que os torna alvos valiosos de spear phishing e pretexting direcionado (ex: um e-mail falso "do CI/CD" pedindo para rodar um script).

5. Mini-Projeto: Caçador de Phishing 🚀

  1. Encontre (ou peça para simular) um e-mail suspeito.
  2. Verifique: o domínio do remetente bate com a empresa? Há erros de português? O link aponta para onde parece?
  3. Documente pelo menos 3 indicadores encontrados e explique por que cada um é suspeito.

6. Exercício de Fixação 🧠

  1. Explique a diferença entre ameaça, vulnerabilidade e risco com um exemplo próprio.
  2. Cite 3 sinais que ajudam a identificar um e-mail de phishing.
  3. Por que desenvolvedores costumam ser alvos valiosos de engenharia social?

Próxima Aula: Do phishing ao código malicioso: Malware e Tipos de Ataques 🦠

Aula 03 - Malware e Tipos de Ataques 🦠

Objetivo

Objetivo: Conhecer as principais famílias de software malicioso e os vetores de ataque técnicos mais comuns, entendendo como cada um funciona e como se propaga.

1. O que é Malware? 🧬

Malware (software malicioso) é qualquer programa criado com a intenção de causar dano, roubar dados ou obter acesso não autorizado a um sistema.

2. As Principais Famílias 🗂️

Tipo Como age
Vírus Se anexa a arquivos legítimos e se espalha quando o arquivo é executado
Worm Se replica sozinho pela rede, sem precisar de arquivo hospedeiro
Trojan (Cavalo de Troia) Se disfarça de programa legítimo, mas executa ações maliciosas escondidas
Ransomware Cifra os arquivos da vítima e exige pagamento (resgate) para devolver o acesso
Spyware Coleta informações da vítima (senhas, hábitos) sem seu conhecimento
Keylogger Registra tudo o que é digitado no teclado 
graph LR
    A[Malware] --> B[Vírus]
    A --> C[Worm]
    A --> D[Trojan]
    A --> E[Ransomware]
    A --> F[Spyware]

3. Vetores de Ataque Técnicos Comuns 🕳️

  1. Força bruta: tentar todas as combinações possíveis de senha até acertar.
  2. Injeção: inserir código malicioso em campos de entrada (veremos em detalhe na Aula 12).
  3. Man-in-the-Middle (MITM): interceptar comunicação entre duas partes sem que elas percebam.
  4. Negação de Serviço (DoS/DDoS): sobrecarregar um sistema até torná-lo indisponível.

4. Ransomware: o Ataque Mais Caro da Década 💰

Ransomware combina malware + criptografia (que veremos em detalhe na Aula 06): o atacante cifra os arquivos da vítima com uma chave que só ele possui, tornando os dados inacessíveis até o pagamento — sem garantia de que os dados serão realmente devolvidos.

Nunca pague o resgate sem consultar especialistas

Pagar não garante recuperação dos dados e financia mais ataques. A melhor defesa contra ransomware é backup offline e testado regularmente.

5. Mini-Projeto: Linha do Tempo de um Ataque 🚀

Escolha um caso real de malware (WannaCry, NotPetya, ou outro que você pesquisar):

  1. Identifique o tipo de malware (vírus, worm, ransomware...).
  2. Descreva como ele se propagava.
  3. Qual vulnerabilidade específica ele explorava?
  4. Que medida teria evitado ou mitigado o ataque?

6. Exercício de Fixação 🧠

  1. Qual a diferença fundamental entre um vírus e um worm?
  2. Por que um Trojan é particularmente perigoso do ponto de vista da engenharia social (Aula 02)?
  3. Por que backup offline é considerado a defesa mais eficaz contra ransomware?

Próxima Aula: Como decidir onde investir na defesa? Análise de Riscos e PSI 📋

Aula 04 - Análise de Riscos e PSI 📋

Objetivo

Objetivo: Aprender a avaliar e priorizar riscos de segurança de forma estruturada, e entender o papel de uma Política de Segurança da Informação (PSI) dentro de uma organização.

1. Por que Analisar Riscos? ⚖️

Nenhuma organização tem recursos infinitos para se proteger de tudo. A Análise de Riscos ajuda a decidir onde investir primeiro, priorizando o que realmente importa.

2. Matriz de Probabilidade x Impacto 📊

Uma ferramenta simples e amplamente usada para priorizar riscos:

Impacto Baixo Impacto Médio Impacto Alto
Probabilidade Alta 🟡 Médio 🟠 Alto 🔴 Crítico
Probabilidade Média 🟢 Baixo 🟡 Médio 🟠 Alto
Probabilidade Baixa 🟢 Baixo 🟢 Baixo 🟡 Médio 
graph TD
    A[Identificar Ativo] --> B[Identificar Ameaças]
    B --> C[Avaliar Probabilidade]
    C --> D[Avaliar Impacto]
    D --> E[Classificar Risco]
    E --> F[Definir Tratamento]

3. As Quatro Estratégias de Tratamento de Risco 🛠️

  1. Mitigar: reduzir a probabilidade ou o impacto (ex: implementar MFA).
  2. Transferir: repassar o risco a terceiros (ex: contratar um seguro cibernético).
  3. Aceitar: decidir conscientemente conviver com o risco (quando o custo de mitigar supera o benefício).
  4. Evitar: eliminar a atividade que gera o risco (ex: não coletar um dado sensível que não é realmente necessário).

4. O que é uma PSI? 📜

A Política de Segurança da Informação (PSI) é o documento formal que define as regras, responsabilidades e diretrizes de segurança de uma organização — desde uso aceitável de recursos até resposta a incidentes.

O que uma PSI geralmente contém:

  • Classificação da informação (pública, interna, confidencial, restrita).
  • Regras de uso de senhas e dispositivos.
  • Processo de resposta a incidentes.
  • Consequências para violação das regras.

PSI não é burocracia — é proteção legal e operacional

Sem uma PSI formal, é muito mais difícil responsabilizar alguém por uma violação de segurança, e a empresa fica mais vulnerável tanto tecnicamente quanto juridicamente.

5. Mini-Projeto: Sua Primeira Análise de Risco 🚀

Para um sistema fictício de e-commerce:

  1. Liste 4 riscos possíveis (ex: vazamento de dados de cartão, indisponibilidade no Black Friday, funcionário mal-intencionado, dependência desatualizada).
  2. Para cada um, estime a probabilidade (baixa/média/alta) e o impacto (baixo/médio/alto).
  3. Posicione cada risco na matriz da seção 2.
  4. Escolha uma estratégia de tratamento (mitigar/transferir/aceitar/evitar) para cada risco e justifique.

6. Exercício de Fixação 🧠

  1. Qual a diferença entre "mitigar" e "aceitar" um risco? Dê um exemplo de cada.
  2. Por que uma empresa precisa de uma PSI formal, mesmo tendo boas ferramentas de segurança técnica?
  3. Cite um exemplo de risco que você trataria com "transferência" (ex: seguro).

Próxima Aula: Fim do Módulo 1! Hora dos mecanismos de defesa: Firewall, IDS e IPS 🧱

Módulo 2 – Mecanismos de Segurança

Aula 05 - Firewall, IDS e IPS 🧱

Objetivo

Objetivo: Entender as três principais linhas de defesa de perímetro de rede — firewall, sistemas de detecção (IDS) e de prevenção de intrusão (IPS) — e como elas se complementam.

1. Firewall: o Porteiro da Rede 🚪

Um Firewall filtra o tráfego de rede com base em regras — permitindo ou bloqueando conexões conforme critérios como origem, destino e porta.

Tipo Como funciona
Firewall de Rede Filtra tráfego entre redes (ex: entre a Internet e a rede interna)
Firewall de Aplicação (WAF) Analisa o conteúdo das requisições HTTP, entende o protocolo da aplicação
Firewall Pessoal Roda no próprio computador, protege apenas aquele dispositivo 
graph LR
    A[Internet] --> F[Firewall]
    F -- "Regra permite" --> B[Rede Interna]
    F -- "Regra bloqueia" --> X[Tráfego Descartado]

2. IDS: o Vigilante que Observa 👁️

O IDS (Intrusion Detection System) monitora o tráfego e alerta quando detecta um padrão suspeito — mas não bloqueia nada automaticamente.

  • Baseado em Assinatura: compara o tráfego com um banco de padrões de ataques conhecidos.
  • Baseado em Anomalia: aprende o comportamento "normal" da rede e alerta sobre desvios.

3. IPS: o Vigilante que Age ⛔

O IPS (Intrusion Prevention System) faz o mesmo trabalho de detecção do IDS, mas vai além: bloqueia automaticamente o tráfego identificado como malicioso, em tempo real.

IDS IPS
Ação Apenas alerta Bloqueia automaticamente
Posição na rede Observa uma cópia do tráfego (fora do caminho) Fica no caminho direto do tráfego
Risco Ataque pode passar antes do alerta ser visto Falso positivo pode bloquear tráfego legítimo

4. Defesa em Camadas 🧅

Nenhuma ferramenta sozinha é suficiente. A abordagem profissional é a defesa em profundidade — várias camadas de proteção, para que a falha de uma não comprometa tudo.

graph TD
    A[Internet] --> B[Firewall de Borda]
    B --> C[IPS]
    C --> D[WAF - se for aplicação web]
    D --> E[Aplicação com validação própria]
    E --> F[Banco de Dados com controle de acesso]

5. Mini-Projeto: Desenhando um Perímetro 🚀

Para uma aplicação web fictícia (frontend + API + banco de dados):

  1. Desenhe (em papel, Mermaid ou ferramenta de diagramas) as camadas de defesa que você colocaria entre a Internet e o banco de dados.
  2. Justifique a posição de cada camada (firewall, WAF, IPS).
  3. Explique o que aconteceria se o atacante conseguisse burlar apenas a primeira camada.

6. Exercício de Fixação 🧠

  1. Qual a diferença fundamental entre um IDS e um IPS?
  2. Por que um Web Application Firewall (WAF) é diferente de um firewall de rede tradicional?
  3. Explique o conceito de "defesa em profundidade" com suas palavras.

Próxima Aula: A base matemática da proteção de dados: Criptografia e Assinatura Digital 🔐

Aula 06 - Criptografia e Assinatura Digital 🔐

Objetivo

Objetivo: Entender os conceitos essenciais de criptografia simétrica, assimétrica, hash e assinatura digital — o suficiente para aplicar corretamente em código, sem precisar ser um criptógrafo.

1. Criptografia Simétrica: Uma Chave para Tudo 🔑

Na criptografia simétrica, a mesma chave cifra e decifra. É rápida — o algoritmo padrão hoje é o AES.

graph LR
    A[Texto Claro] -- "Cifra com Chave K" --> B[Texto Cifrado]
    B -- "Decifra com a MESMA Chave K" --> A

O problema

Como transmitir a chave com segurança sem que um invasor a intercepte? É aqui que entra a criptografia assimétrica.

2. Criptografia Assimétrica: Duas Chaves 🗝️

Usa um par de chaves: uma pública (compartilhável) e uma privada (secreta). O algoritmo mais usado é o RSA.

Chave Quem tem acesso Função
Pública Todo mundo Cifra mensagens / verifica assinaturas
Privada Só o dono Decifra mensagens / cria assinaturas

Na prática, sistemas reais combinam as duas: assimétrica para trocar uma chave secreta, simétrica (rápida) para cifrar o tráfego de verdade — é assim que o HTTPS funciona.

3. Hash: Impressão Digital dos Dados #️⃣

Uma função de hash transforma qualquer entrada em uma saída de tamanho fixo, de forma unidirecional (não dá para reverter).

  • MD5 e SHA-1: ❌ quebrados, não usar mais.
  • SHA-256: ✅ padrão atual, seguro.

Usos principais: 1. Verificar integridade de arquivos. 2. Guardar senhas (com sal e algoritmo lento — veremos isso com mais detalhe quando falarmos de autenticação).

4. Assinatura Digital: Provando Autoria 📜

A assinatura digital inverte o fluxo da criptografia assimétrica: cifra-se o hash do documento com a chave privada do autor.

graph LR
    A[Documento] --> H[Hash SHA-256]
    H -- "Cifra com Chave PRIVADA" --> S[Assinatura]
    S -- "Verifica com Chave PÚBLICA" --> V{Bate?}
    V -- Sim --> OK[Autêntico e íntegro]

Ela garante três coisas ao mesmo tempo:

  1. Autenticidade: só quem tem a chave privada poderia ter assinado.
  2. Integridade: se o documento mudar, o hash muda, e a assinatura deixa de bater.
  3. Não-repúdio: o autor não pode alegar depois que "não foi ele".

5. Regra de Ouro: Nunca Implemente Sua Própria Criptografia ⚠️

Use sempre bibliotecas testadas

Pequenos erros de implementação (um IV reutilizado, um algoritmo obsoleto) podem quebrar completamente a segurança. Use bibliotecas consagradas (cryptography em Python, crypto no Node.js) — nunca "invente" seu próprio algoritmo.

6. Mini-Projeto: Verificador de Integridade 🚀

  1. Escolha uma linguagem (Python com hashlib é uma boa opção).
  2. Escreva uma função que calcula o hash SHA-256 de um arquivo.
  3. Calcule o hash, modifique 1 caractere do arquivo, e calcule de novo.
  4. Confirme que os hashes são completamente diferentes (efeito avalanche).

7. Exercício de Fixação 🧠

  1. Por que sistemas reais (como o HTTPS) combinam criptografia simétrica e assimétrica em vez de usar só uma?
  2. Explique por que hash não é a mesma coisa que criptografia (cifragem).
  3. Quais as três garantias que uma assinatura digital proporciona?

Próxima Aula: Provando quem você é: Autenticação e Autorização 🔑

Aula 07 - Autenticação e Autorização 🔑

Objetivo

Objetivo: Diferenciar autenticação de autorização, entender os fatores de autenticação e os modelos de controle de acesso mais usados na indústria, e aprender a armazenar senhas com segurança.

1. Autenticação x Autorização 🚦

Dois conceitos frequentemente confundidos, mas que respondem perguntas diferentes:

  • Autenticação (AuthN): "Quem é você?" — provar identidade.
  • Autorização (AuthZ): "O que você pode fazer?" — decidir permissões, depois que a identidade já foi confirmada.

2. Os Três Fatores de Autenticação 🧑‍💻

Fator Categoria Exemplo
Algo que você sabe Conhecimento Senha, PIN
Algo que você tem Posse Celular (app autenticador), token físico
Algo que você é Inerência Impressão digital, reconhecimento facial

MFA (Multi-Factor Authentication)

Combinar 2+ fatores diferentes reduz drasticamente o risco: mesmo que a senha vaze, o atacante ainda precisa do segundo fator.

3. Armazenamento Seguro de Senhas 🗝️

Nunca guarde senhas em texto puro, nem com hash simples (SHA-256 puro é rápido demais e vulnerável a rainbow tables).

graph LR
    A[senha123] --> C["+ salt aleatório"]
    C --> H["bcrypt/Argon2 (lento de propósito)"]
    H --> R[Hash único e seguro]
  • bcrypt: padrão de mercado, salt embutido automaticamente.
  • Argon2: recomendação mais forte atualmente, vencedor da Password Hashing Competition.

4. Modelos de Controle de Acesso 🎚️

Modelo Sigla Como funciona
Controle Baseado em Papéis RBAC Usuário recebe um "papel" (admin, editor, leitor) com permissões pré-definidas
Controle Baseado em Atributos ABAC Decisão baseada em atributos dinâmicos (horário, localização, departamento)
Princípio do Menor Privilégio — Cada usuário/sistema deve ter apenas o acesso mínimo necessário 
graph TD
    U[Usuário] --> R[Papel: Editor]
    R --> P1[Permissão: Ler]
    R --> P2[Permissão: Editar]
    R -.->|Não tem| P3[Permissão: Apagar usuários]

5. Tokens de Sessão: JWT e Sessões 🎫

  • Sessão tradicional: servidor guarda o estado do usuário logado em memória/banco.
  • JWT (JSON Web Token): "crachá digital" assinado, que carrega os dados do usuário — o servidor não precisa guardar nada (stateless).

JWT não é criptografado por padrão

O payload de um JWT comum é apenas codificado, não cifrado — qualquer um pode decodificar e ler. Nunca guarde senhas ou dados sensíveis dentro dele.

6. Mini-Projeto: Simulador de RBAC 🚀

  1. Defina 3 papéis: admin, editor, leitor.
  2. Defina 4 permissões: criar, editar, apagar, visualizar.
  3. Associe cada papel às permissões que deveria ter.
  4. Escreva uma função tem_permissao(papel, acao) que retorna true/false consultando essa estrutura.

7. Exercício de Fixação 🧠

  1. Cite um exemplo de cada um dos três fatores de autenticação.
  2. Por que hash simples (SHA-256 puro) não é adequado para senhas?
  3. Explique o Princípio do Menor Privilégio com um exemplo prático.

Próxima Aula: Protegendo o tráfego entre sistemas: Segurança em Redes 🌐

Aula 08 - Segurança em Redes 🌐

Objetivo

Objetivo: Encerrar o Módulo 2 entendendo como o TLS protege o tráfego de rede, os riscos de redes não confiáveis, e as boas práticas de configuração de rede para aplicações.

1. SSL x TLS: a Base do Tráfego Seguro 🔒

TLS (Transport Layer Security) é o protocolo que cifra a comunicação entre cliente e servidor — o "S" do HTTPS. Seu antecessor, o SSL, está totalmente aposentado por vulnerabilidades.

Versão Status
SSL 2.0 / 3.0 ❌ Quebrados
TLS 1.0 / 1.1 ❌ Obsoletos
TLS 1.2 / 1.3 ✅ Padrão atual

2. O TLS Handshake em Resumo 🤝

sequenceDiagram
    participant C as Cliente
    participant S as Servidor
    C->>S: Client Hello
    S->>C: Server Hello + Certificado
    C->>C: Valida o certificado
    C->>S: Troca de chaves (Diffie-Hellman)
    Note over C,S: Chave simétrica compartilhada
    C->>S: Dados cifrados com AES
  1. Servidor prova sua identidade com um certificado digital.
  2. Cliente e servidor combinam uma chave secreta.
  3. Toda a comunicação depois disso é cifrada, rápida e segura.

3. Riscos de Redes Não Confiáveis 📡

  • Wi-Fi público: qualquer pessoa na mesma rede pode tentar interceptar tráfego não cifrado (ataque Man-in-the-Middle).
  • VPN: cria um "túnel" cifrado entre seu dispositivo e um servidor confiável, protegendo o tráfego mesmo em redes hostis.
  • DNS Spoofing: um atacante engana a resolução de nomes, redirecionando você para um servidor falso.

4. Segmentação de Rede 🧩

Em um ambiente de produção, dividir a rede em segmentos limita o alcance de um invasor caso ele comprometa uma parte do sistema.

graph TD
    Internet --> DMZ[Zona Desmilitarizada - servidores web]
    DMZ --> App[Rede de Aplicação]
    App --> DB[Rede de Banco de Dados - isolada, sem acesso direto à Internet]

Princípio

Se um atacante comprometer o servidor web na DMZ, a segmentação impede que ele acesse diretamente o banco de dados — ele precisaria comprometer outra camada.

5. Boas Práticas de Configuração de Rede 🛠️

  1. HTTPS obrigatório em produção, nunca HTTP puro para dados sensíveis.
  2. Firewall de rede configurado para bloquear tudo por padrão, liberando só o necessário ("deny by default").
  3. VPN para acesso administrativo a servidores de produção.
  4. Rotação de credenciais de rede periodicamente.

6. Mini-Projeto: Auditor de TLS 🚀

  1. Escolha 3 sites diferentes.
  2. Para cada um, verifique a versão de TLS suportada (openssl s_client -connect site.com:443).
  3. Verifique se o cabeçalho Strict-Transport-Security está presente (curl -I).
  4. Compare: qual site parece mais bem configurado?

7. Exercício de Fixação 🧠

  1. Descreva em 3 passos o que acontece durante um TLS handshake.
  2. Por que uma VPN protege você em uma rede Wi-Fi pública não confiável?
  3. Explique o benefício da segmentação de rede com um exemplo próprio.

Próxima Aula: Fim do Módulo 2! Hora de pensar como atacante: Introdução ao Pentest 🎯

Módulo 3 – Prática

Aula 09 - Introdução ao Pentest 🎯

Objetivo

Objetivo: Entender o que é um teste de penetração (pentest), suas fases metodológicas, os tipos de escopo, e — mais importante — os limites éticos e legais dessa prática.

1. O que é Pentest? 🕵️

Um Teste de Penetração (Pentest) é uma simulação controlada de ataque, realizada por profissionais autorizados, com o objetivo de encontrar vulnerabilidades antes que um atacante real o faça.

Autorização é obrigatória

Testar a segurança de qualquer sistema sem autorização explícita e por escrito é crime, mesmo com boas intenções. Todo pentest profissional começa com um contrato de escopo formalmente assinado.

2. Tipos de Pentest por Conhecimento Prévio 📦

Tipo O que o pentester sabe
Black Box Nada — simula um atacante externo real
Gray Box Acesso parcial (ex: uma conta de usuário comum)
White Box Acesso total, incluindo código-fonte — mais profundo e rápido

3. As Fases Clássicas de um Pentest 🗺️

graph LR
    A[1. Reconhecimento] --> B[2. Varredura/Enumeração]
    B --> C[3. Exploração]
    C --> D[4. Pós-Exploração]
    D --> E[5. Relatório]
  1. Reconhecimento: coletar informações públicas sobre o alvo (OSINT).
  2. Varredura e Enumeração: mapear serviços, portas e versões ativas (Aula 10).
  3. Exploração: tentar efetivamente comprometer as vulnerabilidades encontradas (Aula 11).
  4. Pós-Exploração: avaliar até onde o acesso obtido permite ir (movimento lateral, escalonamento de privilégio).
  5. Relatório: o entregável mais importante — documentar achados, riscos e recomendações de correção.

4. Pentest x Red Team x Bug Bounty 🎭

Abordagem Escopo e Duração Foco
Pentest Escopo definido, prazo curto Encontrar o máximo de vulnerabilidades possível
Red Team Objetivo específico, sem avisar o time de defesa Testar a detecção e resposta real da equipe
Bug Bounty Contínuo, aberto a pesquisadores externos Recompensar quem encontrar vulnerabilidades

5. Ambientes Legais para Praticar 🏋️

Nunca pratique técnicas de ataque em sistemas que não são seus ou que você não tem autorização explícita para testar. Existem plataformas criadas especificamente para prática legal e ética:

  • TryHackMe e Hack The Box: laboratórios gamificados de segurança ofensiva.
  • DVWA (Damn Vulnerable Web Application): aplicação propositalmente vulnerável, para rodar localmente.
  • OWASP Juice Shop: aplicação de e-commerce fictícia, cheia de vulnerabilidades propositais para treino.

6. Mini-Projeto: Escopo de um Pentest Fictício 🚀

Você foi contratado para planejar (não executar) um pentest em uma aplicação web fictícia:

  1. Defina o tipo de teste (black/gray/white box) e justifique a escolha.
  2. Liste o que estaria dentro do escopo (ex: aplicação web em app.exemplo.com).
  3. Liste o que estaria fora do escopo (ex: engenharia social com funcionários, infraestrutura de terceiros).
  4. Redija 3 regras de "não fazer" que você incluiria no contrato (ex: não realizar ataques de negação de serviço).

7. Exercício de Fixação 🧠

  1. Por que testar segurança sem autorização é crime, mesmo com boas intenções?
  2. Qual a diferença entre Black Box e White Box pentest?
  3. Cite duas plataformas legais para praticar técnicas de segurança ofensiva.

Próxima Aula: Mapeando o alvo na prática: Scanners e Enumeração 🔍

Aula 10 - Scanners e Enumeração 🔍

Objetivo

Objetivo: Aprender técnicas e ferramentas de reconhecimento e varredura usadas para mapear a superfície de ataque de um sistema, sempre em ambiente autorizado e controlado.

1. Reconhecimento: Antes de Escanear 🔎

Antes de tocar tecnicamente no alvo, boa parte da informação já pode ser coletada publicamente — isso é chamado de OSINT (Open Source Intelligence).

  • Registros de domínio (whois).
  • Subdomínios expostos.
  • Tecnologias usadas (frameworks, versões de servidor).
  • Vazamentos de dados públicos associados ao domínio.

2. Varredura de Portas com Nmap 🗺️

O Nmap é a ferramenta de varredura de rede mais usada no mundo — permite descobrir hosts ativos, portas abertas e os serviços rodando em cada uma.

$ # Varredura basica de portas em um alvo autorizado (ex: sua propria maquina de laboratorio) $ nmap -sV 192.168.1.10 $ $ PORT STATE SERVICE VERSION $ 22/tcp open ssh OpenSSH 8.9 $ 80/tcp open http nginx 1.24.0 $ 443/tcp open https nginx 1.24.0

Só em ambiente autorizado

Rode o Nmap apenas contra máquinas suas ou de laboratórios de prática (Aula 09) — escanear IPs de terceiros sem autorização pode ser considerado atividade maliciosa, mesmo sem intenção de ataque.

3. O que a Enumeração Revela 📊

graph TD
    A[Varredura de Portas] --> B[Portas Abertas]
    B --> C[Serviços Identificados]
    C --> D[Versões de Software]
    D --> E[Vulnerabilidades Conhecidas para essa Versão]

Cada porta aberta e versão de software identificada é uma pista: se uma versão antiga de um serviço tem uma vulnerabilidade conhecida (CVE) publicada, ela se torna um alvo prioritário na fase de exploração (Aula 11).

4. Enumeração de Aplicações Web 🕸️

Além de portas de rede, aplicações web têm sua própria superfície de enumeração:

  • Diretórios e arquivos ocultos: ferramentas como dirb ou gobuster tentam descobrir caminhos não linkados publicamente.
  • Tecnologias do frontend/backend: extensões de navegador (Wappalyzer) ou cabeçalhos HTTP revelam frameworks usados.
  • Formulários e pontos de entrada: cada campo de input é uma superfície potencial de ataque (veremos em detalhe nas Aulas 12-13).

5. Bases de Vulnerabilidades Conhecidas 📚

Depois de identificar versões específicas de software, consulta-se bases públicas para saber se existem vulnerabilidades já catalogadas:

  • CVE (Common Vulnerabilities and Exposures): identificador padrão de vulnerabilidades conhecidas.
  • NVD (National Vulnerability Database): base de dados oficial dos EUA com detalhes técnicos e severidade.

6. Mini-Projeto: Relatório de Reconhecimento 🚀

Em um ambiente próprio (sua máquina local, uma VM de laboratório ou uma das plataformas legais da Aula 09):

  1. Rode uma varredura de portas com Nmap.
  2. Liste os serviços e versões encontrados.
  3. Para pelo menos 1 serviço identificado, pesquise se existe alguma CVE conhecida para aquela versão específica.
  4. Redija um mini-relatório: "o que foi encontrado" e "por que seria relevante em um pentest real".

7. Exercício de Fixação 🧠

  1. O que é OSINT e por que ele é uma etapa importante antes de qualquer varredura técnica?
  2. Por que a versão exata de um serviço (não só o nome) é importante para um pentester?
  3. O que é um CVE e onde você pode consultá-lo?

Próxima Aula: De vulnerabilidade encontrada a acesso obtido: Exploração Controlada 💥

Aula 11 - Exploração Controlada 💥

Objetivo

Objetivo: Entender como uma vulnerabilidade identificada na fase de enumeração se transforma em acesso real, de forma controlada e ética, e o papel de ferramentas como o Metasploit nesse processo.

1. Da Enumeração à Exploração 🔗

Na Aula 10, mapeamos serviços, versões e possíveis CVEs. A exploração é o passo de tentar efetivamente usar uma vulnerabilidade identificada para obter acesso não autorizado — sempre em ambiente de laboratório controlado.

graph LR
    A[Vulnerabilidade Identificada] --> B[Exploit Disponível?]
    B -- Sim --> C[Exploração Controlada]
    B -- Não --> D[Documentar risco teórico]
    C --> E[Acesso Obtido]
    E --> F[Pós-Exploração / Relatório]

2. O que é um Exploit? 🎯

Um exploit é um pedaço de código ou técnica que aproveita uma vulnerabilidade específica para causar um comportamento não intencional — de vazamento de informação até execução remota de código.

  • Exploits públicos: já documentados e disponíveis (ex: no Exploit-DB), geralmente para vulnerabilidades conhecidas (CVE) não corrigidas.
  • Exploits 0-day: exploram vulnerabilidades ainda desconhecidas do fabricante — extremamente valiosos e perigosos.

3. Frameworks de Exploração: Metasploit 🛠️

O Metasploit é o framework de exploração mais usado no mundo da segurança ofensiva, reunindo milhares de exploits organizados e prontos para uso em ambientes de laboratório.

$ # Exemplo conceitual de fluxo no Metasploit (msfconsole) $ msfconsole $ msf6 > search type:exploit name:eternalblue $ msf6 > use exploit/windows/smb/ms17_010_eternalblue $ msf6 > set RHOSTS 192.168.1.20 $ msf6 > exploit

Somente em laboratório próprio

Todos os exemplos desta aula devem ser praticados exclusivamente em máquinas virtuais de laboratório isoladas (ex: Metasploitable, DVWA) — nunca contra sistemas reais sem autorização por escrito.

4. Pós-Exploração: O Que Vem Depois do Acesso 🚪

Obter acesso inicial é só o começo de um pentest real. A fase de pós-exploração avalia o real impacto do comprometimento:

  1. Escalonamento de privilégio: transformar um acesso limitado em acesso administrativo.
  2. Movimento lateral: usar o sistema comprometido como ponte para atacar outros sistemas da mesma rede.
  3. Persistência: técnicas que um atacante real usaria para manter acesso — entender isso ajuda a saber o que procurar ao investigar um incidente.

5. Por Que Isso Importa Para Quem Desenvolve (Não Ataca) 👨‍💻

Você não precisa se tornar um pentester profissional para se beneficiar deste conhecimento: entender como uma vulnerabilidade é explorada na prática ajuda a priorizar corretamente o que corrigir primeiro no seu próprio código e infraestrutura.

6. Mini-Projeto: Analisando um CVE Público 🚀

  1. Escolha um CVE conhecido e antigo (ex: relacionado a alguma versão desatualizada de software popular).
  2. Pesquise: qual era a vulnerabilidade exata? Como ela era explorada?
  3. Qual seria o impacto real se ela fosse explorada com sucesso (confidencialidade, integridade ou disponibilidade — Aula 01)?
  4. Que correção (patch, configuração, boa prática) eliminaria essa vulnerabilidade?

7. Exercício de Fixação 🧠

  1. Qual a diferença entre um exploit público e um exploit 0-day?
  2. O que é "escalonamento de privilégio" na fase de pós-exploração?
  3. Por que entender exploração é útil mesmo para quem só desenvolve software, sem fazer pentest profissionalmente?

Próxima Aula: Fim do Módulo 3! Hora de proteger aplicações web: OWASP Top 10 🔟

Módulo 4 – Segurança Web

Aula 12 - OWASP Top 10 🔟

Objetivo

Objetivo: Conhecer as 10 categorias de vulnerabilidades web mais críticas do mundo, catalogadas pela OWASP, com foco especial em Injection e Broken Access Control — as mais exploradas na prática.

1. O que é a OWASP? 🏛️

A OWASP (Open Worldwide Application Security Project) é uma organização sem fins lucrativos que mantém, entre outros recursos, uma lista atualizada periodicamente das vulnerabilidades web mais críticas — referência obrigatória para qualquer desenvolvedor.

2. As Categorias do OWASP Top 10 📊

# Categoria O que é
1 Broken Access Control Falhas que permitem acessar recursos sem permissão adequada
2 Cryptographic Failures Uso incorreto ou ausência de criptografia em dados sensíveis
3 Injection Inserir código malicioso via entrada do usuário (SQL, comandos, etc.)
4 Insecure Design Falhas de segurança na arquitetura, não só na implementação
5 Security Misconfiguration Configurações padrão inseguras, permissões excessivas
6 Vulnerable Components Usar bibliotecas/dependências desatualizadas com falhas conhecidas
7 Auth Failures Falhas em autenticação e gerenciamento de sessão
8 Software/Data Integrity Failures Confiar em atualizações/dados sem verificar integridade
9 Logging Failures Falta de logs adequados para detectar e investigar ataques
10 SSRF Servidor é enganado para fazer requisições a locais não autorizados

3. Foco Prático: SQL Injection 💉

A vulnerabilidade mais didática e ainda muito comum. Acontece quando a entrada do usuário é concatenada diretamente em uma consulta SQL.

# ❌ VULNERÁVEL - concatenação direta
query = f"SELECT * FROM usuarios WHERE nome = '{nome_usuario}'"
# Se nome_usuario for: ' OR '1'='1
# A query vira: SELECT * FROM usuarios WHERE nome = '' OR '1'='1'
# Isso retorna TODOS os usuários!

# ✅ SEGURO - consulta parametrizada (prepared statement)
cursor.execute("SELECT * FROM usuarios WHERE nome = %s", (nome_usuario,))

graph TD
    A[Entrada do usuário] --> B{Concatenada direto na query?}
    B -- Sim --> C[❌ SQL Injection possível]
    B -- Não, usa prepared statement --> D[✅ Entrada tratada como dado, nunca como código]

4. Foco Prático: Broken Access Control 🚪

A categoria número 1 do OWASP na prática mais recente. Acontece quando o sistema não verifica corretamente se o usuário logado tem permissão para acessar um recurso específico.

  • IDOR (Insecure Direct Object Reference): mudar /pedidos/123 para /pedidos/124 e conseguir ver o pedido de outra pessoa, porque o backend nunca verificou se aquele pedido pertence ao usuário logado.

Autenticado ≠ Autorizado

Só porque um usuário está logado, não significa que ele deve poder acessar qualquer recurso do sistema — cada endpoint precisa verificar explicitamente a permissão (Aula 07).

5. Mini-Projeto: Caça-Vulnerabilidades 🚀

  1. Encontre (ou peça) um trecho de código com uma consulta SQL montada por concatenação de strings.
  2. Identifique a vulnerabilidade e explique como ela seria explorada.
  3. Reescreva o código de forma segura, usando prepared statements.
  4. Repita o exercício com um endpoint que busca um recurso por ID sem checar se ele pertence ao usuário logado (IDOR).

6. Exercício de Fixação 🧠

  1. O que significa a sigla OWASP e qual o objetivo do OWASP Top 10?
  2. Explique com suas palavras como funciona um ataque de SQL Injection.
  3. O que é um ataque IDOR e por que ele se encaixa na categoria "Broken Access Control"?

Próxima Aula: Como se defender do OWASP Top 10 na prática: Proteções para Aplicações Web 🛡️

Aula 13 - Proteções para Aplicações Web 🛡️

Objetivo

Objetivo: Aprender as defesas práticas contra XSS, CSRF e outras vulnerabilidades comuns, e conhecer os cabeçalhos HTTP de segurança que toda aplicação web moderna deveria usar.

1. XSS (Cross-Site Scripting): a Defesa 🖼️

Ocorre quando dados fornecidos pelo usuário são exibidos na página sem escapar caracteres especiais de HTML, permitindo injetar scripts.

<!-- Comentário de usuário exibido sem tratamento -->
<div>Comentário: <script>roubarCookies()</script></div>

Regra de ouro contra XSS

Nunca confie em dados do usuário. Sempre escape (ou use frameworks que escapam automaticamente, como React/Vue) qualquer conteúdo dinâmico antes de renderizá-lo como HTML.

2. CSRF (Cross-Site Request Forgery) 🎭

Um ataque que engana o navegador da vítima para que ele envie uma requisição indesejada a um site onde ela já está autenticada — sem que ela perceba.

Defesas principais: 1. Token CSRF: um valor único, verificado a cada requisição que altera dados. 2. Cookies SameSite: impedem que o cookie de sessão seja enviado em requisições vindas de outros domínios.

3. Cabeçalhos HTTP de Segurança 📋

Cabeçalho O que faz
Content-Security-Policy Restringe de onde scripts/estilos podem ser carregados, mitigando XSS
X-Content-Type-Options: nosniff Impede o navegador de "adivinhar" o tipo de arquivo, evitando alguns ataques
X-Frame-Options: DENY Impede que o site seja carregado dentro de um <iframe> (proteção contra clickjacking)
Strict-Transport-Security Força o navegador a sempre usar HTTPS para aquele domínio
$ # Verificando os cabecalhos de seguranca de uma aplicacao $ curl -sI https://example.com | grep -Ei "x-content-type|x-frame|content-security" $ X-Content-Type-Options: nosniff $ X-Frame-Options: DENY $ Content-Security-Policy: default-src 'self'

4. Segurança em Dependências 📦

Boa parte das vulnerabilidades reais não está no código próprio — está nas bibliotecas de terceiros usadas pelo projeto (categoria "Vulnerable Components" do OWASP Top 10).

$ pip install pip-audit $ pip-audit $ Found 2 known vulnerabilities in 1 package

Ferramentas como pip-audit, npm audit e o Dependabot do GitHub automatizam essa verificação continuamente.

5. Validação de Entrada: a Primeira Linha de Defesa 🚧

A maioria das vulnerabilidades deste módulo (SQL Injection, XSS, e outras) compartilha uma raiz comum: confiar em dados do usuário sem validar. Validar tipo, tamanho e formato de toda entrada, no backend (nunca só no frontend), é a defesa mais barata e eficaz.

6. Mini-Projeto: Auditoria de Cabeçalhos 🚀

  1. Escolha 3 sites que você usa no dia a dia.
  2. Para cada um, rode curl -sI <site> e verifique quais cabeçalhos de segurança da tabela da seção 3 estão presentes.
  3. Monte uma tabela comparativa: qual site está mais bem protegido?
  4. Para o site com menos cabeçalhos, sugira quais ele deveria adicionar.

7. Exercício de Fixação 🧠

  1. Explique com suas palavras como funciona um ataque CSRF.
  2. Para que serve o cabeçalho Content-Security-Policy?
  3. Por que dependências desatualizadas são consideradas um risco, mesmo que seu código próprio esteja correto?

Próxima Aula: Fim do Módulo 4! A segurança encontra a legislação: LGPD e Privacidade 📜

Módulo 5 – Ética e Legislação

Aula 14 - LGPD e Privacidade 📜

Objetivo

Objetivo: Entender os princípios da LGPD, os direitos do titular de dados, e como as decisões técnicas de segurança que você já aprendeu neste curso ajudam a cumprir a lei na prática.

1. O que é a LGPD? 📋

A LGPD (Lei Geral de Proteção de Dados, Lei nº 13.709/2018) regula como empresas e organizações no Brasil podem coletar, armazenar, processar e compartilhar dados pessoais — fortemente inspirada no GDPR europeu.

2. Dado Pessoal x Dado Sensível 🧑

Categoria Definição Exemplos
Dado Pessoal Qualquer informação que identifique uma pessoa Nome, e-mail, CPF, IP
Dado Pessoal Sensível Categoria com proteção reforçada Origem racial, religião, saúde, dados biométricos

3. Os Princípios da LGPD ⚖️

graph TD
    A[Princípios da LGPD] --> B[Finalidade: coleta com propósito específico]
    A --> C[Necessidade: coletar só o mínimo]
    A --> D[Transparência: informar claramente o uso]
    A --> E[Segurança: proteger tecnicamente os dados]

4. Direitos do Titular dos Dados 🙋

  1. Confirmação e acesso: saber se uma empresa tem seus dados e quais são.
  2. Correção: corrigir dados incompletos ou desatualizados.
  3. Eliminação: solicitar exclusão de dados desnecessários.
  4. Portabilidade: transferir os dados para outro fornecedor.
  5. Revogação do consentimento: retirar a autorização a qualquer momento.

5. Onde a Segurança Técnica se Encontra com a LGPD 🔗

Tudo que você viu nos módulos anteriores deste curso é, na prática, exigência legal:

Exigência da LGPD Técnica correspondente (já vista no curso)
Proteger dados contra acesso não autorizado Firewall, IDS/IPS (Aula 05), Criptografia (Aula 06)
Controlar quem acessa o quê Autenticação, RBAC (Aula 07)
Comunicação segura entre sistemas TLS/HTTPS (Aula 08)
Prevenir vazamentos por vulnerabilidades OWASP Top 10 (Aulas 12-13)

Vazamento de dados = Multa

Empresas que sofrem vazamentos por negligência de segurança estão sujeitas a multas de até 2% do faturamento, limitadas a R$ 50 milhões por infração — além do dano à reputação.

6. O Papel do DPO 👤

O DPO (Data Protection Officer, ou Encarregado de Dados) é a pessoa formalmente responsável por garantir a conformidade de uma empresa com a LGPD — o ponto de contato entre a organização, os titulares de dados e a autoridade regulatória (ANPD).

7. Mini-Projeto: Auditoria de Privacidade 🚀

  1. Escolha um app ou site popular e localize sua política de privacidade.
  2. Identifique: quais dados são coletados? Para qual finalidade? Por quanto tempo são retidos?
  3. Verifique se existe uma opção clara para solicitar exclusão da conta e dos dados.
  4. Escreva um parecer curto avaliando se a política atende aos princípios estudados.

8. Exercício de Fixação 🧠

  1. Qual a diferença entre dado pessoal e dado pessoal sensível?
  2. Cite 3 direitos garantidos ao titular de dados pela LGPD.
  3. Como a criptografia (Aula 06) ajuda uma empresa a cumprir a LGPD mesmo em caso de vazamento?

Próxima Aula: Ética, carreira e o que vem depois: Cultura Hacker (Ética e Carreira) 🎩

Aula 15 - Cultura Hacker (Ética e Carreira) 🎩

Objetivo

Objetivo: Entender a diferença entre os "chapéus" da cultura hacker, os limites éticos e legais da profissão, e conhecer as principais trilhas de carreira em segurança da informação.

1. Hacker Não é Sinônimo de Criminoso 🧢

O termo "hacker" originalmente descreve alguém com profundo conhecimento técnico e curiosidade por entender como sistemas funcionam — não necessariamente alguém malicioso. A cultura de segurança usa "chapéus" (hats) para diferenciar intenções:

Chapéu Descrição
White Hat Age dentro da lei e com autorização, para proteger sistemas (pentesters profissionais)
Black Hat Age sem autorização, com intenção maliciosa (criminosos)
Gray Hat Encontra vulnerabilidades sem autorização, mas sem intenção maliciosa — ainda assim, ilegal na maioria das jurisdições

2. Divulgação Responsável (Responsible Disclosure) 📢

Quando um pesquisador encontra uma vulnerabilidade em um sistema de terceiros, o procedimento ético e mais aceito é:

graph LR
    A[Vulnerabilidade encontrada] --> B[Reportar diretamente à empresa/programa de Bug Bounty]
    B --> C[Empresa corrige a falha]
    C --> D[Divulgação pública coordenada, após a correção]

Publicar uma vulnerabilidade sem antes reportá-la à empresa responsável ("full disclosure" sem aviso prévio) expõe usuários reais a risco antes que exista correção.

3. Certificações da Área 🎓

Certificação Foco
CompTIA Security+ Fundamentos de segurança, boa porta de entrada
CEH (Certified Ethical Hacker) Introdução formal a técnicas ofensivas
OSCP (Offensive Security Certified Professional) Altamente prática e respeitada, foco em pentest real
CISSP Voltada para gestão e arquitetura de segurança, mais sênior

4. Trilhas de Carreira em Segurança 🛤️

  • AppSec (Application Security): foco em segurança de código e SDLC — conecta diretamente com desenvolvimento.
  • Pentester / Red Team: segurança ofensiva, simular ataques.
  • Blue Team / SOC Analyst: segurança defensiva, monitoramento e resposta a incidentes.
  • GRC (Governance, Risk & Compliance): políticas, conformidade legal (LGPD, ISO 27001), auditoria.

5. Comunidade e Aprendizado Contínuo 🌍

Segurança é uma das áreas de tecnologia que mais muda — novas vulnerabilidades e técnicas surgem constantemente. Participar de comunidades (CTFs, conferências como DEF CON e H2HC, fóruns) é parte essencial da profissão, não opcional.

6. Mini-Projeto: Meu Plano de Carreira em Segurança 🚀

  1. Pesquise as 4 trilhas de carreira da seção 4 e escolha a que mais te interessa.
  2. Liste 2 certificações relevantes para essa trilha.
  3. Pesquise uma competição de CTF (Capture The Flag) iniciante e descreva como ela funciona.
  4. Escreva 3 próximos passos concretos que você tomaria para começar essa trilha.

7. Exercício de Fixação 🧠

  1. Qual a diferença entre White Hat, Black Hat e Gray Hat?
  2. Explique o processo de "divulgação responsável" de uma vulnerabilidade.
  3. Cite uma trilha de carreira em segurança e explique brevemente seu foco.

Próxima Aula: Fim do Módulo 5! Hora de consolidar tudo: Projeto Integrador 🏆

Módulo 6 – Projeto Final

Aula 16 - Projeto Integrador 🏆

Objetivo

Objetivo: Consolidar tudo o que foi aprendido no curso realizando uma auditoria de segurança completa em uma aplicação real, aplicando os conceitos de todos os 5 módulos.

1. O Desafio Final: Auditoria de Segurança Completa 🔍

Escolha uma aplicação web real (sua ou de um colega, com autorização) ou uma das plataformas legais de prática (DVWA, OWASP Juice Shop — Aula 09) e conduza uma auditoria de segurança estruturada.

2. Etapas Obrigatórias da Auditoria 📋

O relatório final deve conter, obrigatoriamente:

  • Análise de Riscos (Aula 04): matriz de probabilidade x impacto com pelo menos 5 riscos identificados.
  • Reconhecimento e Enumeração (Aula 10): varredura de portas/serviços (só em ambiente autorizado).
  • Checklist OWASP Top 10 (Aulas 12-13): verificação de pelo menos 4 categorias (ex: Injection, Broken Access Control, Security Misconfiguration, Vulnerable Components).
  • Configuração de Rede (Aula 08): versão de TLS suportada e cabeçalhos de segurança presentes.
  • Autenticação (Aula 07): como as senhas são armazenadas? Existe MFA disponível?
  • Conformidade com LGPD (Aula 14): a política de privacidade é clara? Existe opção de exclusão de dados?

3. Estrutura do Relatório Final 📄

graph TD
    A[1. Resumo Executivo] --> B[2. Escopo e Metodologia]
    B --> C[3. Achados por Categoria]
    C --> D[4. Classificação de Risco de cada Achado]
    D --> E[5. Recomendações de Correção]
    E --> F[6. Conclusão]

Um relatório profissional de segurança sempre prioriza os achados por risco (Aula 04) — vulnerabilidades críticas primeiro, cosméticas por último.

4. Exemplo de Formato de Achado 📝

Para cada vulnerabilidade encontrada, documente:

### Achado: [Nome da vulnerabilidade]
**Categoria OWASP**: [ex: A03 - Injection]
**Severidade**: Crítica / Alta / Média / Baixa
**Descrição**: O que foi encontrado e onde.
**Impacto**: O que um atacante conseguiria fazer explorando isso.
**Recomendação**: Como corrigir.

5. Checklist de Entrega ✅

  • Análise de riscos com matriz preenchida
  • Pelo menos 4 categorias do OWASP Top 10 verificadas
  • Configuração de rede/TLS documentada
  • Avaliação de autenticação e armazenamento de senhas
  • Avaliação de conformidade com LGPD
  • Relatório final com achados priorizados por severidade

🎨 Conclusão do Curso

Você percorreu uma jornada completa em Desenvolvimento Seguro — dos fundamentos da tríade CID até a condução de uma auditoria de segurança real. Agora você sabe:

  • Pensar como defensor: análise de riscos, PSI, e mecanismos de defesa em camadas.
  • A criptografia por trás da proteção de dados: simétrica, assimétrica, hash e assinatura digital.
  • Pensar como atacante, de forma ética: pentest, enumeração e exploração controlada em ambiente autorizado.
  • Proteger aplicações web reais: OWASP Top 10 e as defesas práticas contra cada categoria.
  • Navegar a legislação: LGPD e o papel da segurança técnica no cumprimento da lei.

Segurança não é um destino, é um processo contínuo — continue praticando em ambientes legais, mantenha-se atualizado, e leve esses princípios para todo sistema que você construir daqui em diante! 🛡️

Aula 17 - Análise Estática (SAST) e Dinâmica (DAST) de Código 🔍

Objetivo Pedagógico

Objetivo: Estruturar pipelines automatizados de segurança integrando Análise Estática de Segurança de Aplicações (SAST) com Semgrep/SonarQube e Análise Dinâmica (DAST) com OWASP ZAP, compreendendo suas forças e limitações complementares.

📑 1. Fundamentos Teóricos & Análise Técnica

No paradigma DevSecOps, a segurança deixa de ser uma auditoria tardia que precede a entrada em produção e passa a ser integrada continuamente no ciclo de desenvolvimento (Shift-Left Security).

A detecção de vulnerabilidades apoia-se em duas metodologias complementares de análise: 1. Static Application Security Testing (SAST - Caixa Branca): - Inspeciona diretamente o código-fonte, árvores de sintaxe abstrata (AST) e fluxos de dados (Taint Analysis) sem a necessidade de executar a aplicação. - Vantagens: Identifica a linha exata da vulnerabilidade (ex: injeção SQL, segredos expostos, deserialização insegura) nos estágios iniciais de codificação. - Limitações: Não tem visibilidade sobre vulnerabilidades de ambiente de execução, configurações de servidor ou autenticação dinâmica; suscetível a taxas de falsos positivos.

  1. Dynamic Application Security Testing (DAST - Caixa Preta):
  2. Avalia a aplicação em execução a partir de uma perspectiva externa de ataque, enviando requisições maliciosas contra endpoints HTTP/REST.
  3. Vantagens: Valida se uma vulnerabilidade teórica é de fato explorável no ambiente real considerando middlewares, WAF e configurações de infraestrutura; taxa de falsos positivos extremamente baixa.
  4. Limitações: Não aponta a linha do código-fonte onde a correção deve ser aplicada; depende da cobertura dos crawlers para descobrir todas as rotas e estados de autenticação.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Code["Código-Fonte (Git Push)"] --> SAST["SAST (Semgrep / Sonar): Varredura de AST & Taint Flow"]
    SAST --> SASTReport["Relatório de Código: Linha X vulnerável a SQLi"]
    Code --> Build["Build & Container Deploy (Staging)"]
    Build --> DAST["DAST (OWASP ZAP): Ataques Ativos & Fuzzing HTTP"]
    DAST --> DASTReport["Relatório de Runtime: Endpoint /api vulnerável a XSS"]
    SASTReport & DASTReport --> Triage["Triagem Automatizada e Quality Gate"]
    Triage --> Decision{"Vulnerabilidade Crítica Encontrada?"}
    Decision -- Sim --> Block["Quebra Pipeline de CI/CD"]
    Decision -- Não --> Prod["Libera Deploy Seguro"]
    style Code fill:#e1f5fe,stroke:#01579b
    style SAST fill:#fff3e0,stroke:#e65100
    style DAST fill:#f3e5f5,stroke:#7b1fa2
    style Block fill:#ffebee,stroke:#c62828
    style Prod fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Taint Analysis (Análise de Mancha): Rastreamento do fluxo de dados não confiáveis provenientes de entradas de usuário (Sources) até pontos críticos de execução (Sinks). - Software Bill of Materials (SBOM): Inventário sistemático de componentes de terceiros gerado para análise de composição de software (SCA). - DAST Baseado em Contexto de Autenticação: Configuração de tokens JWT e sessões automatizadas para garantir que o scanner DAST acesse áreas restritas da aplicação. - Zero-Vulnerability Tolerance Gates: Regras corporativas de conformidade que barram builds com vulnerabilidades CVSS score superior a 7.0 (High/Critical).

🛠️ 2. Implementação Prática em Segurança de Aplicações (AppSec), SAST e DAST

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// semgrep_rule_sqli.yml (Regra Declarativa Semgrep para Bloqueio de SQL Injection)
rules:
  - id: python-sqli-raw-format
    languages: [python]
    severity: ERROR
    message: "Possível SQL Injection detectado: interpolação de strings em consultas de banco de dados!"
    metadata:
      cwe: "CWE-89: Improper Neutralization of Special Elements used in an SQL Command"
      owasp: "A03:2021 - Injection"
    patterns:
      - pattern-either:
          - pattern: $CURSOR.execute(f"SELECT ... {$VAR} ...")
          - pattern: $CURSOR.execute("SELECT ... %s ..." % $VAR)
          - pattern: $CURSOR.execute("SELECT ... {}".format($VAR))
      - pattern-not: $CURSOR.execute("SELECT ...", (...))
    fix: $CURSOR.execute("SELECT ... WHERE id = %s", ($VAR,))

💡 Análise Passo a Passo do Código

  1. Casamento Estrutural via AST: Identifica padrões de risco independentemente de quebras de linha ou espaçamento cosmético no código Python.
  2. Filtro Negativo (pattern-not): Previne falsos positivos ignorando chamadas que utilizam parâmetros tipados (Prepared Statements).
  3. Sugestão de Correção Automática (fix): Permite que ferramentas de correção automática sugiram patches seguros diretamente no Pull Request do desenvolvedor.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Mitigação de Vulnerabilidades OWASP Top 10 🛡️

Objetivo Pedagógico

Objetivo: Compreender os mecanismos de exploração e implementar contramedidas rigorosas contra as ameaças mais críticas do OWASP Top 10: Broken Access Control, Injection, Insecure Design e Security Misconfiguration.

📑 1. Fundamentos Teóricos & Análise Técnica

O consórcio OWASP (Open Worldwide Application Security Project) categoriza as ameaças de segurança mais prevalentes em aplicações web modernas.

A mitigação técnica eficaz exige o abandono de soluções paliativas em favor de padrões arquiteturais consolidados: 1. A01: Broken Access Control (Controle de Acesso Quebrado): - Tornou-se a vulnerabilidade número 1 do ranking global. Ocorre quando a aplicação falha em impor o princípio do privilégio mínimo, permitindo que usuários visualizem ou alterem recursos de outros inquilinos (IDOR - Insecure Direct Object Reference). - Mitigação: Controle de Acesso Baseado em Atributos (ABAC) ou Políticas (PBAC), validando a relação de posse do recurso diretamente na camada de domínio de negócio em cada requisição. 2. A03: Injection (Injeções): - Dados não confiáveis são enviados a um interpretador como parte de um comando ou consulta (SQL, NoSQL, LDAP, OS Command). - Mitigação: Uso exclusivo de consultas parametrizadas (Prepared Statements), Object-Relational Mappers (ORMs) seguros com tipagem estrita e validação de esquemas de entrada com listas de permissão (Allowlists). 3. A05: Security Misconfiguration (Configurações Incorretas de Segurança): - Headers HTTP de proteção ausentes, portas desnecessárias abertas, contas com senhas padrão e mensagens de erro contendo stack traces detalhados que expõem versões internas do sistema. - Mitigação: Implementação compulsória de cabeçalhos de segurança defensivos: Content-Security-Policy (CSP), Strict-Transport-Security (HSTS), X-Content-Type-Options: nosniff e bloqueio de CORS permissivo (Access-Control-Allow-Origin: *).

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Attacker["Atacante Injeta '../' ou 'OR 1=1'"] --> Middleware["Filtro de Entrada & Validador de Schema (Zod / Pydantic)"]
    Middleware --> AuthZ["Validação de Autorização Fina (ABAC / PBAC)"]
    AuthZ --> Engine["Repositório com Consultas Parametrizadas"]
    Engine --> DB["Banco de Dados Relacional Protegido"]
    Engine --> Response["Sanitização de Saída & Headers HTTP Seguros"]
    Response --> Browser["Navegador Seguro (Bloqueia Scripts Maliciosos via CSP)"]
    style Attacker fill:#ffebee,stroke:#c62828
    style Middleware fill:#fff3e0,stroke:#e65100
    style AuthZ fill:#e1f5fe,stroke:#01579b
    style DB fill:#e8f5e9,stroke:#2e7d32
    style Browser fill:#f3e5f5,stroke:#7b1fa2

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Princípio do Menor Privilégio: Cada processo, serviço e usuário deve possuir apenas os privilégios mínimos necessários para a execução de sua tarefa. - Defesa em Profundidade (Defense in Depth): Múltiplas camadas de proteção independentes: se o WAF falhar, a validação de entrada barra; se esta falhar, o Prepared Statement impede o ataque. - Política CSP Rigorosa (Content-Security-Policy): Restringe os domínios a partir dos quais scripts, fontes e conexões de rede podem ser carregados no navegador. - Tratamento Seguro de Exceções: Logging detalhado em ambiente interno e retorno de mensagens amigáveis e genéricas para o cliente externo.

🛠️ 2. Implementação Prática em Segurança Defensiva, OWASP Top 10 e Sanitização

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// secure_endpoints.ts (Proteção Contra IDOR e Configuração de Segurança em Node/Express)
import express, { Request, Response, NextFunction } from 'express';
import helmet from 'helmet';

const app = express();

// 1. Defesa em Profundidade: Headers HTTP Hardened com Helmet
app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'"],
      objectSrc: ["'none'"],
      upgradeInsecureRequests: [],
    },
  },
  crossOriginEmbedderPolicy: true,
}));

interface AuthenticatedUser {
  id: string;
  tenantId: string;
}

// 2. Mitigação de Broken Access Control (Anti-IDOR)
app.get('/api/v1/invoices/:invoiceId', async (req: Request, res: Response) => {
  const user = req.user as AuthenticatedUser;
  const { invoiceId } = req.params;

  // Consulta que amarra estritamente o recurso ao dono autenticado
  const invoice = await db.invoice.findFirst({
    where: {
      id: invoiceId,
      tenantId: user.tenantId, // Bloqueia acesso cruzado entre inquilinos!
    },
  });

  if (!invoice) {
    // Retorna 404 para não vazar a existência do recurso a atacantes
    return res.status(404).json({ error: 'Recurso não encontrado' });
  }

  return res.json(invoice);
});

💡 Análise Passo a Passo do Código

  1. Uso de Middleware Helmet: Aplica automaticamente mais de 10 cabeçalhos de proteção moderna HTTP eliminando configurações incorretas.
  2. Prevenção Estrita de IDOR: Inclui compulsóriamente a chave tenantId nas cláusulas de busca do banco de dados.
  3. Resposta 404 Uniforme: Evita vazamento de enumeração de dados sensíveis (Information Disclosure).

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Gestão Segura de Segredos e Certificados em CI/CD 🔑

Objetivo Pedagógico

Objetivo: Eliminar credenciais estáticas de longa duração em pipelines de CI/CD utilizando autenticação sem segredos via OpenID Connect (OIDC), HashiCorp Vault e rotação dinâmica de segredos.

📑 1. Fundamentos Teóricos & Análise Técnica

Um dos vetores de ataque mais recorrentes contra a cadeia de suprimentos de software é o vazamento de chaves de API estáticas e credenciais de nuvem gravadas em variáveis de ambiente de CI/CD.

A segurança moderna de infraestrutura aboliu credenciais persistentes em favor de Identidades Criptográficas Efêmeras: 1. O Problema das Long-Lived Credentials: - Chaves de acesso AWS IAM ou Service Account Keys do GCP armazenadas como segredos de repositório têm prazo indeterminado. Se um pipeline for comprometido ou um log vazar a variável, o atacante adquire persistência silenciosa. 2. OpenID Connect (OIDC) Federado e Zero-Secret CI/CD: - O runner de CI (ex: GitHub Actions) atua como um provedor de identidade (IdP) emitindo um token JWT assinado criptograficamente contendo claims verificáveis (repositório, branch, commit SHA). - O provedor de nuvem (AWS, Azure, GCP ou HashiCorp Vault) valida a assinatura do token OIDC diretamente com o IdP e concede credenciais temporárias de curto prazo (válidas por 15 a 60 minutos) com permissões restritas. 3. HashiCorp Vault e Segredos Dinâmicos: - Em vez de compartilhar uma senha fixa de banco de dados entre dezenas de microsserviços, a aplicação autentica-se no Vault, que provisiona na hora um usuário único no banco de dados com Time-to-Live (TTL) limitado, revogando o acesso automaticamente ao expirar o tempo.

📐 Arquitetura Conceitual & Diagrama de Fluxo

sequenceDiagram
    autonumber
    participant Runner as GitHub Actions Runner
    participant IdP as GitHub OIDC Provider
    participant AWS as AWS STS (AssumeRoleWithWebIdentity)
    participant Cloud as Recursos Cloud (S3, EKS, RDS)
    Runner->>IdP: Solicita OIDC Token JWT
    IdP-->>Runner: JWT Assinado (Audience, Repository, Ref)
    Runner->>AWS: Envia JWT e solicita AssumeRole
    AWS->>IdP: Valida chave pública e claims da organização
    AWS-->>Runner: Credenciais Temporárias STS (Válidas por 15min)
    Runner->>Cloud: Executa deploy com segurança zero-secret!
    Note over Runner,Cloud: Credenciais expiram automaticamente; zero segredo estático mantido!

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Eliminação de Segredos Estáticos: Nenhuma credencial permanente de nuvem reside armazenada em configurações de CI/CD. - Claims-Based Access Control: Políticas IAM que concedem permissão de deploy apenas se o commit pertencer à branch main da organização oficial. - Auditoria Centralizada de Acessos: Cada requisição gera logs unificados rastreando a autoria exata do job de pipeline até o commit. - Time-To-Live (TTL) Curto: Janela de exposição reduzida para minutos em caso improvável de interceptação de token.

🛠️ 2. Implementação Prática em Gestão de Segredos, HashiCorp Vault e OIDC

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// oidc_cloud_deploy.yml (Pipeline GitHub Actions sem Segredos com AWS OIDC)
name: Cloud Deploy via OIDC

on:
  push:
    branches: [main]

permissions:
  id-token: write # Permissão obrigatória para requisitar o token JWT OIDC
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Autenticação Segura via OIDC (Zero Chaves Estáticas!)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsWorkloadDeployRole
          aws-region: us-east-1
          audience: https://github.com/organizacao-oficial

      - name: Deploy em Infraestrutura Protegida
        run: |
          echo "Executando sincronização segura com credenciais temporárias do STS:"
          aws sts get-caller-identity
          aws s3 sync ./dist s3://portal-producao-bucket --delete

💡 Análise Passo a Passo do Código

  1. Diretiva id-token: write: Autoriza o runner a solicitar tokens OIDC federados de curto prazo ao servidor do GitHub.
  2. Role-to-Assume Declarativa: Associa o job a uma IAM Role previamente configurada para confiar apenas no repositório corporativo específico.
  3. Zero Segredos em Settings: Elimina a necessidade de manter AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY no painel de configurações.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀

Objetivo Pedagógico

Objetivo: Engenhar um pipeline DevSecOps integralmente blindado (Hardened): verificação de dependências (SCA), SAST com Semgrep, auditoria de imagens Docker com Trivy, geração de SBOM e assinatura criptográfica de artefatos com Sigstore Cosign atendendo aos níveis de conformidade SLSA.

📑 1. Fundamentos Teóricos & Análise Técnica

A segurança contemporânea da cadeia de suprimentos de software exige aderência a frameworks formais como o SLSA (Supply-chain Levels for Software Artifacts).

O Projeto Capstone de Desenvolvimento Seguro consolida uma esteira industrial de integridade de software: 1. Verificação de Proveniência e SLSA: - Garantir que o artefato binário ou contêiner foi comprovadamente gerado a partir do código-fonte auditado, dentro de um ambiente de compilação confiável e isolado, impedindo a injeção de binários adulterados por terceiros. 2. Varredura Completa de Contêineres com Trivy: - Auditoria não apenas das dependências de aplicação (npm, pip, go modules), mas de todas as camadas do sistema operacional do contêiner (pacotes debian/alpine, bibliotecas compartilhadas C, CVEs de kernel). 3. Software Bill of Materials (SBOM) Padronizado: - Geração automática de inventários em formato SPDX ou CycloneDX, permitindo consulta imediata de impacto caso novas vulnerabilidades zero-day (ex: Log4Shell) surjam na indústria. 4. Assinatura e Verificação Criptográfica com Sigstore Cosign: - As imagens de contêiner geradas pelo build são assinadas digitalmente com chaves transitórias no registry corporativo. - O cluster de produção (Kubernetes) utiliza controladores de admissão (ex: Kyverno) para rejeitar compulsóriamente qualquer imagem que não possua a assinatura válida do pipeline oficial de DevSecOps.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Commit["Commit Assinado no Git"] --> SCA["SCA: Varredura de Dependências"]
    SCA --> SAST["SAST: Análise de Código e Segredos"]
    SAST --> Build["Build Seguro em Runner Isolado"]
    Build --> Scan["Trivy: Scanner de Vulnerabilidades da Imagem"]
    Scan --> SBOM["Geração de SBOM (CycloneDX / SPDX)"]
    SBOM --> Sign["Sigstore Cosign: Assinatura Criptográfica da Imagem"]
    Sign --> Registry["Push para Container Registry Corporativo"]
    Registry --> K8s["Kubernetes Admission Controller (Kyverno)"]
    K8s --> Deploy{"Assinatura Válida?"}
    Deploy -- Sim --> Pod["Execução do Pod em Produção"]
    Deploy -- Não --> Rejection["Bloqueio Imediato do Pod"]
    style Commit fill:#e1f5fe,stroke:#01579b
    style Scan fill:#fff3e0,stroke:#e65100
    style Sign fill:#f3e5f5,stroke:#7b1fa2
    style Pod fill:#e8f5e9,stroke:#2e7d32
    style Rejection fill:#ffebee,stroke:#c62828

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Assinatura Keyless com Sigstore: Uso de identidades OpenID Connect e transparência criptográfica pública (Rekor) para assinar contêineres sem gestão de chaves privadas locais. - Controle de Admissão em Runtime: Garantia de que contêineres não assinados ou com vulnerabilidades críticas sejam fisicamente impedidos de subir em produção. - Auditoria de Base Images Mínimas: Uso de imagens base distroless ou scratch sem shells interativos para reduzir drasticamente a superfície de ataque. - Conformidade SLSA Level 3: Prevenção de ataques de substituição de dependências e ataques de homem-no-meio no processo de compilação.

🛠️ 2. Implementação Prática em Engenharia de DevSecOps, SLSA Framework e Assinatura Cosign

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// devsecops_hardened_capstone.yml (Pipeline DevSecOps Completo com Trivy, SBOM e Cosign)
name: Hardened DevSecOps Pipeline

on:
  push:
    branches: [main]

permissions:
  contents: read
  packages: write
  id-token: write

jobs:
  security-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Análise Estática de Segurança (Semgrep)
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/owasp-top-ten

      - name: Build do Contêiner
        run: |
          docker build -t ghcr.io/${{ github.repository }}:latest .

      - name: Varredura de Imagem e Sistema Operacional com Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ghcr.io/${{ github.repository }}:latest
          format: 'table'
          exit-code: '1' # Quebra o build se houver vulnerabilidade CRITICAL
          ignore-unfixed: true
          severity: 'CRITICAL'

      - name: Instalar Sigstore Cosign
        uses: sigstore/cosign-installer@v3.5.0

      - name: Assinar Imagem Criptograficamente (Keyless Signing)
        run: |
          echo "Assinando imagem com identidade OIDC do pipeline..."
          cosign sign --yes ghcr.io/${{ github.repository }}:latest

💡 Análise Passo a Passo do Código

  1. Qualificação com Semgrep: Interrompe o fluxo caso vulnerabilidades arquiteturais de código sejam detectadas.
  2. Trivy com exit-code: 1: Impõe barreira absoluta contra publicação de contêineres contendo vulnerabilidades críticas não corrigidas.
  3. Assinatura com Cosign: Garante rastreabilidade matemática de proveniência para validação em runtime por admission controllers.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

🏋️ Exercício 01 – Fundamentos de Segurança da Informação ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 01 sobre Fundamentos de Segurança da Informação ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Fundamentos de Segurança da Informação ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Fundamentos de Segurança da Informação ️** fundamenta-se em princípios consolidados de engenharia de software (1. O que é Segurança da Informação?, 2. A Tríade CIA (CID), 3. Segurança vs Desenvolvimento: Onde Elas se Encontram, 4. Quem são os Adversários?). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Fundamentos de Segurança da Informação ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Fundamentos de Segurança da Informação ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Fundamentos de Segurança da Informação ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 01 Responder Quiz 01

🏋️ Exercício 02 – Ameaças e Engenharia Social ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 02 sobre Ameaças e Engenharia Social ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Ameaças e Engenharia Social ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Ameaças e Engenharia Social ️** fundamenta-se em princípios consolidados de engenharia de software (1. Ameaça x Vulnerabilidade x Risco, 2. Engenharia Social: o Elo Mais Fraco, 3. Sinais de um E-mail de Phishing, 4. Por que Desenvolvedores São Alvos Específicos ‍). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Ameaças e Engenharia Social ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Ameaças e Engenharia Social ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Ameaças e Engenharia Social ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 02 Responder Quiz 02

🏋️ Exercício 03 – Malware e Tipos de Ataques

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 03 sobre Malware e Tipos de Ataques, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Malware e Tipos de Ataques, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Malware e Tipos de Ataques** fundamenta-se em princípios consolidados de engenharia de software (1. O que é Malware?, 2. As Principais Famílias ️, 3. Vetores de Ataque Técnicos Comuns ️, 4. Ransomware: o Ataque Mais Caro da Década). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Malware e Tipos de Ataques. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Malware e Tipos de Ataques** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Malware e Tipos de Ataques. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 03 Responder Quiz 03

🏋️ Exercício 04 – Análise de Riscos e PSI

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 04 sobre Análise de Riscos e PSI, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Análise de Riscos e PSI, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Análise de Riscos e PSI** fundamenta-se em princípios consolidados de engenharia de software (1. Por que Analisar Riscos? ⚖️, 2. Matriz de Probabilidade x Impacto, 3. As Quatro Estratégias de Tratamento de Risco ️, 4. O que é uma PSI?). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Análise de Riscos e PSI. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Análise de Riscos e PSI** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Análise de Riscos e PSI. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 04 Responder Quiz 04

🏋️ Exercício 05 – Firewall, IDS e IPS

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 05 sobre Firewall, IDS e IPS, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Firewall, IDS e IPS, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Firewall, IDS e IPS** fundamenta-se em princípios consolidados de engenharia de software (1. Firewall: o Porteiro da Rede, 2. IDS: o Vigilante que Observa ️, 3. IPS: o Vigilante que Age ⛔, 4. Defesa em Camadas). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Firewall, IDS e IPS. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Firewall, IDS e IPS** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Firewall, IDS e IPS. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 05 Responder Quiz 05

🏋️ Exercício 06 – Criptografia e Assinatura Digital

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 06 sobre Criptografia e Assinatura Digital, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Criptografia e Assinatura Digital, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Criptografia e Assinatura Digital** fundamenta-se em princípios consolidados de engenharia de software (1. Criptografia Simétrica: Uma Chave para Tudo, 2. Criptografia Assimétrica: Duas Chaves ️, 3. Hash: Impressão Digital dos Dados #️⃣, 4. Assinatura Digital: Provando Autoria). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Criptografia e Assinatura Digital. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Criptografia e Assinatura Digital** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Criptografia e Assinatura Digital. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 06 Responder Quiz 06

🏋️ Exercício 07 – Autenticação e Autorização

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 07 sobre Autenticação e Autorização, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Autenticação e Autorização, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Autenticação e Autorização** fundamenta-se em princípios consolidados de engenharia de software (1. Autenticação x Autorização, 2. Os Três Fatores de Autenticação ‍, 3. Armazenamento Seguro de Senhas ️, 4. Modelos de Controle de Acesso ️). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Autenticação e Autorização. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Autenticação e Autorização** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Autenticação e Autorização. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 07 Responder Quiz 07

🏋️ Exercício 08 – Segurança em Redes

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 08 sobre Segurança em Redes, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Segurança em Redes, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Segurança em Redes** fundamenta-se em princípios consolidados de engenharia de software (1. SSL x TLS: a Base do Tráfego Seguro, 2. O TLS Handshake em Resumo, 3. Riscos de Redes Não Confiáveis, 4. Segmentação de Rede). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Segurança em Redes. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Segurança em Redes** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Segurança em Redes. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 08 Responder Quiz 08

🏋️ Exercício 09 – Introdução ao Pentest

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 09 sobre Introdução ao Pentest, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Introdução ao Pentest, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Introdução ao Pentest** fundamenta-se em princípios consolidados de engenharia de software (1. O que é Pentest? ️, 2. Tipos de Pentest por Conhecimento Prévio, 3. As Fases Clássicas de um Pentest ️, 4. Pentest x Red Team x Bug Bounty). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Introdução ao Pentest. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Introdução ao Pentest** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Introdução ao Pentest. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 09 Responder Quiz 09

🏋️ Exercício 10 – Scanners e Enumeração

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 10 sobre Scanners e Enumeração, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Scanners e Enumeração, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Scanners e Enumeração** fundamenta-se em princípios consolidados de engenharia de software (1. Reconhecimento: Antes de Escanear, 2. Varredura de Portas com Nmap ️, 3. O que a Enumeração Revela, 4. Enumeração de Aplicações Web ️). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Scanners e Enumeração. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Scanners e Enumeração** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Scanners e Enumeração. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 10 Responder Quiz 10

🏋️ Exercício 11 – Exploração Controlada

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 11 sobre Exploração Controlada, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Exploração Controlada, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Exploração Controlada** fundamenta-se em princípios consolidados de engenharia de software (1. Da Enumeração à Exploração, 2. O que é um Exploit?, 3. Frameworks de Exploração: Metasploit ️, 4. Pós-Exploração: O Que Vem Depois do Acesso). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Exploração Controlada. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Exploração Controlada** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Exploração Controlada. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 11 Responder Quiz 11

🏋️ Exercício 12 – OWASP Top 10

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 12 sobre OWASP Top 10, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de OWASP Top 10, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **OWASP Top 10** fundamenta-se em princípios consolidados de engenharia de software (1. O que é a OWASP? ️, 2. As Categorias do OWASP Top 10, 3. Foco Prático: SQL Injection, 4. Foco Prático: Broken Access Control). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo OWASP Top 10. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **OWASP Top 10** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em OWASP Top 10. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 12 Responder Quiz 12

🏋️ Exercício 13 – Proteções para Aplicações Web ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 13 sobre Proteções para Aplicações Web ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Proteções para Aplicações Web ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Proteções para Aplicações Web ️** fundamenta-se em princípios consolidados de engenharia de software (1. XSS (Cross-Site Scripting): a Defesa ️, 2. CSRF (Cross-Site Request Forgery), 3. Cabeçalhos HTTP de Segurança, 4. Segurança em Dependências). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Proteções para Aplicações Web ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Proteções para Aplicações Web ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Proteções para Aplicações Web ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 13 Responder Quiz 13

🏋️ Exercício 14 – LGPD e Privacidade

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 14 sobre LGPD e Privacidade, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de LGPD e Privacidade, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **LGPD e Privacidade** fundamenta-se em princípios consolidados de engenharia de software (1. O que é a LGPD?, 2. Dado Pessoal x Dado Sensível, 3. Os Princípios da LGPD ⚖️, 4. Direitos do Titular dos Dados). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo LGPD e Privacidade. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **LGPD e Privacidade** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em LGPD e Privacidade. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 14 Responder Quiz 14

🏋️ Exercício 15 – Cultura Hacker (Ética e Carreira)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 15 sobre Cultura Hacker (Ética e Carreira), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Cultura Hacker (Ética e Carreira), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Cultura Hacker (Ética e Carreira)** fundamenta-se em princípios consolidados de engenharia de software (1. Hacker Não é Sinônimo de Criminoso, 2. Divulgação Responsável (Responsible Disclosure), 3. Certificações da Área, 4. Trilhas de Carreira em Segurança ️). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Cultura Hacker (Ética e Carreira). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Cultura Hacker (Ética e Carreira)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Cultura Hacker (Ética e Carreira). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 15 Responder Quiz 15

🏋️ Exercício 16 – Projeto Integrador

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 16 sobre Projeto Integrador, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Projeto Integrador, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Projeto Integrador** fundamenta-se em princípios consolidados de engenharia de software (1. O Desafio Final: Auditoria de Segurança Completa, 2. Etapas Obrigatórias da Auditoria, 3. Estrutura do Relatório Final, 4. Exemplo de Formato de Achado). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Projeto Integrador. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Projeto Integrador** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Projeto Integrador. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 16 Responder Quiz 16

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

Projeto 01 - Cinto de Utilidades Backend 🛠️

Objetivo: Validar a instalação das ferramentas e testar a comunicação básica com uma API pública.

O Desafio

  1. Instale o Postman ou Insomnia.
  2. Realize uma requisição do tipo GET para a API pública do GitHub: https://api.github.com/users/github.
  3. Analise a resposta (JSON). Identifique os campos login, id e public_repos.
  4. Instale o Docker Desktop e rode o comando docker run hello-world no terminal para garantir que a virtualização está ativa.
  5. Crie uma conta no GitHub (se não tiver) e instale o Git.

O que entregar?

  • Print (screenshot) da resposta JSON no Postman/Insomnia.
  • Print do terminal com a mensagem de sucesso do Docker "Hello from Docker!".

Projeto 02 - Modelagem de Fluxo de Gateway 🏗️

Objetivo: Entender o roteamento e a agregação de dados em um Gateway.

O Desafio

Imagine que você tem dois serviços: - Serviço A (User): Retorna { "id": 1, "nome": "Ricardo" } - Serviço B (Orders): Retorna [ { "id": 101, "valor": 50.0 }, { "id": 102, "valor": 30.0 } ]

  1. Desenhe um diagrama (pode ser no Mermaid ou papel) onde um API Gateway recebe uma chamada em /dashboard/1 e busca os dados nos dois serviços.
  2. Escreva o JSON final que o Gateway entregaria para o Frontend, unindo as informações do usuário e seus pedidos.
  3. Pesquisa: Liste 3 ferramentas famosas de API Gateway de mercado (ex: Kong, AWS API Gateway, etc).

O que entregar?

  • O diagrama de fluxo.
  • O JSON de resposta agregada.
  • A lista de ferramentas pesquisadas.

Projeto 03 - Contrato de API de Rede Social ⚡

Objetivo: Aplicar os conceitos de recursos, verbos e JSON na modelagem de uma rede social.

O Desafio

Você deve projetar a API para o recurso "Postagens" (Posts).

  1. Liste as 5 rotas principais (CRUD) para gerenciar postagens, indicando o Verbo, a URI e o Status Code de sucesso esperado.
  2. Crie um exemplo de JSON para uma postagem que contenha:
    • id
    • autor_id
    • conteúdo (texto)
    • data_publicacao
    • tags (lista de strings)
  3. Simulação de Erro: Qual seria a URI e o Verbo para dar um "Like" em uma postagem? Projete isso.

O que entregar?

  • Tabela com as 5 rotas (Verbo, URI, Status).
  • Bloco de código com o JSON de exemplo.
  • Proposta da rota de "Like".

Projeto 04 - Criando o Primeiro Mock 🧱

Objetivo: Dominar o fluxo de documentação de contrato e simulação de servidor.

O Desafio

Você deve criar um servidor de Mock para uma API de Lista de Tarefas (ToDo).

  1. Use o Postman (Mock Server) ou o Mockoon para criar 2 rotas:
    • GET /tarefas: Deve retornar uma lista com pelo menos 3 tarefas.
    • POST /tarefas: Deve aceitar uma nova tarefa e retornar 201 Created.
  2. Documente os campos de uma tarefa (ex: id, titulo, concluida).
  3. Teste as rotas e garanta que o servidor responda corretamente no formato JSON.

O que entregar?

  • Print (screenshot) do Swagger UI ou da tela do Mock Server rodando.
  • O JSON de exemplo retornado pelo GET /tarefas.
  • Print do teste da rota POST /tarefas com sucesso.

Projeto 05 - Meu Primeiro Controller ⚙️

Objetivo: Praticar a criação de rotas e a captura de diferentes tipos de parâmetros.

O Desafio

Crie a estrutura de um Controller para um sistema de Gestão de Tarefas (To-Do). Você deve definir (em pseudocódigo ou na linguagem que preferir):

  1. Uma rota para listar todas as tarefas, permitindo um filtro opcional por status (ex: concluída ou pendente).
  2. Uma rota para buscar uma única tarefa pelo seu id.
  3. Uma rota para criar uma tarefa, recebendo titulo e descricao.
  4. Sinalize qual seria o Status Code de sucesso para cada uma das rotas acima.

O que avaliar?

  • Uso correto de Path Params vs Query Params.
  • Escolha dos verbos HTTP adequados.
  • Padronização das respostas de sucesso.

Projeto 06 - Implementando a Lógica de Negócio 🧠

Objetivo: Aplicar a separação de camadas criando um Service para validação de dados.

O Desafio

Você deve criar o UsuarioService para um sistema de cadastro.

  1. Função validarSenha(senha): Deve garantir que a senha tenha no mínimo 8 caracteres e contenha pelo menos um número.
  2. Função criarUsuario(dados):
    • Chama a validação de senha.
    • Verifica se o e-mail já está sendo usado (simule um erro se estiver).
    • Retorna o usuário criado (sem a senha!).
  3. Simule o Controller chamando esse Service e tratando o erro de "Senha Insegura" com um Status Code 400.

O que observar?

  • O Service não deve usar objetos globais como req ou res.
  • As mensagens de erro devem ser claras e informativas.
  • Uso de DTOs (retornar objeto filtrado).

Projeto 07 - Modelagem de Banco de Dados 🗄️

Objetivo: Praticar a criação de esquemas relacionais e comandos SQL básicos.

O Desafio

Modele o banco de dados para um sistema de Aluguel de Filmes:

  1. Tabelas: Crie as tabelas Clientes e Filmes.
  2. Campos:
    • Clientes deve ter id, nome e email.
    • Filmes deve ter id, titulo e genero.
  3. Relacionamento: Crie uma terceira tabela Alugueis que ligue um cliente a um filme (incluindo a data_aluguel).
  4. SQL: Escreva uma query que liste o nome do cliente e o título do filme para todos os aluguéis feitos hoje.

O que avaliar?

  • Definição correta das Chaves Primárias.
  • Uso de Chaves Estrangeiras para conectar as tabelas.
  • Clareza na estrutura das colunas.

Projeto 08 - Schema de Validação Profissional ✅

Objetivo: Praticar a criação de regras de validação para garantir a integridade da API.

O Desafio

Crie o esquema de validação (em pseudocódigo ou usando uma biblioteca como Zod/Joi) para um Cadastro de Eventos:

  1. Campos Obrigatórios: titulo (mín. 10 char), data (deve ser futura), capacidade_maxima (número positivo).
  2. Campos Opcionais: descricao (máx. 500 char), link_inscricao (formato de URL).
  3. Sanitização: O título não deve conter espaços em branco sobrando no início ou no fim (trim).
  4. Simulação: Mostre qual seria a mensagem de erro retornada se o usuário enviasse uma capacidade negativa.

O que avaliar?

  • Clareza e rigor das regras de validação.
  • Escolha dos tipos de dados corretos.
  • Mensagens de erro amigáveis ao desenvolvedor (DX).

Projeto 09 - Sistema de Login (Simulado) 🔐

Objetivo: Implementar a lógica de geração de tokens JWT para autenticação.

O Desafio

Crie uma API de simulação de login:

  1. Entrada: Receba um JSON com email e senha.
  2. Validação: Verifique se a senha tem mais de 6 caracteres.
  3. JWT: Use uma biblioteca (ou pseudocódigo) para gerar um token que contenha o id do usuário e sua permissão (ex: 'aluno').
  4. Expiração: Configure o token para ser válido por apenas 24 horas.
  5. Resposta: Retorne para o cliente um objeto contendo o token e o nome do usuário.

O que avaliar?

  • Tratamento correto de erro caso a senha seja curta.
  • Estrutura limpa do Payload do JWT.
  • Escolha de uma chave secreta segura (simulada).

Projeto 10 - Gerenciador de Permissões 🛡️

Objetivo: Implementar a lógica de proteção de rotas baseada em perfis de usuário.

O Desafio

Crie a estrutura de autorização para um Sistema de RH:

  1. Roles: Defina três tipos: ADMIN, GESTOR e FUNCIONARIO.
  2. Regras:
    • Todos podem ver o próprio perfil (GET /me).
    • Apenas GESTOR e ADMIN podem ver a lista de salários (GET /salarios).
    • Apenas ADMIN pode deletar um registro (DELETE /colaboradores/:id).
  3. Middleware: Desenhe (em desenho técnico ou código) como seria o "fluxo da cancela" (Authentication Middleware -> Authorization Middleware).

O que avaliar?

  • Separação clara entre quem é você e o que você pode fazer.
  • Uso correto dos Status Codes em caso de bloqueio.
  • Lógica de hierarquia (Admin pode tudo).

Projeto 11 - Blindagem de API 🏗️

Objetivo: Implementar camadas avançadas de segurança e renovação de tokens.

O Desafio

Fortaleça sua API de login:

  1. Helmet: Instale e configure o Helmet para proteger os Headers.
  2. CORS: Restrinja o acesso à API para que apenas o domínio http://localhost:3000 possa consultá-la.
  3. Refresh Token: Implemente uma rota /refresh que receba um refresh token, valide-o no banco (ou lista em memória) e gere um novo accessToken.
  4. Rate Limit: Adicione uma trava para que ninguém possa tentar logar mais de 5 vezes em 1 minuto.

O que avaliar?

  • Configuração correta das origens no CORS.
  • Lógica de expiração do Refresh Token (ele deve durar muito mais que o Access Token).
  • Verificação se o Helmet está realmente escondendo o header X-Powered-By.

Projeto 12 - Primeiro App React ⚛️

Objetivo: Criar e organizar componentes básicos usando React e Vite.

O Desafio

Crie uma página de Perfil de Usuário:

  1. Componente FotoPerfil: Exibe uma imagem circular.
  2. Componente InfoUsuario: Recebe nome e bio via props e exibe na tela.
  3. Componente BotaoSeguir: Um botão simples que, por enquanto, apenas exibe um alerta ao ser clicado.
  4. Layout: Organize esses componentes dentro do App.jsx usando CSS simples para centralizar o conteúdo.

O que avaliar?

  • Separação correta dos componentes em arquivos diferentes (ou funções separadas).
  • Uso correto de Props para personalizar o nome do usuário.
  • Sintaxe JSX correta (tags fechadas, className, etc).

Projeto 13 - Lista Dinâmica de Contatos 📱

Objetivo: Aplicar o uso de useState e gerenciamento de listas.

O Desafio

Crie um mini-gerenciador de contatos:

  1. Inputs: Dois campos de texto (Nome e Telefone).
  2. Botão Adicionar: Quando clicado, deve validar se os campos estão preenchidos e adicionar o contato em um Estado de Array.
  3. Lista: Exiba todos os contatos adicionados abaixo do formulário.
  4. Botão Limpar: Um botão que limpa toda a lista de contatos.

O que avaliar?

  • Uso correto do useState para os inputs e para a lista.
  • Uso do .map() para renderizar a lista de contatos.
  • Limpeza dos campos de input após a adição com sucesso.

Projeto 14 - Buscador de Repositórios 🔍

Objetivo: Consumir uma API real e gerenciar estados de carregamento.

O Desafio

Crie um app que busca repositórios do GitHub de um usuário:

  1. Input: Campo para digitar o nome do usuário do GitHub.
  2. Botão Buscar: Ao clicar, deve disparar a busca.
  3. Loading: Enquanto a API não responde, deve aparecer o texto "Buscando repositórios...".
  4. Lista: Exiba o nome de todos os repositórios públicos encontrados.
  5. Erro: Se o usuário não existir, exiba "Erro: Usuário não encontrado".

O que avaliar?

  • Uso do useEffect para carregar dados (pode ser ao carregar a página ou via clique).
  • Tratamento correto dos estados: null, loading, data e error.
  • Renderização limpa usando .map().

Projeto 15 - Sistema de Multi-Páginas 🚦

Objetivo: Implementar a navegação completa em uma SPA.

O Desafio

Transforme seu app de repositórios ou contatos em um site completo com 3 páginas:

  1. Home (/): Uma página de boas-vindas com links para as outras seções.
  2. Dashboard (/app): Onde fica a funcionalidade principal (ex: a busca de repositórios).
  3. Sobre (/sobre): Uma página contando quem criou o projeto.
  4. 404: Uma página personalizada para links quebrados.

Requisito Extra (Parâmetro)

Crie uma página de Perfil de Repositório (/repo/:id) que deve ser aberta ao clicar em um item da lista. Essa página só precisa exibir o ID que foi clicado por enquanto.

O que avaliar?

  • Configuração correta do BrowserRouter no main.jsx ou App.jsx.
  • Uso exclusivo de <Link> para navegação em menus.
  • Funcionamento correto dos parâmetros de URL com useParams.

Projeto 16 - App Final Full-Stack Integrador 🏆

Objetivo: O "TCC (Trabalho de Conclusão de Curso)" do desenvolvedor Full-Stack.

O Tema

Escolha um tema que resolva um problema real integrando o que você construiu no Backend (Módulos 1-3) com o que aprendeu no Frontend (Módulo 4).

Requisitos Mínimos

  1. Backend (Express): Uso obrigatório de rotas protegidas por JWT e validação de dados.
  2. Frontend (React): Componentização clara, uso de Hooks (useState, useEffect) e navegação com React Router.
  3. Integração: O Frontend deve consumir a sua própria API de forma assíncrona.
  4. UX/UI: Interface amigável, com tratamento de estados de carregamento e erro.
  5. Segurança: Configuração correta de CORS e Headers de segurança (Helmet).

Documentação ✨

Seu repositório no GitHub deve ter um README.md impecável, com imagens (prints) da aplicação, explicação das tecnologias usadas e instruções claras de como rodar o servidor e o cliente. Este projeto será o seu maior cartão de visitas!

Boa sorte e bom código! 🚀🚀🚀

Quizzes

🧠 Quizzes de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – Fundamentos de Segurança da Informação 🛡️

  1. Qual é o conceito fundamental e objetivo principal de Fundamentos de Segurança da Informação 🛡️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Fundamentos de Segurança da Informação 🛡️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Fundamentos de Segurança da Informação 🛡️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Fundamentos de Segurança da Informação 🛡️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Fundamentos de Segurança da Informação 🛡️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Fundamentos de Segurança da Informação 🛡️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Fundamentos de Segurança da Informação 🛡️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Fundamentos de Segurança da Informação 🛡️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Fundamentos de Segurança da Informação 🛡️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Fundamentos de Segurança da Informação 🛡️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Ameaças e Engenharia Social 🕵️

  1. Qual é o conceito fundamental e objetivo principal de Ameaças e Engenharia Social 🕵️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Ameaças e Engenharia Social 🕵️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Ameaças e Engenharia Social 🕵️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Ameaças e Engenharia Social 🕵️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Ameaças e Engenharia Social 🕵️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Ameaças e Engenharia Social 🕵️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Ameaças e Engenharia Social 🕵️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Ameaças e Engenharia Social 🕵️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Ameaças e Engenharia Social 🕵️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Ameaças e Engenharia Social 🕵️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Malware e Tipos de Ataques 🦠

  1. Qual é o conceito fundamental e objetivo principal de Malware e Tipos de Ataques 🦠?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Malware e Tipos de Ataques 🦠?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Malware e Tipos de Ataques 🦠, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Malware e Tipos de Ataques 🦠?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Malware e Tipos de Ataques 🦠 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Malware e Tipos de Ataques 🦠, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Malware e Tipos de Ataques 🦠?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Malware e Tipos de Ataques 🦠 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Malware e Tipos de Ataques 🦠 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Malware e Tipos de Ataques 🦠 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Análise de Riscos e PSI 📋

  1. Qual é o conceito fundamental e objetivo principal de Análise de Riscos e PSI 📋?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Análise de Riscos e PSI 📋?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Análise de Riscos e PSI 📋, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Análise de Riscos e PSI 📋?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Análise de Riscos e PSI 📋 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Análise de Riscos e PSI 📋, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Análise de Riscos e PSI 📋?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Análise de Riscos e PSI 📋 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Análise de Riscos e PSI 📋 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Análise de Riscos e PSI 📋 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Firewall, IDS e IPS 🧱

  1. Qual é o conceito fundamental e objetivo principal de Firewall, IDS e IPS 🧱?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Firewall, IDS e IPS 🧱?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Firewall, IDS e IPS 🧱, IDS e IPS 🧱, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Firewall, IDS e IPS 🧱?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Firewall, IDS e IPS 🧱 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Firewall, IDS e IPS 🧱, IDS e IPS 🧱, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Firewall, IDS e IPS 🧱?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Firewall, IDS e IPS 🧱 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Firewall, IDS e IPS 🧱 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Firewall, IDS e IPS 🧱 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Criptografia e Assinatura Digital 🔐

  1. Qual é o conceito fundamental e objetivo principal de Criptografia e Assinatura Digital 🔐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Criptografia e Assinatura Digital 🔐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Criptografia e Assinatura Digital 🔐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Criptografia e Assinatura Digital 🔐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Criptografia e Assinatura Digital 🔐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Criptografia e Assinatura Digital 🔐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Criptografia e Assinatura Digital 🔐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Criptografia e Assinatura Digital 🔐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Criptografia e Assinatura Digital 🔐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Criptografia e Assinatura Digital 🔐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 07 – Autenticação e Autorização 🔑

  1. Qual é o conceito fundamental e objetivo principal de Autenticação e Autorização 🔑?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Autenticação e Autorização 🔑?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Autenticação e Autorização 🔑, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Autenticação e Autorização 🔑?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Autenticação e Autorização 🔑 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Autenticação e Autorização 🔑, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Autenticação e Autorização 🔑?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Autenticação e Autorização 🔑 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Autenticação e Autorização 🔑 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Autenticação e Autorização 🔑 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Segurança em Redes 🌐

  1. Qual é o conceito fundamental e objetivo principal de Segurança em Redes 🌐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Segurança em Redes 🌐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Segurança em Redes 🌐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Segurança em Redes 🌐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Segurança em Redes 🌐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Segurança em Redes 🌐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Segurança em Redes 🌐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Segurança em Redes 🌐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Segurança em Redes 🌐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Segurança em Redes 🌐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – Introdução ao Pentest 🎯

  1. Qual é o conceito fundamental e objetivo principal de Introdução ao Pentest 🎯?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução ao Pentest 🎯?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução ao Pentest 🎯, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução ao Pentest 🎯?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução ao Pentest 🎯 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução ao Pentest 🎯, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução ao Pentest 🎯?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução ao Pentest 🎯 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução ao Pentest 🎯 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução ao Pentest 🎯 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – Scanners e Enumeração 🔍

  1. Qual é o conceito fundamental e objetivo principal de Scanners e Enumeração 🔍?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Scanners e Enumeração 🔍?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Scanners e Enumeração 🔍, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Scanners e Enumeração 🔍?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Scanners e Enumeração 🔍 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Scanners e Enumeração 🔍, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Scanners e Enumeração 🔍?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Scanners e Enumeração 🔍 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Scanners e Enumeração 🔍 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Scanners e Enumeração 🔍 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – Exploração Controlada 💥

  1. Qual é o conceito fundamental e objetivo principal de Exploração Controlada 💥?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Exploração Controlada 💥?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Exploração Controlada 💥, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Exploração Controlada 💥?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Exploração Controlada 💥 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Exploração Controlada 💥, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Exploração Controlada 💥?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Exploração Controlada 💥 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Exploração Controlada 💥 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Exploração Controlada 💥 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – OWASP Top 10 🔟

  1. Qual é o conceito fundamental e objetivo principal de OWASP Top 10 🔟?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de OWASP Top 10 🔟?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em OWASP Top 10 🔟, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em OWASP Top 10 🔟?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de OWASP Top 10 🔟 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em OWASP Top 10 🔟, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em OWASP Top 10 🔟?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a OWASP Top 10 🔟 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar OWASP Top 10 🔟 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a OWASP Top 10 🔟 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Proteções para Aplicações Web 🛡️

  1. Qual é o conceito fundamental e objetivo principal de Proteções para Aplicações Web 🛡️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Proteções para Aplicações Web 🛡️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Proteções para Aplicações Web 🛡️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Proteções para Aplicações Web 🛡️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Proteções para Aplicações Web 🛡️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Proteções para Aplicações Web 🛡️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Proteções para Aplicações Web 🛡️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Proteções para Aplicações Web 🛡️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Proteções para Aplicações Web 🛡️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Proteções para Aplicações Web 🛡️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – LGPD e Privacidade 📜

  1. Qual é o conceito fundamental e objetivo principal de LGPD e Privacidade 📜?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de LGPD e Privacidade 📜?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em LGPD e Privacidade 📜, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em LGPD e Privacidade 📜?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de LGPD e Privacidade 📜 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em LGPD e Privacidade 📜, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em LGPD e Privacidade 📜?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a LGPD e Privacidade 📜 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar LGPD e Privacidade 📜 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a LGPD e Privacidade 📜 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Cultura Hacker (Ética e Carreira) 🎩

  1. Qual é o conceito fundamental e objetivo principal de Cultura Hacker (Ética e Carreira) 🎩?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Cultura Hacker (Ética e Carreira) 🎩?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Cultura Hacker (Ética e Carreira) 🎩, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Cultura Hacker (Ética e Carreira) 🎩?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Cultura Hacker (Ética e Carreira) 🎩 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Cultura Hacker (Ética e Carreira) 🎩, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Cultura Hacker (Ética e Carreira) 🎩?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Cultura Hacker (Ética e Carreira) 🎩 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Cultura Hacker (Ética e Carreira) 🎩 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Cultura Hacker (Ética e Carreira) 🎩 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Projeto Integrador 🏆

  1. Qual é o conceito fundamental e objetivo principal de Projeto Integrador 🏆?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Projeto Integrador 🏆?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Projeto Integrador 🏆, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Projeto Integrador 🏆?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Projeto Integrador 🏆 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Projeto Integrador 🏆, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Projeto Integrador 🏆?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Projeto Integrador 🏆 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Projeto Integrador 🏆 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Projeto Integrador 🏆 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 17 – Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀

  1. Qual o propósito principal de Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Análise Estática (SAST) e Dinâmica (DAST) de Código 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 18 – Mitigação de Vulnerabilidades OWASP Top 10 🚀

  1. Qual o propósito principal de Mitigação de Vulnerabilidades OWASP Top 10 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Mitigação de Vulnerabilidades OWASP Top 10 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Mitigação de Vulnerabilidades OWASP Top 10 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Mitigação de Vulnerabilidades OWASP Top 10 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Mitigação de Vulnerabilidades OWASP Top 10 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Mitigação de Vulnerabilidades OWASP Top 10 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Mitigação de Vulnerabilidades OWASP Top 10 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Mitigação de Vulnerabilidades OWASP Top 10 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Mitigação de Vulnerabilidades OWASP Top 10 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Mitigação de Vulnerabilidades OWASP Top 10 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 19 – Gestão Segura de Segredos e Certificados em CI/CD 🚀

  1. Qual o propósito principal de Gestão Segura de Segredos e Certificados em CI/CD 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Gestão Segura de Segredos e Certificados em CI/CD 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Gestão Segura de Segredos e Certificados em CI/CD 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Gestão Segura de Segredos e Certificados em CI/CD 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Gestão Segura de Segredos e Certificados em CI/CD 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Gestão Segura de Segredos e Certificados em CI/CD 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Gestão Segura de Segredos e Certificados em CI/CD 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Gestão Segura de Segredos e Certificados em CI/CD 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Gestão Segura de Segredos e Certificados em CI/CD 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Gestão Segura de Segredos e Certificados em CI/CD 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 20 – Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀

  1. Qual o propósito principal de Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Projeto Capstone: Pipeline DevSecOps Autônomo Hardened 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

Slides

Configuração

Ambientes de Desenvolvimento e Configuração 🛠️

Guias oficiais passo a passo para configurar suas ferramentas profissionais de desenvolvimento para Desenvolvimento Seguro (DevSecOps).

Setup 01: Análise Estática de Segurança (SAST) com Semgrep 🛠️

Objetivo da Configuração

Objetivo: Instalação e uso do Semgrep para identificar vulnerabilidades de código em tempo de desenvolvimento.

1. Pré-Requisitos e Visão Geral

A configuração correta deste ambiente é fundamental para o desenvolvimento eficiente e sem atritos ao longo do curso de Desenvolvimento Seguro (DevSecOps).

2. Passo a Passo de Instalação e Configuração

📥 Passo 1: Download e Instalação

Siga as instruções oficiais correspondentes ao seu sistema operacional (Windows, Linux ou macOS): - Baixe o pacote oficial da ferramenta diretamente do site do mantenedor. - Execute o assistente de instalação habilitando a opção de adicionar os binários à variável de ambiente PATH.

⚙️ Passo 2: Verificação no Terminal

Abra uma nova janela de terminal e valide se o comando está acessível: 

# Verificação de versão instalada
echo "Validando ambiente de Desenvolvimento Seguro (DevSecOps)..."

💻 Passo 3: Configuração no Editor / IDE

  • Instale as extensões recomendadas para obter destaque de sintaxe, autocompletar e linters integrados.
  • Reinicie o editor para carregar os novos caminhos de execução.

3. Teste Rápido de Validação

Crie um arquivo de teste simples para comprovar que o compilador, interpretador ou ferramenta está operando com 100% de sucesso.

🎯 Próximos Passos

Com o ambiente configurado, você está pronto para iniciar as aulas práticas e desenvolver os projetos da disciplina.

Setup 02: Varredura de Dependências com Trivy e Snyk 🛠️

Objetivo da Configuração

Objetivo: Identificação de CVEs e bibliotecas vulneráveis em projetos de software.

1. Pré-Requisitos e Visão Geral

A configuração correta deste ambiente é fundamental para o desenvolvimento eficiente e sem atritos ao longo do curso de Desenvolvimento Seguro (DevSecOps).

2. Passo a Passo de Instalação e Configuração

📥 Passo 1: Download e Instalação

Siga as instruções oficiais correspondentes ao seu sistema operacional (Windows, Linux ou macOS): - Baixe o pacote oficial da ferramenta diretamente do site do mantenedor. - Execute o assistente de instalação habilitando a opção de adicionar os binários à variável de ambiente PATH.

⚙️ Passo 2: Verificação no Terminal

Abra uma nova janela de terminal e valide se o comando está acessível: 

# Verificação de versão instalada
echo "Validando ambiente de Desenvolvimento Seguro (DevSecOps)..."

💻 Passo 3: Configuração no Editor / IDE

  • Instale as extensões recomendadas para obter destaque de sintaxe, autocompletar e linters integrados.
  • Reinicie o editor para carregar os novos caminhos de execução.

3. Teste Rápido de Validação

Crie um arquivo de teste simples para comprovar que o compilador, interpretador ou ferramenta está operando com 100% de sucesso.

🎯 Próximos Passos

Com o ambiente configurado, você está pronto para iniciar as aulas práticas e desenvolver os projetos da disciplina.

Setup 03: OWASP ZAP (Zed Attack Proxy) para Testes DAST 🛠️

Objetivo da Configuração

Objetivo: Configuração de scanner dinâmico para testar APIs e aplicações web contra o OWASP Top 10.

1. Pré-Requisitos e Visão Geral

A configuração correta deste ambiente é fundamental para o desenvolvimento eficiente e sem atritos ao longo do curso de Desenvolvimento Seguro (DevSecOps).

2. Passo a Passo de Instalação e Configuração

📥 Passo 1: Download e Instalação

Siga as instruções oficiais correspondentes ao seu sistema operacional (Windows, Linux ou macOS): - Baixe o pacote oficial da ferramenta diretamente do site do mantenedor. - Execute o assistente de instalação habilitando a opção de adicionar os binários à variável de ambiente PATH.

⚙️ Passo 2: Verificação no Terminal

Abra uma nova janela de terminal e valide se o comando está acessível: 

# Verificação de versão instalada
echo "Validando ambiente de Desenvolvimento Seguro (DevSecOps)..."

💻 Passo 3: Configuração no Editor / IDE

  • Instale as extensões recomendadas para obter destaque de sintaxe, autocompletar e linters integrados.
  • Reinicie o editor para carregar os novos caminhos de execução.

3. Teste Rápido de Validação

Crie um arquivo de teste simples para comprovar que o compilador, interpretador ou ferramenta está operando com 100% de sucesso.

🎯 Próximos Passos

Com o ambiente configurado, você está pronto para iniciar as aulas práticas e desenvolver os projetos da disciplina.

Setup 04: Prevenção de Vazamento de Segredos com Gitleaks 🛠️

Objetivo da Configuração

Objetivo: Detecção automática de chaves de API, senhas e tokens antes do commit no Git.

1. Pré-Requisitos e Visão Geral

A configuração correta deste ambiente é fundamental para o desenvolvimento eficiente e sem atritos ao longo do curso de Desenvolvimento Seguro (DevSecOps).

2. Passo a Passo de Instalação e Configuração

📥 Passo 1: Download e Instalação

Siga as instruções oficiais correspondentes ao seu sistema operacional (Windows, Linux ou macOS): - Baixe o pacote oficial da ferramenta diretamente do site do mantenedor. - Execute o assistente de instalação habilitando a opção de adicionar os binários à variável de ambiente PATH.

⚙️ Passo 2: Verificação no Terminal

Abra uma nova janela de terminal e valide se o comando está acessível: 

# Verificação de versão instalada
echo "Validando ambiente de Desenvolvimento Seguro (DevSecOps)..."

💻 Passo 3: Configuração no Editor / IDE

  • Instale as extensões recomendadas para obter destaque de sintaxe, autocompletar e linters integrados.
  • Reinicie o editor para carregar os novos caminhos de execução.

3. Teste Rápido de Validação

Crie um arquivo de teste simples para comprovar que o compilador, interpretador ou ferramenta está operando com 100% de sucesso.

🎯 Próximos Passos

Com o ambiente configurado, você está pronto para iniciar as aulas práticas e desenvolver os projetos da disciplina.

Sobre

Sobre o Curso

🎓 Desenvolvimento Seguro

Este é um curso completo e estruturado de Desenvolvimento Seguro. Desenvolvido para levar você dos fundamentos de segurança da informação até a prática de pentest controlado e a conformidade com a LGPD, com foco em proteger aplicações desde a concepção do código.

🎯 Objetivos do Curso

  • Pensar como Atacante

    Entender ameaças, engenharia social e tipos de ataque para saber exatamente o que defender.

  • Dominar Mecanismos de Defesa

    Aplicar firewall, IDS/IPS, criptografia, assinatura digital e autenticação segura na prática.

  • Praticar Pentest Controlado

    Usar scanners, enumeração e exploração controlada em ambiente de laboratório, com ética.

  • Proteger Aplicações Web

    Aplicar o OWASP Top 10 e as principais proteções contra as vulnerabilidades mais exploradas.

📚 O Que Você Vai Aprender

Módulo 1 – Fundamentos e Ameaças

  • Fundamentos de Segurança da Informação
  • Ameaças e Engenharia Social
  • Malware e tipos de ataque
  • Análise de Riscos e Política de Segurança da Informação (PSI)

Módulo 2 – Mecanismos de Segurança

  • Firewall, IDS e IPS
  • Criptografia e Assinatura Digital
  • Autenticação e Autorização
  • Segurança em Redes

Módulo 3 – Prática (Pentest)

  • Introdução ao Pentest
  • Scanners e Enumeração
  • Exploração Controlada

Módulo 4 – Segurança Web

  • OWASP Top 10
  • Proteções para Aplicações Web

Módulo 5 – Ética e Legislação

  • LGPD e Privacidade
  • Cultura Hacker (Ética e Carreira)

🛠️ Metodologia

Foco 100% prático e orientado a laboratórios. Cada módulo culmina em uma etapa funcional de análise ou defesa de segurança, garantindo que ao final do curso você tenha um portfólio robusto de segurança da informação.

👨‍🎓 Público-Alvo

  • Desenvolvedores que querem escrever código seguro desde a primeira linha
  • Estudantes de TI e ADS que buscam entender segurança da informação na prática
  • Profissionais de infraestrutura que precisam reconhecer e mitigar ameaças reais
  • Futuros analistas de segurança que querem uma base sólida antes de se especializar em pentest

📋 Pré-requisitos

  • Computador com internet
  • Lógica de programação básica
  • Curiosidade para entender como sistemas são atacados — e defendidos
  • Não é necessário conhecimento prévio de segurança!

🎖️ O Que Você Receberá

  • ✅ 16 aulas completas e estruturadas
  • ✅ Slides modernos e interativos
  • ✅ Exercícios práticos por aula
  • ✅ Mini-projetos aplicados
  • ✅ Quizzes de fixação por aula
  • ✅ Projeto Integrador final

Pronto para dominar a Segurança? Começar Agora

Roadmap do Projeto: APIs e Microsserviços 🚀

Este documento rastreia a evolução do curso.

✅ Fase 1: Planejamento (Concluído)

  • Definição Syllabus (16 Aulas)
  • Estrutura Backend-first com integração SPA
  • Configuração MkDocs Material

✅ Fase 2: Conteúdo Base (Concluído)

  • Criação das 16 Aulas (Markdown)
  • Criação dos 16 Quizzes (HTML)
  • Criação dos 16 Conjuntos de Exercícios
  • Criação dos 16 Slides (RevealJS)

✅ Fase 3: Projetos e UX (Concluído)

  • Definição dos 16 Projetos práticos
  • Documentação Swagger/OpenAPI integrada
  • Diagramação Mermaid de arquitetura de serviços

🚀 Fase 4: Lançamento e Manutenção

  • Deploy GitHub Pages (GitHub Actions)
  • Atualização para novas versões de frameworks (Spring/Node/React)
  • Inclusão de exemplos de mensageria (RabbitMQ/Kafka)

Status Atual: Finalizado / Manutenção Última Atualização: 19/02/2026

Materiais Complementares 📚

Bem-vindo à seção de materiais complementares do curso de APIs e Microsserviços. Aqui você encontra recursos adicionais para apoiar seus estudos e aprofundar seu conhecimento técnico.

  • Slides

    • Acompanhe o conteúdo teórico com slides dinâmicos.

  • Exercícios

    • Pratique a implementação de microsserviços e rotas REST.

  • Quizzes

    • Valide seu aprendizado com testes rápidos por módulo.

  • Projetos

    • Construa um ecossistema completo para seu portfólio.

  • Ambiente

    • Guias de instalação (Docker, IDEs, Postman).

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

Esta página foi gerada automaticamente para impressão.