pentest-supply-chain

name

pentest-supply-chain

description

Pentest de supply chain, CI/CD e infraestrutura — SCA/CVE, typosquatting, malicious postinstall, GitHub Actions (pinning por SHA, permissões, script injection, pwn-request), Docker (imagem base, rootless, secrets em layer), lockfile poisoning, SBOM, gestão de secrets e GitOps. TRIGGERS: supply chain, sca, cve, github actions security, docker security, sbom, dependabot, codeql, typosquat, postinstall malicious, lockfile, pin dependencies, renovate, secret management

🔗 pentest-supply-chain — Auditoria Ofensiva de Supply Chain & CI/CD

Supply chain é o vetor de crescimento mais rápido (ex: SolarWinds, event-stream, xz-utils). Foco: código que roda antes do seu código.

Required Reading

• package.json (raiz + todas as libs)
• pnpm-lock.yaml / package-lock.json
• .github/workflows/*.yml
• .github/dependabot.yml, renovate.json
• Dockerfile*, docker-compose*.yml
• .npmrc, .yarnrc.yml, .pnpmfile.cjs
• .env*, .envrc
• .gitignore

---

1. Dependências (SCA)

CVE scanning

pnpm audit --audit-level=moderate --json > .pentest/audit.json
pnpm dlx osv-scanner --lockfile pnpm-lock.yaml --format json --output .pentest/osv.json
pnpm dlx retire --outputformat json --outputpath .pentest/retire.json
# Snyk opcional (requer auth): pnpm dlx snyk test --json > .pentest/snyk.json

• Zero critical/high com fix disponível
• prod dependencies têm zero vulnerabilidades exploráveis
• Transitivas auditadas (não só diretas) — osv-scanner cobre isso

Typosquatting / packages maliciosos

pnpm dlx npq install --dry-run || true   # verifica reputation
pnpm dlx socket-security < package.json

Red flags manuais:

• Pacote muito novo (< 30 dias) com nome parecido com lib conhecida (lodaash, react-natve)
• Autor diferente do mainline (@types/xxxx oficial é @types)
• postinstall/preinstall scripts em libs que não deveriam executar nada

rg -l "\"postinstall\"|\"preinstall\"" node_modules/**/package.json 2>/dev/null | head -30

Lockfile integrity

• Lockfile commitado (pnpm-lock.yaml / package-lock.json / yarn.lock)
• CI roda pnpm install --frozen-lockfile (ou npm ci)
• .npmrc com auto-install-peers=true + registry=https://registry.npmjs.org/ explícito (impede hijack via scope proxy)
• Sem .npmrc com //registry/...:_authToken=<valor> commitado — usar ${NPM_TOKEN}

cat .npmrc 2>/dev/null
rg -n "_authToken|_auth" .npmrc .yarnrc .yarnrc.yml 2>/dev/null

Version pinning

rg -n '"[\^~][0-9]' package.json libs/*/*/package.json apps/*/package.json

• Libs críticas (auth, crypto, payments, JWT) fixadas sem ^/~
• engines.node com range estreito (ex: "node": ">=20 <21")
• packageManager fixado ("packageManager": "pnpm@9.10.0")
• Renovate/Dependabot configurado com schedule e auto-merge apenas de patches

---

2. GitHub Actions

Pinning por SHA

rg -n "uses: .+@v[0-9]" .github/workflows/
rg -n "uses: .+@(main|master|develop)" .github/workflows/   # CRITICAL

• Toda uses: de 3rd party fixada por SHA de 40 chars (@a1b2c3d4...)
• Ações do GitHub (actions/checkout) podem usar tag major, mas preferir SHA
• Sem @main/@master jamais (branch mutável = RCE delegado)

Permissions

rg -n "permissions:" .github/workflows/ -A 8

• Workflow começa com permissions: {} (least privilege) e libera só o necessário
• contents: write só em release; demais jobs contents: read
• id-token: write só quando usa OIDC
• GITHUB_TOKEN não é passado para scripts de terceiros sem necessidade

Script Injection (pwn-request, issue/PR titles)

rg -n "\$\{\{\s*github\.event\." .github/workflows/

Padrão perigoso:

- run: echo "${{ github.event.pull_request.title }}"   # injection se título = `"; rm -rf /; "`

Fix:

env:
  TITLE: ${{ github.event.pull_request.title }}
run: echo "$TITLE"

pull_request_target

• Nenhum workflow usa pull_request_target + checkout do código do PR (RCE trivial em fork)
• Se usar, não executar código do PR com GITHUB_TOKEN privilegiado

rg -n "pull_request_target" .github/workflows/ -A 20

Secrets

• Secrets usados via ${{ secrets.X }} apenas em jobs necessários
• Sem echo ${{ secrets.X }} (vaza em log)
• OIDC → AWS/GCP/Azure em vez de access keys estáticas
• Environments com required reviewers para production

CodeQL / Security scanning

ls .github/workflows/ | rg -i "codeql|security|scorecard"

• codeql-analysis.yml ativo para javascript-typescript
• OSSF Scorecard (scorecard.yml) rodando semanal
• Dependabot security updates habilitado
• Branch protection: reviews obrigatórias + status checks + signed commits

---

3. Docker / Containers

rg -n "FROM " Dockerfile* apps/*/Dockerfile*
rg -n "USER " Dockerfile* apps/*/Dockerfile*
rg -n "ADD " Dockerfile*   # preferir COPY

Imagem base

• Tag imutável (SHA: node@sha256:...) — nunca :latest
• Distroless ou Alpine para prod; distro completa só em builder stage
• Multi-stage build — runtime não contém npm/git/curl
• Base image atualizada (verificar CVE com trivy image)

User / Filesystem

• USER node (não-root) em runtime
• --read-only no container + tmpfs para /tmp
• HEALTHCHECK definido
• NODE_ENV=production

Secrets

• Nenhum ENV SECRET=xxx no Dockerfile (fica em layer)
• Sem COPY .env . (usar BuildKit secret mount: --mount=type=secret)
• .dockerignore inclui .env, node_modules, .git, *.pem

cat .dockerignore 2>/dev/null
rg -n "^ENV\s+.*(SECRET|KEY|TOKEN|PASSWORD)" Dockerfile*
rg -n "COPY \.env" Dockerfile*

Scan

docker scout cves <image> || true
pnpm dlx @anchore/syft <image> -o spdx-json > .pentest/sbom.json || true
pnpm dlx @anchore/grype <image> -o json > .pentest/grype.json || true
trivy image --severity HIGH,CRITICAL <image> || true

---

4. SBOM (Software Bill of Materials)

• SBOM gerado a cada release (CycloneDX ou SPDX)
• SBOM publicado com a release (GitHub Release asset) + assinatura
• Sigstore/cosign para assinatura de artefatos

pnpm dlx @cyclonedx/cyclonedx-npm --output-file .pentest/sbom.cdx.json

---

5. Secret Management

Gitleaks / detect-secrets

gitleaks detect --source . --no-git --report-format json --report-path .pentest/gitleaks.json
pnpm dlx @secretlint/secretlint --format json '**/*' > .pentest/secretlint.json

Regex patterns adicionais

rg -n "AKIA[0-9A-Z]{16}" .
rg -n "ASIA[0-9A-Z]{16}" .
rg -n "ghp_[A-Za-z0-9]{36}" .
rg -n "github_pat_[A-Za-z0-9_]{82}" .
rg -n "xox[baprs]-[A-Za-z0-9-]+" .
rg -n "-----BEGIN (RSA |EC |OPENSSH )?PRIVATE KEY-----" .
rg -n "sk_live_[A-Za-z0-9]{24,}" .   # Stripe live key
rg -n "SG\.[A-Za-z0-9_-]{22}\.[A-Za-z0-9_-]{43}" .   # SendGrid
rg -n "AIza[0-9A-Za-z_-]{35}" .   # Google API

Runtime secret manager

• Usa AWS Secrets Manager / GCP Secret Manager / HashiCorp Vault / Doppler
• .env apenas em dev; prod injeta por variável no runtime
• Rotation automática para credenciais sensíveis
• @nestjs/config com schema Zod/Joi validando env em startup

Se encontrar secret vivo

🚨 Sempre instruir no relatório:

1. Revogar no provider imediatamente (AWS: IAM; GitHub: settings/tokens; Stripe: dashboard)
2. Rotacionar com novo valor
3. Auditar logs do provider buscando uso não-autorizado
4. Remover do histórico git com git filter-repo (não git filter-branch)
5. Force-push com aviso à equipe; considerar repositório comprometido

---

6. Git History

git log --all --source --full-history -p --diff-filter=D -- '**/.env*' 2>/dev/null | head -100
git log --all -S'BEGIN RSA PRIVATE KEY' --oneline 2>/dev/null

• Nenhum secret no histórico (mesmo que removido no HEAD)
• .gitignore robusto: .env*, *.pem, *.p12, firebase-adminsdk*.json, *.mobileprovision
• Hooks pre-commit (husky + gitleaks-protect ou pre-commit framework) instalados

---

7. Branch Protection / GitOps

• main/master com branch protection: 2 reviews + status checks + signed commits + linear history
• Deploy apenas via tag assinada
• Rollback documentado
• Nenhum segredo em PRs de fork (Actions com pull_request em vez de pull_request_target)

---

8. Outros

.env local em node_modules publicado

Libs internas publicadas em registry privado devem ter files: no package.json limitando o que vai no tarball.

rg -n "\"files\":" libs/*/*/package.json apps/*/package.json

Prebuild scripts

rg -n "\"(pre|post)?(install|build|test|publish)\":" package.json

Scripts que rodam durante pnpm install devem ser auditados — são vetor de RCE.

---

Output Snippet

### 🔗 Supply Chain & CI/CD — N findings

| ID | Sev | CWE | File:Line | Issue |
|----|---|---|---|---|
| S-001 | 🔴 Critical | CWE-798 | .github/workflows/deploy.yml:42 | Secret `AWS_ACCESS_KEY_ID` em log (`echo ${{ secrets.X }}`) |
| S-002 | 🟠 High | CWE-829 | .github/workflows/ci.yml:14 | Action `foo/bar@main` sem SHA pinning |
| S-003 | 🟠 High | CWE-937 | package.json | lodash 4.17.19 — CVE-2021-23337 (command injection) |
| S-004 | 🟡 Medium | CWE-693 | Dockerfile | Runtime como root (falta `USER`) |

Anti-patterns a SEMPRE reportar

• uses: x/y@main|@master em workflow
• pull_request_target + checkout de branch do PR
• ${{ github.event.*.title }} / .body direto em run:
• ENV SECRET= / COPY .env em Dockerfile
• Rodar container como root em prod
• :latest em imagem base ou Compose
• .npmrc com token commitado
• postinstall em dep direta nova/desconhecida
• Ausência de dependabot.yml ou renovate.json
• Branch main sem proteção