A regra de ouro do DevSecOps: o humano esquece; o CI não. Você não vai "lembrar" de rodar o gitleaks antes de todo commit — mas o pipeline roda, sempre, em todo push. A segurança vira parte do encanamento, não uma tarefa a mais.

Por que isto é o seu atalho: você já usa Git, já faz deploy, já automatiza (n8n). DevSecOps é adicionar segurança a um processo que você domina — não aprender um mundo novo.

PARTE B — Os 8 portões (práticas)

Cada um: o que é · o que pega · ferramentas · no seu projeto.

Portão 1 — Secrets scanning 🔑 (o mais urgente)

• O que pega: chave/segredo prestes a entrar (ou já) no Git.
• Como: gitleaks ou TruffleHog — como pre-commit hook (bloqueia antes do commit) e no CI (bloqueia o merge).
• Projeto: corrige a raiz do Ex. 32 (75 segredos no histórico). Pre-commit impede o próximo.

Portão 2 — SAST (análise estática do SEU código) 🔍

• O que é: Static Application Security Testing — lê seu código-fonte procurando padrões inseguros (SQLi, XSS, eval, etc.) sem executá-lo.
• Ferramentas: Semgrep (rápido, regras open-source), CodeQL (GitHub, gratuito para repos públicos).
• Projeto: pegaria o dangerouslySetInnerHTML do Ex. 33, concatenação de SQL, etc.

Portão 3 — Dependency scanning / SCA 📦

• O que é: Software Composition Analysis — verifica as dependências de terceiros por CVEs conhecidos.
• Ferramentas: npm audit / pip-audit, Dependabot (abre PR automático de correção), Trivy, Snyk.
• Projeto: corrige o Ex. 34 (range versions, supply chain). Dependabot mantém atualizado.

Portão 4 — Container scanning 🐳

• O que é: escanear a imagem do container por CVEs (liga ao Módulo 7).
• Ferramentas: Trivy, docker scout, Grype.
• Projeto: a imagem do n8n e qualquer imagem base — no CI, antes do deploy.

Portão 5 — DAST (teste dinâmico da app rodando) 🌐

• O que é: Dynamic Application Security Testing — testa a aplicação rodando (como um scanner de fora), pegando o que a análise estática não vê.
• Ferramentas: OWASP ZAP (gratuito), Burp (manual).
• Projeto: rodar o ZAP contra um ambiente de staging no pipeline.

Portão 6 — IaC security (infra como código) 🏗️

• O que é: sua infraestrutura vira código (Terraform, wrangler.jsonc, docker-compose, manifests K8s). Ela também tem falhas de config — e pode ser escaneada.
• Ferramentas: checkov, tfsec, Trivy (config).
• Projeto: pegaria "bucket público", "porta de banco aberta", "container privilegiado" — antes de aplicar.

Portão 7 — Branch protection, code review & CODEOWNERS 👥

• O que é: regras no repositório: main protegida (exige review + CI verde), CODEOWNERS para rotas sensíveis (/api/admin), sem push direto.
• Projeto: garante que nada entra em produção sem passar pelos portões (DOC §4.8.3).

Portão 8 — Supply-chain security 🔗

• O que é: garantir a integridade da cadeia: lockfile commitado, npm ci (só o lockfile) no CI, ignore-scripts quando possível, e um SBOM (lista de componentes) para saber o que você embarca.
• Projeto: fecha typosquatting/dependency confusion (Ex. 34).

PARTE C — Montando um pipeline seguro (exemplo)

Um workflow de CI que roda os portões em todo push (exemplo ilustrativo — no GitHub Actions; adapte ao seu provedor). É a versão automatizada do DOCUMENTACAO §4.8:

name: security
on: [push, pull_request]
jobs:
  guard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }         # histórico completo p/ o gitleaks

      # Portão 1 — segredos
      - name: gitleaks
        uses: gitleaks/gitleaks-action@v2

      # Portão 3 — dependências
      - name: npm audit
        run: npm ci && npm audit --audit-level=high

      # Portão 2 — SAST
      - name: semgrep
        uses: returntocorp/semgrep-action@v1
        with: { config: "p/owasp-top-ten" }

      # Portão 4/6 — container & IaC
      - name: trivy (fs + config)
        uses: aquasecurity/trivy-action@master
        with: { scan-type: "fs", severity: "HIGH,CRITICAL" }

A lógica: cada passo falha o build se achar problema → o código inseguro não avança. O pipeline é o guardião.

Ordem de implantação (comece simples): primeiro secrets (Portão 1) e dependências (3) — mais impacto, menos esforço. Depois SAST (2) e branch protection (7). DAST (5) e IaC (6) quando amadurecer.

PARTE D — Labs práticos 🧪

Tudo no seu repositório. O objetivo é sair com pelo menos 2 portões rodando de verdade.

Lab 1 — gitleaks: pre-commit + varredura (🟡) — Portão 1

# instale o gitleaks e rode uma varredura do histórico:
gitleaks detect --source . --report-path leaks.json
# instale como pre-commit (bloqueia segredo antes do commit):
pip install pre-commit
# .pre-commit-config.yaml com o hook do gitleaks; depois:
pre-commit install

Lição: o próximo segredo é barrado antes de entrar (corrige a raiz do Ex. 32).

Lab 2 — Semgrep no seu código (🟢) — Portão 2

pip install semgrep
semgrep --config p/owasp-top-ten .   # regras OWASP no seu código

Observe: ele aponta padrões inseguros. Lição: SAST acha a falha na fonte (ex.: render inseguro).

Lab 3 — Dependências (🟢) — Portão 3

npm audit --audit-level=high
# no GitHub: Settings → Code security → ligar Dependabot

Lição: você vê e corrige CVEs de terceiros; o Dependabot automatiza (Ex. 34).

Lab 4 — Container scan (🟢) — Portão 4

trivy image sua-imagem:tag --severity HIGH,CRITICAL

Lição: a imagem entra no pipeline já verificada (liga ao Módulo 7).

Lab 5 — Montar o workflow e a branch protection (🟡)

Crie .github/workflows/security.yml (Parte C) e ligue branch protection na main (exige CI verde + review). Lição: agora nada inseguro chega em produção sem passar pelos portões.

PARTE E — Autoavaliação ✅

Responda de memória:

1. O que significa "shift left" e por que é melhor que testar segurança no final?
2. Qual a diferença entre SAST e DAST?
3. O que é SCA (dependency scanning) e qual ferramenta automatiza a correção?
4. Por que rodar o gitleaks como pre-commit é melhor que só no CI?
5. O que é IaC security e um exemplo do que ela pegaria?
6. Qual a regra de ouro do DevSecOps (humano × CI)?
7. Cite a ordem de implantação recomendada dos portões (por impacto/esforço).

1. Empurrar a segurança para o início do processo — achar a falha antes da produção, automaticamente. Mais barato e rápido que corrigir depois (A.1).
2. SAST lê o código-fonte parado (estático); DAST testa a aplicação rodando (dinâmico). Um pega o que o outro não vê (Portões 2 e 5).
3. Software Composition Analysis — verifica dependências de terceiros por CVEs. Dependabot abre PR de correção automático (Portão 3).
4. Porque o pre-commit barra o segredo antes de ele entrar no histórico; no CI já entrou (e o histórico é permanente) (Portão 1/Ex. 32).
5. Segurança da infra como código (Terraform/compose/manifests). Pegaria bucket público, porta de banco aberta, container privilegiado — antes de aplicar (Portão 6).
6. O humano esquece; o CI não. Automatize; não confie na memória (A.3).
7. Secrets (1) e dependências (3) primeiro; depois SAST (2) e branch protection (7); DAST (5) e IaC (6) ao amadurecer (Parte C).</details>

Checklist prático:

[ ] Rodei gitleaks no meu repo e instalei o pre-commit
[ ] Rodei Semgrep (SAST) no meu código
[ ] Rodei npm audit e liguei o Dependabot
[ ] Escaneei uma imagem com Trivy
[ ] Criei um .github/workflows/security.yml com ≥ 2 portões
[ ] Liguei branch protection na main (CI verde + review)
[ ] Entendo a diferença entre SAST, DAST, SCA e IaC scan

Conclusão: 5/7 do quiz + ≥ 2 portões rodando no seu repositório.