🧠FFVAcademy
🛡️

Segurança de Software de Verdade: threat model ao SBOM

19 min de leitura·+90 XP
Pré-requisitos (0/1)0%

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

Segurança não é dept de outra pessoa. É propriedade do código. Em 2026, com agents gerando muito código e stack distribuída por 10 vendors, atacar vira mais barato que defender. A boa notícia: as ferramentas para shift-left (prevenir em design/code) e shift-right (detectar em runtime) amadureceram. Este módulo monta o mínimo que uma pessoa sênior deve operar — sem viramentação de cerimônia.

O modelo mental (Defense in Depth)

🗺️ Camadas que se defendem em sequência
🎨Designthreat model
STRIDE, MITRE ATT&CK. Pense em ataques antes de codar.
informa
⌨️Codeshift-left
Linter de segurança, SAST, secret scanner em pre-commit.
valida
🤖CIgates
SAST completo, SBOM, dependency audit, container scan.
blinda
🚀Deployleast privilege
IAM mínimo, network policy, secrets via vault, image signing.
observa
👁️Runtimeshift-right
WAF, IAST, RASP, anomaly detection, SIEM.
responde
🚨Incidentprepared
Runbook, comunicação, forense, postmortem, lições pro threat model.

Threat Modeling com STRIDE

Em reunião de design (30 min), pegue cada fluxo novo e passe a régua STRIDE. Para cada componente do diagrama, pergunte:

SiglaAmeaçaExemploMitigação típica
SSpoofingAtacante se passa por usuário ou serviçoAuth forte (MFA, mTLS), identidade verificada
TTamperingDados ou binário alterados em trânsito ou repousoHTTPS, HMAC, assinatura, integridade
RRepudiationUsuário nega ter feito uma açãoAudit log imutável, assinatura de ação
IInformation disclosureVazamento de dado sensívelCriptografia, mascaramento, mínimo privilégio
DDenial of serviceIndisponibilidade por ataqueRate limit, WAF, autoscaling, circuit breaker
EElevation of privilegeBaixo → alto privilégioRBAC rigoroso, sandbox, patches
💡
Quem escreve. Engenheiro responsável pela feature, em doc curto junto da spec (ver módulo SDD). Revisor do PR checa que ameaças relevantes foram endereçadas. Não é papel isolado de security team — é parte do design.

OWASP Top 10 (2021, ainda vigente) em PT-BR

A01 Broken Access ControlAutorização falha (IDOR, path traversal, admin acessível sem papel). Hoje é o #1 em bug bounty. Teste específico pra autorização — não confie em "o front esconde o botão".
A02 Cryptographic FailuresUso errado de crypto: ECB, MD5 em senha, JWT sem validar assinatura, HTTPS opcional. Use libs de alto nível (libsodium, Web Crypto), nunca implemente crypto.
A03 InjectionSQLi, NoSQLi, command injection, LDAP, XPath, prompt injection. Prepared statements, ORM com parâmetros, validação + sanitização.
A04 Insecure DesignFalha conceitual (sem MFA, sem rate limit, senha em logs). Threat modeling + revisão de arquitetura.
A05 Security MisconfigurationDefault credential, diretório indexado, header sem CSP/HSTS, admin panel exposto. Harden por default, security headers obrigatórios.
A06 Vulnerable ComponentsDep conhecida vulnerável. Dependabot, Snyk, Trivy. SBOM obrigatório.
A07 Auth FailuresSessão sem expiração, CSRF, brute force não limitado, recuperação de senha vulnerável. Use auth as a service (Auth0, Clerk, Cognito) quando possível.
A08 Software & Data IntegrityCI/CD inseguro, update não assinado, deserialization inseguro. SLSA, Sigstore, pickle banido para input externo.
A09 Logging & MonitoringSem log, sem alerta, tempo de detecção alto. Log estruturado + SIEM + detecção de anomalia.
A10 SSRFServer-Side Request Forgery. App busca URL que atacante escolheu (metadata IMDS, rede interna). Allowlist de destinos, bloquear IPs privados.

Secrets: onde eles morram

🏛️Vault centralsource of truth
AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Azure Key Vault.
acessado por
🪪Identidade efêmerasem chave estática
IAM role em runtime, OIDC/WIF em CI. Token vive minutos.
injeta em
📦App em runtimelê em memória
Nunca persiste em disco fora de tmpfs. Rotação periódica.
audita
📜Audit + Rotaçãocron
Rotação 30-90 dias. Acesso logado. SIEM monitora padrão anômalo.
bash
# Pre-commit hook: trufflehog ou gitleaks bloqueia secret antes do commit
# .pre-commit-config.yaml
- repo: https://github.com/gitleaks/gitleaks
  rev: v8.18.0
  hooks:
    - id: gitleaks

# CI
- name: Scan for secrets
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

# Em runtime (Node + AWS)
import { SecretsManagerClient, GetSecretValueCommand } from '@aws-sdk/client-secrets-manager';
const client = new SecretsManagerClient({ region: 'us-east-1' });
const secret = await client.send(new GetSecretValueCommand({ SecretId: 'prod/db/password' }));
// nunca console.log(secret), nunca persiste em disco
🚨
Red flags. (1) .env no repo. (2) console.log(process.env) em dev deixado em prod. (3) Secret como variável de build que fica no histórico do Docker (--build-arg com senha → use --secret). (4) Token de service account com TTL infinito.

Supply Chain: SBOM, SLSA, Sigstore

SBOM (Software Bill of Materials)Lista de cada dependência direta e transitiva com versão e hash. Formatos: SPDX, CycloneDX. Gere em build (syft, cdxgen) e publique com o artefato.
SLSA (Supply-chain Levels for SA)Framework do Google. Níveis 1-4 de garantia (source → build → provenance → two-party). SLSA 3+ é objetivo de org séria.
Sigstore / cosignAssinar imagem Docker, artefato, módulo Go. Verificação na hora do deploy.
SHA pinningGitHub Actions, container images, npm: fixar por SHA imutável, não por tag. Tag pode ser reassinada.
Dependency auditDependabot, Snyk, Trivy, Grype. Falha no CI em vuln HIGH+. Auto-PR para bump.
Rotina de revisãoLer dependências novas no PR (quem mantém? popularidade? últimos commits?). Agent security-review do módulo anterior ajuda.
bash
# Gerar SBOM
syft packages dir:. -o cyclonedx-json > sbom.json

# Scan de vuln contra SBOM
grype sbom:./sbom.json --fail-on high

# Assinar imagem Docker
cosign sign --key cosign.key ghcr.io/empresa/app:${SHA}

# Verificar na hora do deploy (policy de admission)
cosign verify --key cosign.pub ghcr.io/empresa/app:${SHA}

SAST, DAST, IAST, SCA

TipoOndeO que pegaFerramenta
SASTCódigo (static)SQLi, XSS, command injection via taint analysisCodeQL, Semgrep, SonarQube
DASTApp rodando (black-box)Vulns expostas via HTTP: XSS, injection, configZAP, Burp Suite, Nuclei
IASTApp rodando (instrumentado)Vulns reais com contexto de runtimeContrast, Seeker
SCADependênciasCVE em lib usadaSnyk, Dependabot, Trivy, Grype
FuzzCódigo + inputCrash, UAF, overflow em parserAFL, libFuzzer, go-fuzz, OSS-Fuzz
Secret scanRepo + commitsToken/chave esquecidosgitleaks, trufflehog
Container scanImagem DockerVuln em base image e bináriosTrivy, Grype, Snyk Container
Infra scanIaC (Terraform, K8s)Config errada, permissão frouxaCheckov, tfsec, kubescape

Headers e defesas padrão

http
# Headers mínimos em toda resposta HTTP (API ou web)
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-site
💡
Ferramenta. Rode https://securityheaders.com ou observatory.mozilla.org contra seu domínio. Grau A é pré-requisito.

Autenticação e autorização sem dor

SenhaArgon2id (OWASP recomenda) com salt por usuário. Nunca MD5/SHA1.
MFATOTP (Authy, Google Authenticator) + WebAuthn/Passkey como meta final.
SessãoCookie Secure + HttpOnly + SameSite=Lax/Strict. Expiração curta + rotation.
JWTAssinado com RS256 ou EdDSA (nunca HS256 com secret compartilhado). Expira em minutos. Refresh token com rotation.
OAuth2/OIDCUse provider (Auth0, Clerk, Cognito, Keycloak). Nunca implemente flow do zero.
AutorizaçãoABAC/RBAC bem desenhado. Teste IDOR em TODOS endpoints (usuário A tenta acessar recurso de B).

Dois cenários reais

📋 API nova de saúde com dados sensíveis (LGPD/PII)

Threat model + Vault + SAST + SBOM + audit log + Data at Rest/Transit

Stack completa: STRIDE no design; AWS Secrets Manager + KMS; CodeQL no CI; SBOM publicado com artefato; audit log com HMAC de encadeamento (não-repúdio); TLS 1.3 e criptografia de coluna sensível no DB.

📋 Microserviço interno que consome webhook de parceiro

HMAC + Idempotency + Rate Limit + WAF + Fuzz no parser

Input externo → trate como hostil. Validar HMAC do payload, idempotency-key, rate limit por parceiro, WAF bloqueia pattern conhecido, fuzz no parser do JSON/XML garante que input malicioso não quebra.

Checklist de go-live de segurança

  • ✔ Threat model existe e foi revisado.
  • ✔ Secrets em vault + rotation + audit.
  • ✔ SAST sem HIGH/CRITICAL aberto.
  • ✔ SBOM gerado e publicado. SCA sem HIGH+ aberto.
  • ✔ Headers de segurança grau A.
  • ✔ Auth com MFA; sessão com expiração.
  • ✔ RBAC testado via testes de IDOR.
  • ✔ Rate limit + WAF em endpoints públicos.
  • ✔ Log estruturado + alerta em eventos críticos (login falho em massa, 5xx spike).
  • ✔ DR plan testado nos últimos 90 dias.
  • ✔ Runbook de incidente + contato responsável.
  • ✔ SLO e error budget conhecido.

Perguntas típicas

Preciso de time de segurança dedicado?

Ajuda a partir de ~30 devs. Abaixo disso: 1 engenheiro sênior como security champion por time + parceiro externo pra pentest anual. Com agents modernos, um dev bom cobre 80% do que um júnior de security fazia.

Pentest anual é suficiente?

Não em 2026. Pentest anual pega a superfície atual. Dev frequente de features muda a superfície toda semana. SAST/DAST contínuo + bug bounty + threat model em cada feature nova é o mínimo pra org que mexe em dados sensíveis.

Como lidar com CVE em dep sem fix?

Avaliar exploração real no seu contexto (CVSS não é tudo). Opções: pinar em versão segura, fork/patch temporário, isolar em processo/rede separada, remover a dep. Se nada serve, documentar risco aceito com validade.

Agent pode fazer review de segurança?

Pode (vimos o security-review agent no módulo anterior). Mas é complemento, não substituto. Humano sênior vê o que agent não vê: contexto do negócio, lógica sutil, ataque encadeado. Use os dois.

Certificações valem a pena?

CISSP/OSCP são sinais fortes pra profissionais de segurança dedicados. Pra dev: leia o OWASP Top 10, faça um CTF (picoCTF, HackTheBox) e entenda threat model. Vale mais que certificado.
Take-aways. (1) Segurança é responsabilidade do dev sênior — não do "time de segurança". (2) Threat model rápido em cada feature é barato e evita desastre. (3) Secrets em vault com identidade efêmera é inegociável em 2026. (4) Supply chain (SBOM, SHA pin, signing) virou tão crítico quanto código próprio. (5) SAST/DAST/IAST/SCA/Fuzz cada um pega uma classe distinta — use em combinação. (6) Próximo e último: arquitetura moderna.
🧩

Quiz rápido

4 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito

Continue lendo