Três Portões

capítulo 02

Preparando o Ambiente

Setup do alvo vulnerável, dos dois workflows do GitHub Actions, e da conta no SonarCloud — tudo o que precisa existir antes de qualquer gate poder bloquear alguma coisa.

1. Fork do alvo vulnerável

O Juice Shop entra no repositório como fork + git submodule, não como cópia direta — isso preserva o histórico original e deixa claro que o código vulnerável não é nosso, é o alvo.

gh repo fork juice-shop/juice-shop --clone=false
git submodule add https://github.com/<seu-usuario>/juice-shop.git target-app
git commit -m "Add OWASP Juice Shop fork as submodule (target-app)"
git push

2. Validar localmente via Docker, antes de automatizar

Antes de escrever qualquer workflow, confirme que o alvo sobe e responde:

docker run --rm -p 3000:3000 bkimminich/juice-shop

Abra http://localhost:3000 e confirme que a tela de login do Juice Shop carrega.

porta ocupada?

Se a porta 3000 já estiver em uso na sua máquina por outro serviço, use outra porta local (-p 3001:3000) — isso não afeta em nada o pipeline real, porque os runners do GitHub Actions são isolados e não têm esse conflito.

3. Gitleaks: pre-commit + config

Duas peças: o hook local (roda antes de cada commit na sua máquina) e o arquivo de configuração/allowlist.

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
pipx install pre-commit
pre-commit install

O .gitleaks.toml estende as regras padrão do Gitleaks e documenta qualquer exceção necessária — ver capítulo 04 pra um caso real de exceção justificada.

4. SonarCloud: conta, projeto e token

  1. Login em sonarcloud.io via Log in → With GitHub.
  2. + (Analyze new project) → selecionar o repositório.
  3. Em My Account → Security, gerar um token.
  4. No repositório GitHub: Settings → Secrets and variables → Actions → novo secret SONAR_TOKEN.
  5. Em Project Settings → New Code, escolher Number of days (30) como critério de código novo — não "Previous version", porque este repositório não tem processo formal de releases/tags.
sonar.projectKey=<org>_secure-pipeline-poc
sonar.organization=<org>
sonar.exclusions=target-app/**
por que excluir target-app/

O Juice Shop já tem vulnerabilidades conhecidas de propósito e não é "nosso" código — o gate deve avaliar o que a gente escreve no pipeline, não o alvo.

5. OWASP ZAP: regras

O arquivo de regras controla o que escala pra FAIL, o que fica em WARN, e o que é ignorado — mais sobre como isso realmente se comporta no capítulo 04.

# Formato: <rule id>  <threshold>  (descrição)
# IGNORE = não reporta | WARN = reporta mas não falha | FAIL = reporta e falha o job
10038   FAIL   (CSP Header Not Set)

6. Os dois workflows

Com o alvo, o Gitleaks, o SonarCloud e o ZAP configurados, faltam só os workflows que os conectam ao ciclo de vida do código — pre-merge-gates.yml (Gitleaks + SonarCloud, em toda PR) e pre-deploy-dast.yml (ZAP, disparo manual). O conteúdo completo de cada um, e o porquê de cada escolha dentro deles, está no capítulo 03.