Matriz de Riscos¶

Este documento consolida os riscos do projeto Quorum (quorum-sec-scan, v0.8.3) — uma ferramenta de consensus security scanning CLI/Docker — organizados por categoria (Técnico, Negócio, Segurança, Operação, Infraestrutura, Financeiro, Legal, além da camada Consultiva/IA opt-in). Para cada risco há um ID, descrição, probabilidade, impacto, severidade (calculada pela matriz), mitigação, responsável e status. O foco recai sobre riscos que são reais e verificáveis no código: dependência das versões/saídas dos 12 scanners externos, supply chain, indisponibilidade do OSV.dev, cobertura parcial do crosswalk de consenso, falsos negativos por mount/config errado, envelhecimento do banco do Grype, exaustão de recursos (DoS), bus factor de manutenção do OSS e — apenas quando a camada consultiva opt-in está habilitada — riscos específicos de IA.

Referências de código verificadas para este documento: README.md, DESIGN.md (§6 correlação, §7 alias, §8 crosswalk, §9 consenso, §12 supply chain, §14 riscos), internal/orchestrator/orchestrator.go, internal/adapter/ (12 adapters), internal/alias/osv.go, cmd/quorum/scan.go, internal/advisor//internal/enrich//internal/rag/ (camada consultiva), crosswalk/aws.yaml/azure.yaml/gcp.yaml/k8s.yaml, action.yml, Dockerfile.full, .goreleaser.yaml, .github/workflows/release.yml, .github/workflows/tag-major.yml. Link interno: 01 — Visão Geral.

Escopo (N/A explícito). O Quorum é apenas CLI/Docker: não há frontend web, banco de dados relacional, API REST HTTP nem autenticação/contas de usuário. O núcleo determinístico não tem IA; uma camada consultiva opt-in (--advice) adiciona uma camada de apresentação com LLM local/remoto que fica desligada por padrão e nunca toca em correlationKey/fingerprint/confidence/severidade agregada/o gate fail-on (sem --advice, a saída é byte-a-byte idêntica). Por isso, classes inteiras de risco típicas de aplicações server-side — injeção em endpoints HTTP, vazamento de PII de um banco de dados, comprometimento de sessão/autenticação, DDoS de serviço, custo de nuvem em runtime — são tratadas como N/A com justificativa técnica (ver §10 Riscos N/A). Os riscos catalogados refletem a arquitetura as-is: um orquestrador stateless que faz shell-out para scanners OSS e roda em pipelines CI/CD.

1. Metodologia¶

1.1 Escalas¶

Probabilidade (P) — chance de o risco se materializar em um horizonte de operação de ~12 meses:

Nível	Rótulo	Critério
1	Raro	Improvável; depende de um evento externo incomum
2	Baixa	Pode ocorrer, mas não é esperado
3	Média	Plausível dentro do ciclo normal de uso
4	Alta	Espera-se que ocorra ao menos uma vez
5	Quase certo	Recorrente / contínuo por natureza

Impacto (I) — consequência caso o risco se materialize:

Nível	Rótulo	Critério
1	Insignificante	Cosmético; sem efeito no resultado do scan
2	Menor	Degradação localizada; contornável
3	Moderado	Falha parcial; resultado menos confiável, mas detectável
4	Severo	Falso negativo silencioso ou gate de CI incorreto
5	Crítico	Comprometimento de supply chain / decisão de segurança errada em produção

1.2 Severidade (matriz P × I)¶

Severidade é o produto P × I, classificado em faixas:

Faixa (P×I)	Severidade	Ação esperada
1–4	🟢 Baixa	Aceitar / monitorar
5–9	🟡 Média	Mitigar quando viável; revisar periodicamente
10–14	🟠 Alta	Mitigação ativa necessária; owner nomeado
15–25	🔴 Crítica	Mitigação prioritária; bloqueia "production-ready"

1.3 Mapa de calor (textual)¶

Cada célula lista os IDs de risco cuja combinação (P, I) cai ali. Ver o catálogo nas seções 2–9.

            IMPACTO →
            1(Insig)   2(Menor)      3(Moder)           4(Severo)          5(Crítico)
P  5 ┃        ·          ·             T-01               T-02,O-01          ·
R  4 ┃        ·          T-06,T-07     S-03,O-02          T-03,T-04,S-04     S-01
O  3 ┃        ·          N-02,A-01     T-05,N-01,S-05     S-02,I-01,O-03     L-01
B  2 ┃        ·          F-02,A-04     L-02,I-02,A-03     F-01,I-03,A-02,A-05  ·
.  1 ┃        ·          ·             ·                  N-03               ·
     ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      Legenda de severidade:  🟢 baixa(≤4)  🟡 média(5–9)  🟠 alta(10–14)  🔴 crítica(≥15)

quadrantChart
    title Risco — Probabilidade x Impacto
    x-axis "Baixo impacto" --> "Alto impacto"
    y-axis "Baixa prob." --> "Alta prob."
    quadrant-1 "Crítico (mitigar já)"
    quadrant-2 "Monitorar prob."
    quadrant-3 "Aceitar / monitorar"
    quadrant-4 "Mitigar impacto"
    "T-02 saída de scanner": [0.78, 0.92]
    "T-03 crosswalk parcial": [0.80, 0.80]
    "T-04 falso merge MISCONFIG": [0.78, 0.80]
    "S-01 supply chain de scanner": [0.95, 0.80]
    "S-04 mount errado": [0.80, 0.78]
    "S-05 grype DB desatualizado": [0.62, 0.62]
    "T-07 DoS saída/alvo enorme": [0.55, 0.40]
    "O-01 0 findings = seguro": [0.92, 0.95]
    "S-02 pular verificação de assinatura": [0.62, 0.60]
    "T-01 OSV indisponível": [0.55, 0.90]
    "I-03 queda GHCR/Actions": [0.78, 0.35]
    "L-01 bus factor OSS": [0.62, 0.58]
    "A-02 vazamento egress remoto": [0.65, 0.30]
    "A-01 conselho alucinado": [0.40, 0.35]

2. Riscos Técnicos¶

Relacionados à correção do produto, dependência da saída dos 12 scanners (trivy, grype, checkov, kics, dockle, kubescape, polaris, kube-score, terrascan, tfsec, regula, conftest), correlação e consenso.

ID	Descrição	P	I	Sev	Mitigação	Responsável	Status
T-01	OSV.dev indisponível ou lento durante a resolução de alias (CVE↔GHSA). Sem resolução, o mesmo bug reportado como `GHSA-…` (Grype) e `CVE-…` (Trivy) pode virar dois findings e quebrar o consenso VULN.	3	5	🟠 15→Alta (teto de faixa)	Graceful degradation já implementada (`DESIGN.md` §7): falha de rede ⇒ usa o id como está, nunca derruba o scan. Cache local (`~/.cache/quorum/aliases.json`, perm `0600` + `schemaVersion`) reduz a dependência. `--offline` desabilita o OSV de forma determinística. Aliases locais ao finding (Grype `relatedVulnerabilities`) cobrem parte dos casos sem rede. Id validado e `url.PathEscape` na chamada (`osv.go`).	Core / Alias	Mitigado (residual: sub-merge VULN com rede ruim)
T-02	Mudança no formato de saída de um scanner externo (qualquer dos 12 altera JSON/SARIF entre versões), quebrando o parser do adapter e produzindo findings ausentes ou malformados. Risco residual central do produto.	5	4	🔴 20 Crítica	Teste de contrato por adapter contra fixtures versionadas da saída real (`internal/adapter/testdata`, `realdata_test.go`, `DESIGN.md` §5); o teste quebra antes da produção. Pinning de versão de scanner por `@sha256` na imagem `:full` (`Dockerfile.full`). Atualizar fixtures a cada bump de versão. Cobertura de testes exigida no CI.	Adapters	Mitigado (detecção no CI)
T-03	Cobertura parcial do crosswalk de consenso. Os mapeamentos em `crosswalk/{aws,azure,gcp,k8s}.yaml` foram derivados de saída real de scanner (não mais ilustrativos), mas cobrem um subconjunto de controles (AWS S3/IAM/EBS/SG/RDS/KMS/CloudTrail/VPC-flow-logs; Azure Storage/Key Vault; GCP bucket/firewall/SQL; K8s C-#### de kubescape × polaris × kube-score). Um controle fora do mapa permanece isolado (sem consenso), não errado.	4	4	🔴 16 Crítica	Regra "na dúvida, não fundir": um controle não mapeado permanece `unmapped`, nunca chutado (false split > false merge, `DESIGN.md` §6) — a falha é segura. Mapeamentos com IDs reais (AVD nativo do Trivy, UUIDs do KICS, C-#### do kubescape) checados semanticamente contra a saída. `tfsec` auto-correlaciona com `trivy` (emite AVD nativo). Crosswalk plugável via `--crosswalk`. K8s RBAC permanece single-engine (RBAC do kubescape exige contexto de cluster) — documentado.	Crosswalk / Conteúdo	Parcialmente mitigado (expandir cobertura para prod)
T-04	*Falso merge* (over-merge) em MISCONFIG.** Por uma limitação conhecida, MISCONFIG correlaciona por `basename(file) + resourceType + canonicalControl`; dois recursos distintos do mesmo tipo com o mesmo controle no mesmo arquivo podem se fundir (`README.md` "Known limitations").	4	4	🔴 16 Crítica	O princípio de design false split > false merge mitiga o inverso (não funde por padrão), mas este caso específico é um trade-off aceito e documentado. Identidade por recurso planejada para um release futuro.	Core / Correlate	Aberto (limitação documentada)
T-05	Confiança mal calibrada (`confidence`). A fórmula pondera número de engines (log), diversidade de categoria, severidade e confirmação autoritativa (`DESIGN.md` §9); pesos fixos podem priorizar mal em domínios específicos, agora com mais engines contribuindo por finding.	3	3	🟡 9 Média	Score determinístico e auditável; `detectedBy`/`detectionCount` expostos no relatório para o humano reavaliar. A contagem bruta deliberadamente não é confiança. Pesos versionáveis.	Consenso	Monitorar
T-06	*Timeout por scanner / probe* de versão mal dimensionado.** Probe padrão 60s (`defaultProbeTime`) e `--timeout` 5m; com 12 scanners no fan-out, em um runner lento/saturado um scanner saudável pode ser marcado `unavailable`/`timeout`.	4	2	🟡 8 Média	Probe generoso (60s) e distingue timeout/killed(OOM)/não-instalado com mensagens acionáveis (`orchestrator.go`, `runOne`). `ProbeTime`/`PerScannerTime` configuráveis; `--scanners` escopa o pool. Status sempre reportado (transparência).	Orchestrator	Mitigado
T-07	Exaustão de memória por saída ou alvo enorme (DoS). Um scanner despejando um JSON/SARIF gigantesco, ou um alvo muito grande (repo/manifesto), pode estourar a RAM do processo/runner no fan-out paralelo.	4	2	🟡 8 Média	Limites de DoS já implementados: leitura de saída limitada por `QUORUM_MAX_OUTPUT_BYTES` (padrão 512 MiB, aborta com erro acionável em vez de OOM — `adapter.go`) e tamanho do alvo em disco limitado por `QUORUM_MAX_TARGET_BYTES` (padrão 20 GiB — `scan.go`). Ambos ajustáveis/desabilitáveis via env.	Adapters / Orchestrator	Mitigado

3. Riscos de Negócio¶

ID	Descrição	P	I	Sev	Mitigação	Responsável	Status
N-01	Proposta de valor não compreendida ("é só mais um wrapper de scanner"). O diferencial é a camada de correlação + consenso (agora ativa em SCA e MISCONFIG/K8s via crosswalk), não a detecção.	3	3	🟡 9 Média	Posicionamento claro na doc: "não é só mais um scanner" (`README.md`, 01 — Visão Geral). Exemplo de `detectionCount`/`confidence` no topo do README. Doc publicada no GitHub Pages (MkDocs Material).	Produto / Docs	Mitigado
N-02	Baixa adoção por fricção de instalação de múltiplos scanners (agora 12).	3	2	🟡 6 Média	Imagem `:full` autocontida (todos os 12 scanners embutidos) + GitHub Action composite (`uses:`) elimina a instalação. Modo `:slim` para quem já tem scanners no PATH.	Distribuição	Mitigado
N-03	Concorrência / sobreposição com plataformas ASPM SaaS.	1	4	🟢 4 Baixa	Nicho deliberado: leve, plugável, CLI/Docker, sem lock-in, sem dashboard/daemon. Complementa (produz SARIF para GitHub code scanning / DefectDojo) em vez de competir.	Produto	Aceitar

4. Riscos de Segurança¶

ID	Descrição	P	I	Sev	Mitigação	Responsável	Status
S-01	*Comprometimento de supply chain* via binários de scanner embutidos** na imagem `:full`. Os 12 binários fazem parte do trust boundary do usuário; houve um incidente de supply chain em Actions de scanner em 2026 (`DESIGN.md` §12).	4	5	🔴 20 Crítica	Endurecido no código: cada ferramenta é agora obtida via checksum verificado/`@sha256` no build (`trivy`/`kics` por digest de imagem; `dockle`/`kubescape`/`polaris`/`kube-score`/`tfsec`/`terrascan`/`regula`/`conftest` via `sha256sum -c`; grype/syft via instaladores oficiais com checksum verificado) e imagens base fixadas por sha256 (`Dockerfile.full`). Imagens/binários do Quorum assinados keyless com cosign (OIDC, com retry) + atestação de build-provenance SLSA e SBOM SPDX atestado (`actions/attest-build-provenance`, `actions/attest-sbom`, BuildKit `sbom:true`), verificados de ponta a ponta dentro do próprio release (`release.yml`, `.goreleaser.yaml`). O knowledge pack + crosswalk recebem sua própria atestação de build-provenance SLSA a cada release (job `knowledge`). A Action composite verifica a imagem com cosign antes de rodar (`action.yml`).	Supply chain / Release	Mitigado (residual: confiança nos publishers dos scanners)
S-02	Usuário não verifica a assinatura/atestação antes de rodar a imagem/binário, aceitando um artefato adulterado.	3	4	🟠 12 Alta	`cosign verify`, `gh attestation verify` (imagens, binários e knowledge pack) documentados no README; a tag móvel `v0` (auto-avançada por `tag-major.yml`) recomenda fixar por `@<sha>` em produção. Verificação padrão na Action composite.	Docs / Release	Mitigado (ação a cargo do usuário)
S-03	Vazamento de segredo via o campo `Raw`/`Match` (payload do scanner preservado no `Finding`) se a saída inclui segredos detectados (Trivy `TypeSecret`).	4	3	🟠 12→Média (residual)	Redação implementada: o `Match` do Trivy nunca é armazenado em claro — só um trecho redigido é mantido (`redactSecretText`, `trivy.go`). Filtro `--min-severity`/baseline; o relatório é um artefato controlado pelo usuário (CLI/Docker, sem upload automático). Ainda assim, tratar artefatos SARIF/JSON como sensíveis nos pipelines.	Core / Docs	Mitigado (redação no código)
S-04	Bind mount malformado ⇒ falso negativo. `-v "%cd%/work"` (sem `:`) monta um `/work` vazio e reporta 0 findings para tudo — um falso negativo, não uma atestação de segurança (`README.md`).	4	4	🔴 16 Crítica	Aviso explícito e exemplos por shell (cmd/PowerShell/bash) no README. Status por scanner (`ran`/`skipped`/`unavailable`) e o lema "0 findings não é prova de segurança" ajudam a detectar. Na Action, `--type image` auto-monta `/var/run/docker.sock` (evita falso-zero em scan de imagem local) e avisa quando o socket está ausente (`action.yml`).	Docs / Orchestrator	Parcialmente mitigado (detecção indireta)
S-05	Envelhecimento do banco de vulnerabilidades do Grype. A imagem `:full` traz o grype DB pré-cacheado; sem atualização, CVEs recentes deixam de ser detectadas (falso negativo).	3	3	🟡 9 Média	DB pré-cacheado com `GRYPE_DB_VALIDATE_AGE=false` (não expira ⇒ não falha o scan por idade, garante offline/determinismo — `Dockerfile.full`). Em ambiente com rede, o Grype pode atualizar o DB. Residual: DB fixo fica obsoleto — reconstruir/republicar `:full` periodicamente e documentar a data do DB empacotado.	Release / Distribuição	Mitigado (residual: cadência de rebuild TBD)

5. Riscos de Operação¶

ID	Descrição	P	I	Sev	Mitigação	Responsável	Status
O-01	"0 findings" interpretado como "está seguro" quando na verdade nenhum scanner rodou (ausente, OOM, timeout, alvo errado).	5	4	🔴 20 Crítica	Central ao produto: status por scanner em todo relatório e o lema "0 findings não é prova de segurança" (`orchestrator.go` `ScannerRun`, `DESIGN.md` §14). Resumo no stderr; `--log-format text\\|json` e métricas Prometheus opcionais (`--metrics`) dão observabilidade no CI.	Orchestrator / Docs	Mitigado
O-02	Scanner ausente no modo `:slim` (o orquestrador chama scanners do PATH) ⇒ cobertura silenciosamente reduzida, agora com 12 scanners possíveis.	4	3	🟠 12 Alta	Um scanner ausente vira `unavailable` e é pulado — o scan nunca falha só por isso, mas o status é reportado. `list-scanners` mostra os registrados. A imagem `:full` evita o problema. `conftest` sem policy em `./policy` é reportado como `error` (policy-as-code é opt-in).	Orchestrator	Mitigado
O-03	Configuração de gate errada (`--fail-on`/`--min-severity`) deixa passar risco real ou bloqueia builds indevidamente; confusão de exit-code (`1` gate vs `2` erro).	3	4	🟠 12 Alta	Exit codes documentados (`0` ok / `1` gate / `2` erro). Baseline `.quorumignore` por fingerprint com supressões sempre logadas. Exemplos prontos de CI em `examples/ci/`.	Docs / CLI	Mitigado

6. Riscos de Infraestrutura¶

ID	Descrição	P	I	Sev	Mitigação	Responsável	Status
I-01	*OOM / runner* sem memória** mata o probe ou o scanner (12 scanners potencialmente pesados lançados em paralelo no fan-out).	3	4	🟠 12 Alta	`killedSignal` detecta `signal: killed` e emite mensagem acionável ("provável OOM — aumente a memória do container") (`orchestrator.go`). `--scanners` permite escopar o pool. Limites de DoS (T-07) previnem OOM por saída/alvo enorme. Probe generoso de 60s.	Orchestrator / Infra	Mitigado
I-02	`:full` é `linux/amd64` apenas (sem arm64); usuários arm precisam de `:slim` (amd64+arm64) ou um binário nativo.	2	3	🟡 6 Média	Trade-off documentado: `:full` amd64 (todos os 12 scanners), `:slim` multiarch (`README.md` tabela de tags). Binários nativos via GoReleaser para várias plataformas.	Distribuição	Aceitar (documentado)
I-03	Indisponibilidade de GHCR / GitHub Actions afeta release e pull de imagem; dependência de infraestrutura de terceiros.	2	4	🟡 8 Média	Imagens são cacheáveis; binários nativos como distribuição alternativa. CI/CD via PR para `main`; release por tag semver restrita (`v[0-9]+.[0-9]+.[0-9]+`). Risco residual por ser plataforma externa.	Release / Infra	Aceitar (dependência de plataforma)

7. Riscos Financeiros¶

O Quorum é OSS, CLI/Docker, sem serviço persistente nem nuvem de runtime própria, o que limita drasticamente a exposição financeira (sem custo de infra de produção, sem cobrança por uso).

ID	Descrição	P	I	Sev	Mitigação	Responsável	Status
F-01	Custo de minutos de CI / armazenamento de pacotes no provedor (GitHub Actions/GHCR) cresce com a matriz de build (multi-arch, 12 scanners, atestações SLSA/SBOM incluindo o knowledge pack).	2	4	🟡 8 Média	Release disparado só por tag semver (não a cada push); `:full` restrito a amd64 reduz a matriz; caches de build; grype DB pré-cacheado.	Release / Infra	Mitigar
F-02	Custo de manutenção / tempo do mantenedor (esforço, não desembolso direto) para acompanhar versões de 12 scanners + crosswalk + knowledge pack.	2	2	🟢 4 Baixa	Adapters plugáveis (isolam a mudança); testes de contrato; crosswalk incremental derivado de saída real; harness de evals (`internal/evals`) mantém os dados consultivos honestos no CI. Relacionado a L-01 (bus factor).	Manutenção	Monitorar

8. Riscos Legais¶

ID	Descrição	P	I	Sev	Mitigação	Responsável	Status
L-01	Bus factor / sustentabilidade da manutenção OSS. Dependência de poucos mantenedores e de 12 projetos OSS externos — alguns em manutenção reduzida ou arquivados (ex.: `tfsec` absorvido pelo Trivy mas ainda embutido; `terrascan` arquivado em nov/2025 mas empacotado, `DESIGN.md` §2).	3	5	🔴 15 Crítica	Arquitetura de adapters plugáveis: trocar um scanner morto = trocar um adapter, sem tocar no core (`DESIGN.md` §1). `tfsec` auto-correlaciona com `trivy` (AVD nativo), reduzindo o impacto de sua descontinuação. Escopo exclui deliberadamente ferramentas redundantes sem valor de consenso. Contribuições externas viabilizadas pela interface estável.	Manutenção / Comunidade	Aberto (risco estrutural de OSS)
L-02	Conformidade de licenças dos binários embutidos na imagem `:full` (cada um dos 12 scanners distribuídos tem sua própria licença).	2	3	🟡 6 Média	`THIRD_PARTY_NOTICES.md` cataloga as licenças de terceiros redistribuídas; auditar a licença de cada binário distribuído na imagem (`DESIGN.md` §14). Projeto sob Apache-2.0; `:slim` não redistribui binários de terceiros.	Legal / Release	Parcialmente mitigado (auditoria contínua recomendada)

9. Riscos da Camada Consultiva (IA) — apenas opt-in¶

Estes riscos só se aplicam quando a camada consultiva está habilitada via --advice. A camada fica desligada por padrão, é somente de apresentação e nunca toca em correlationKey/fingerprint/confidence/severidade agregada/o gate fail-on — sem --advice a saída é byte-a-byte idêntica e nenhum destes riscos se aplica. O núcleo determinístico não tem IA. A Fase 0 (templates curados de remediação + referências OWASP, internal/enrich) e a Fase 2 (RAG a partir de um corpus OWASP com digest fixado, internal/rag) são determinísticas e não usam modelo por padrão; a Fase 1 (LLM local) e a Fase 3 (provedor remoto) são as fases opt-in baseadas em modelo (internal/advisor).

ID	Descrição	P	I	Sev	Mitigação	Responsável	Status
A-01	Conselho em linguagem natural alucinado / incorreto do LLM (`--advice-provider=local\\|remote`) — uma recomendação de remediação errada engana o usuário.	3	2	🟡 6 Média	Somente apresentação: o conselho nunca altera correlação/consenso/severidade/gate; o resultado determinístico se sustenta sozinho. Todo anexo de IA é rotulado "AI-generated, advisory only" (`internal/advisor`). Templates determinísticos da Fase 0 + referências OWASP são preferidos e disponíveis sem modelo. `temperature=0` para reprodutibilidade. Desligado por padrão.	Advisor	Mitigado (enquadramento consultivo)
A-02	Vazamento de egress via provedor remoto (`--advice-provider=remote`): o finding normalizado sai do host para uma API externa.	2	4	🟡 8 Média	Gate de consentimento explícito `--advice-allow-egress` obrigatório; BLOQUEADO por `--offline`; só o finding normalizado é enviado — nunca código-fonte. Auth via env `QUORUM_ADVICE_API_KEY` (a Action a repassa como env, nunca inline). Provedor local (on-host, ex.: Ollama) mantém os dados no host. Desligado por padrão.	Advisor / Docs	Mitigado (consentimento + bloqueio offline)
A-03	Patch ruim do `--fix=suggest` propõe uma mudança incorreta ou danosa.	2	3	🟡 6 Média	Verify-the-fix: o patch é aplicado a uma cópia temporária, re-escaneado com o mesmo scanner e mantido apenas se o finding sumiu e o arquivo ainda faz parse (`internal/advisor/verify.go`); nunca aplica automaticamente. O provedor remoto recusa `--fix` (subiria código-fonte). `--fix` tem padrão `off`. A taxa de verify-the-fix é acompanhada como eval e métrica.	Advisor	Mitigado (verify-the-fix + nunca auto-aplica)
A-04	Não-reprodutibilidade / não-determinismo da saída do modelo mina a auditabilidade do anexo consultivo.	2	2	🟢 4 Baixa	`temperature=0` + um cache em disco chaveado por `fingerprint+provider+model` (`internal/advisor`) tornam os anexos estáveis. Graceful degradation: se o modelo estiver inacessível, o relatório sai sem conselho de IA e o scan nunca falha.	Advisor	Mitigado
A-05	Adulteração ou drift do knowledge pack / corpus OWASP (`knowledge/*.yaml`, `knowledge/owasp/corpus.yaml`) alimenta conteúdo errado nas Fases 0/2.	2	4	🟡 8 Média	O corpus é versionado e com DIGEST FIXADO; `quorum advise-index` o embute preservando o pin. O knowledge pack + crosswalk recebem uma atestação de build-provenance SLSA a cada release (verifique com `gh attestation verify knowledge/owasp/corpus.yaml`). A recuperação é determinística (lexical por padrão; semântica só quando embedado).	Supply chain / Advisor	Mitigado (atestação + pin)

10. Riscos N/A (por arquitetura)¶

Itens comuns em templates corporativos que não se aplicam ao Quorum, com justificativa técnica. Onde faz sentido, uma proposta futura claramente separada é anotada.

Categoria de risco (template)	Status	Justificativa
Injeção/OWASP em endpoints HTTP, CSRF, XSS	N/A	Não há frontend web nem API REST HTTP. O Quorum é um binário CLI stateless / imagem Docker. (Injeção de argumento em shell-out é tratada: um alvo que começa com `-` é recusado — `scan.go`.)
Vazamento de PII em banco de dados	N/A	Não há banco de dados relacional. O único estado persistente é o cache de aliases em `~/.cache/quorum/aliases.json` (IDs públicos de vuln, sem PII; perm `0600`) e o cache consultivo (anexos redigidos chaveados por fingerprint).
Comprometimento de autenticação/sessão/conta	N/A	Não há autenticação nem contas de usuário. A autorização é a do shell/CI onde o binário roda.
Alucinação / prompt injection / custo de tokens de IA	N/A para o núcleo; tratado na §9 quando a camada consultiva está habilitada	O núcleo determinístico não tem IA — correlação e consenso são funções puras dos dados normalizados. A camada consultiva opt-in (`--advice`, desligada por padrão) pode invocar um LLM local/remoto; seus riscos (alucinação A-01, egress A-02, patch ruim A-03, não-determinismo A-04, adulteração de corpus A-05) estão catalogados na §9. O OWASP LLM Top 10 só se aplica quando essa camada está habilitada.
DDoS / disponibilidade de serviço online	N/A	Não há serviço/daemon exposto. A única chamada de saída (OSV.dev, e o advisor remoto quando explicitamente habilitado) é opcional e degrada graciosamente. Exaustão local de recursos é tratada pelos limites de DoS (T-07).
Custo de nuvem em runtime / autoscaling	N/A	Sem nuvem de runtime própria; roda no CI/host do usuário.
Risco de runtime security (stream Falco/Tetragon)	N/A hoje	Modelo de stream fora de escopo. Proposta futura: módulo de runtime separado (roadmap `README.md`/`DESIGN.md` §13).

11. Riscos críticos — visão consolidada¶

flowchart LR
    subgraph criticals["🔴 Severidade Crítica (≥15)"]
        T02["T-02 mudança de formato de saída de scanner"]
        T03["T-03 crosswalk com cobertura parcial"]
        T04["T-04 over-merge MISCONFIG"]
        S01["S-01 supply chain de scanner"]
        S04["S-04 mount errado = 0 findings"]
        O01["O-01 '0 findings' = seguro"]
        L01["L-01 bus factor OSS"]
    end
    T02 --> contract["Testes de contrato + fixtures versionadas"]
    T03 --> nomatch["Regra no-match (unmapped) + IDs reais"]
    T04 --> future["Identidade por recurso (futuro)"]
    S01 --> cosign["cosign + SLSA + SBOM + scanners por sha256/checksum"]
    S04 --> status["Status por scanner + lema 0!=seguro + auto-mount socket"]
    O01 --> status
    L01 --> adapters["Adapters plugáveis"]

12. Plano de tratamento (checklist acionável)¶

Priorizado pelos riscos 🔴/🟠. Os itens marcam o que ainda falta para consolidar "production-ready". Itens já concluídos na v0.8.3 aparecem marcados.

[ ] T-03 / crosswalk: expandir a cobertura além do subconjunto atual (mais serviços AWS/Azure/GCP e controles K8s) e revalidar IDs a cada bump de scanner.
[ ] T-02: manter a cobertura de teste de contrato para os 12 adapters e revisar fixtures a cada bump de versão de scanner.
[x] S-01: referências de scanner na :full convertidas para @sha256:<digest>/checksum verificado no build.
[x] S-01: atestação de build-provenance SLSA + SBOM SPDX atestado (imagem e por binário) verificados no release.
[x] S-01: knowledge pack + crosswalk recebem sua própria atestação de build-provenance SLSA a cada release.
[ ] S-05: definir a cadência de rebuild/republish da :full e documentar a data do grype DB empacotado.
[ ] S-02: reforçar no README/CI a verificação cosign/SLSA (incluindo o knowledge pack) e fixar a Action por @<sha>.
[x] S-03: segredos (o Match do Trivy) redigidos antes de armazenar no Finding.
[x] A-02/A-03: egress remoto atrás de --advice-allow-egress, bloqueado por --offline; --fix recusado pelo provedor remoto; verify-the-fix em cópia temporária, nunca auto-aplica.
[ ] O-01 / S-04: considerar um warning automático quando todos os scanners rodaram (ran) mas a contagem total de findings é 0 em um alvo não trivial.
[ ] L-02: manter a auditoria de licenças dos binários redistribuídos na :full (base: THIRD_PARTY_NOTICES.md).
[ ] L-01: documentar o processo de contribuição/substituição de adapter para reduzir o bus factor.
[ ] T-04: acompanhar a implementação de identidade por recurso para MISCONFIG.

13. Reavaliação¶

Gatilhos de reavaliação: bump de versão de qualquer scanner; novo release de imagem/binário; mudança no schema do OSV.dev; arquivamento/descontinuação de um scanner OSS; incidente de supply chain; mudança na camada consultiva (novo provedor de advice, re-pin de corpus, modelo padrão).
Cadência sugerida: revisar a matriz a cada release semver (v[0-9]+.[0-9]+.[0-9]+) e uma auditoria completa trimestralmente.
Responsável pelo documento: mantenedor(es) de quorum-sec-scan.

Premissas¶

Versão. Documento alinhado à v0.8.3 (revisão de 2026-07-04); severidades, mitigações e status refletem o código lido no momento da escrita (README.md, DESIGN.md, internal/orchestrator/orchestrator.go, internal/adapter/, internal/advisor/, cmd/quorum/scan.go, Dockerfile.full, action.yml, .github/workflows/release.yml).
Escopo do produto. O Quorum é apenas CLI/Docker (sem frontend web, banco relacional, API REST HTTP, ou autenticação/contas). O núcleo determinístico não tem IA; uma camada consultiva opt-in (--advice, desligada por padrão, somente apresentação) é a única superfície de IA, e seus riscos estão catalogados na §9. Riscos correspondentes aos componentes ausentes são N/A por decisão arquitetural (ver §10).
Escalas P/I/severidade são uma convenção deste documento (matriz 5×5, faixas do produto P×I), não um artefato presente no código. Os valores numéricos de P e I são estimativas qualitativas dos mantenedores, não medições.
Tetos de faixa. Quando P×I excede 14, a severidade é "Crítica"; T-01 (15) é apresentado como Alta→limítrofe por já estar mitigado no código (graceful degradation), refletindo o risco residual, não o bruto.
Consenso e crosswalk. O consenso está ativo em SCA e em MISCONFIG/IaC/K8s; os mapeamentos crosswalk/{aws,azure,gcp,k8s}.yaml foram derivados de saída real de scanner (IDs reais AVD/CKV/KICS-UUID/C-####), com cobertura ainda parcial (T-03). K8s RBAC permanece single-engine (RBAC do kubescape exige contexto de cluster) — documentado.
A camada consultiva é opt-in e desligada por padrão. Sem --advice, a saída é byte-a-byte idêntica e nenhum risco de IA (§9) se aplica. Quando habilitada, o egress para um provedor remoto exige consentimento explícito (--advice-allow-egress) e é bloqueado por --offline; --fix só mantém um patch que passa por um re-scan de verify-the-fix e nunca auto-aplica; somente o finding normalizado é enviado — nunca código-fonte.
Owners citados são papéis/áreas (Core, Adapters, Orchestrator, Crosswalk, Advisor, Release/Distribuição, Docs, Manutenção/Comunidade, Legal), não pessoas nomeadas — o repositório não define um RACI formal.
Dependência de rede opcional. A resolução de alias via OSV.dev é opcional; o scan completa sem conectividade (--offline a desabilita). Isso sustenta o status "mitigado" de T-01.
Supply chain como trust boundary. Os binários de scanner embutidos na :full fazem parte do trust boundary do usuário; na v0.8.3 a recomendação de digest-pin está aplicada (@sha256/checksum verificado no build — Dockerfile.full), e o knowledge pack + crosswalk estão cobertos por uma atestação de build-provenance SLSA, deixando como residual a confiança nos publishers originais dos scanners (S-01) e a data do grype DB empacotado (S-05).