Ir para o conteúdo

Roadmap

Este documento descreve a evolução do Quorum (quorum-sec-scan), a ferramenta de consensus security scanning CLI/Docker. Ele consolida a tabela de roadmap publicada no README.md, explicita o estado atual (v0.8.3, revisão 2026-07-04), e organiza o trabalho em fases (MVP / V1 / Expansão / V2 / V3 / Longo prazo) com objetivos, entregáveis e critérios de saída verificáveis por fase. O documento é as-is sobre o que já existe e forward-looking (com rótulo claro) sobre o que ainda não existe.

Princípio de produto que guia todas as fases: false split > false merge — na dúvida, o Quorum mantém findings separados e os marca como unmapped, pois uma fusão errada esconde risco. Toda fase abaixo preserva esse invariante.

[!IMPORTANT] O Quorum é CLI/Docker only: não há frontend web, banco relacional, API REST de runtime nem autenticação de usuários. Nenhum item deste roadmap introduz essas categorias. Sobre IA: o núcleo determinístico não tem IA — a orquestração, o correlationKey, o fingerprint, o confidence e o gate fail-on são livres de modelo e reprodutíveis. Desde a v0.8.x existe uma camada consultiva opt-in (--advice, desligada por padrão) que é apenas de apresentação e nunca toca o núcleo; sem a flag, a saída é byte-idêntica. Itens que poderiam sugerir o contrário estão marcados como Fora de escopo com justificativa na seção dedicada.

1. Visão geral das fases

A numeração de fases (MVP/V1/Expansão/V2/V3) é a abstração de planejamento; ela mapeia para as versões SemVer reais conforme a tabela abaixo. O trigger de release é restrito a tags v[0-9]+.[0-9]+.[0-9]+ em .github/workflows/release.yml.

Fase Versão(ões) Tema Status
MVP v0.1.x SCA por consenso (Trivy + Grype), SARIF/JSON, imagem :full Concluído
V1 v0.2.x → v0.3.x IaC (Checkov/KICS) + crosswalk, K8s/hardening (Kubescape/Dockle), XML Concluído
Expansão v0.4.x → v0.8.x +6 engines (Terrascan/tfsec/Regula/Conftest/Polaris/kube-score), consenso multi-cloud (AWS/Azure/GCP) e K8s multi-engine, métricas Prometheus, endurecimento de supply chain e segurança, camada consultiva opt-in (--advice) Concluído (atual: v0.8.3)
V2 v1.0.0 Camada de política sobre findings normalizados (gate Rego), cache de alias persistente/compartilhável, profiles de imagem Planejado
V3 v1.x Identidade per-resource em MISCONFIG, ampliação de crosswalk, novos engines Planejado
Longo prazo v2.x+ Módulo de runtime separado (Falco/Tetragon, modelo de stream) Exploratório

Linha do tempo (Mermaid)

timeline
    title Evolução do Quorum
    section MVP (v0.1.x) - concluído
        SCA consenso       : Trivy + Grype
        Modelo canônico    : model.Finding, correlationKey vulnId+purl
        Relatórios         : SARIF (primário) + JSON
        Distribuição       : imagem :full
    section V1 (v0.2.x / v0.3.x) - concluído
        IaC                : Checkov + KICS
        Crosswalk          : rule->canonical control (AVD/CIS)
        K8s e hardening    : Kubescape + Dockle
        Formato XML        : pipelines legados / JUnit-like
    section Expansao (v0.4.x - v0.8.x) - concluído
        IaC multi-engine   : Terrascan + tfsec + Regula
        Policy-as-code     : Conftest (seu Rego de ./policy)
        K8s multi-engine   : Polaris + kube-score (consenso com Kubescape)
        Crosswalk multi-cloud : AVD aws/azure/gcp + hub C-#### k8s
        Observabilidade    : --metrics (Prometheus) + --log-format json
        Supply chain       : cosign keyless + SLSA + SBOM SPDX atestados
        Camada consultiva  : --advice (Fases 0-3, opt-in, só apresentação)
    section V2 (v1.0.0) - planejado
        Gate de politica   : Rego sobre findings normalizados
        Cache de alias     : persistente / compartilhavel
        Profiles           : presets de scanners + gates
    section V3 (v1.x) - planejado
        Identidade MISCONFIG : per-resource (reduzir over-merge)
        Crosswalk++        : mais controles / catalogos oficiais
        Novos engines      : conforme demanda
    section Longo prazo (v2.x+) - exploratorio
        Runtime module     : Falco / Tetragon (stream model, modulo separado)

Gantt indicativo (sequenciamento, não datas firmes)

gantt
    title Sequenciamento de fases (indicativo, sem compromisso de datas)
    dateFormat  YYYY-MM-DD
    axisFormat  %Y-%m
    section MVP
    SCA Trivy+Grype            :done,    mvp, 2025-09-01, 60d
    section V1
    IaC Checkov+KICS (v0.2)    :done,    v1a, after mvp, 60d
    K8s/Dockle/XML (v0.3)      :done,    v1b, 2026-01-05, 75d
    section Expansao
    +6 engines (v0.4-v0.7)     :done,    ex1, after v1b, 90d
    Crosswalk multi-cloud+k8s  :done,    ex2, after v1b, 90d
    Hardening supply chain     :done,    ex3, after v1b, 90d
    Camada consultiva (v0.8)   :done,    ex4, after ex1, 45d
    section V2
    Gate de politica (v1.0)    :         v2,  after ex4, 90d
    Cache persistente de alias :         v2c, after ex4, 45d
    Profiles                   :         v2p, after ex4, 45d
    section V3
    Identidade per-resource    :         v3,  after v2, 90d
    section Longo prazo
    Runtime module (Falco)     :         lp,  after v3, 180d

As datas no Gantt são relativas e indicativas (sequenciamento), não compromissos de calendário. O único gating real de release é uma tag SemVer.

2. MVP — SCA por consenso (v0.1.x) · Concluído

Objetivos

  • Provar a tese central: correlacionar e pontuar findings sobre os quais múltiplos scanners concordam, em vez de produzir N relatórios duplicados.
  • Estabelecer o modelo canônico (model.Finding) e o pipeline scan → normalize → correlate → score → report.

Entregáveis

  • Adapters trivy e grype implementando a interface Adapter (Name/Version/Supports/Capabilities/Run) — ver internal/adapter/trivy.go e grype.go.
  • correlationKey de VULN baseado em vulnId + purl; Fingerprint = sha256(correlationKey).
  • Relatórios SARIF (primário) e JSON, com partialFingerprints["quorum/v1"] e properties.detectedBy/detectionCount/confidence.
  • Imagem Docker :full com os scanners empacotados.
  • Comandos scan <target> e list-scanners (cobra) em cmd/quorum.

Critérios de saída

  • [x] Dois CVEs equivalentes (CVE x GHSA) para o mesmo pacote/versão fundem em um único finding com detectionCount = 2.
  • [x] Saída SARIF válida ingerível pelo GitHub code scanning.
  • [x] Exit codes determinísticos: 0 ok, 1 gate, 2 erro.
  • [x] Contract test por adapter contra fixture real em internal/adapter/testdata.

3. V1 — IaC, K8s, hardening e formatos (v0.2.x → v0.3.x) · Concluído

Ambas as subfases estão entregues: v0.2 (IaC por consenso) e v0.3 (K8s, hardening de imagem e XML). Os componentes existem no código e são cobertos por contract tests.

3.1 v0.2 — IaC por consenso · Concluído

Objetivos: estender o consenso para misconfigurations de IaC, onde engines divergem em IDs de regra e identidade de recurso.

Entregáveis: - Adapters checkov e kics (internal/adapter/checkov.go, kics.go). - Crosswalk YAML rule → canonical control (AVD/CIS) em internal/crosswalk, bundled em /opt/quorum/crosswalk (com fallback automático a partir de --crosswalk ./crosswalk). - correlationKey de MISCONFIG por basename(file) + resourceType + canonicalControl, com fallback por categoria; regra sem mapeamento fica isolada e marcada unmapped.

Critérios de saída: - [x] Misconfig de S3/IAM detectado por Checkov e Trivy funde via canonicalControl comum. - [x] Regra não mapeada permanece isolada (nunca "adivinhada"). - [x] Supressões via baseline .quorumignore sempre logadas.

3.2 v0.3 — K8s, hardening de imagem e XML · Concluído

Objetivos: cobrir postura Kubernetes e hardening de imagem; adicionar saída XML para pipelines legados/JUnit-like.

Entregáveis (estado no código): - Adapter kubescape (K8S_POSTURE) — internal/adapter/kubescape.go. ✅ presente - Adapter dockle (IMG_HARDENING, controles CIS-DI) — internal/adapter/dockle.go. ✅ presente - Saída XML (mesma estrutura do JSON serializada) — internal/report. ✅ presente - Polaris foi entregue na fase de Expansão (v0.4+) como adapter completo (internal/adapter/polaris.go); deixou de ser um item deferido do roadmap original. Ver §4.

Critérios de saída: - [x] kubescape e dockle registrados em list-scanners e cobertos por contract tests. - [x] --format xml produz documento bem-formado equivalente ao JSON. - [x] Polaris entregue (na Expansão) com adapter e contract test — não mais deferido. - [x] Probe de versão (Options.ProbeTime, 60s) distingue timeout/killed(OOM)/não-instalado; status por scanner (ran/skipped/unavailable/error/timeout) sempre presente no relatório.

4. Expansão — Engines, consenso multi-cloud/K8s e endurecimento (v0.4.x → v0.8.x) · Concluído

Fase não prevista com esse rótulo no roadmap original do README, mas que corresponde ao trabalho realmente entregue entre a v0.3 e a v0.8.3. Vários itens originalmente projetados para V2/V3 foram antecipados aqui. O pool de scanners passou de 6 para 12 e o consenso deixou de ser exclusivo de SCA: passou a valer para MISCONFIG/IaC (multi-cloud) e postura Kubernetes (multi-engine). Esta fase também introduziu a camada consultiva opt-in (§4.5).

4.1 Expansão de engines (6 → 12)

Entregáveis (adapters em internal/adapter):

Adapter Família (consenso) Tipo Observação
terrascan iac MISCONFIG políticas Tenable IaC (baked para offline)
tfsec iac MISCONFIG emite IDs AVD nativos → auto-correlaciona com Trivy; deprecado upstream
regula iac MISCONFIG regras IaC baseadas em OPA (Fugue)
conftest policy MISCONFIG policy-as-code: roda o seu Rego de ./policy (sem regras embutidas)
polaris k8s K8S_POSTURE best-practices Fairwinds
kube-score k8s K8S_POSTURE análise estática de manifests
  • As famílias de engine estão em internal/consensus/consensus.go (iac, policy, k8s, hardening).
  • conftest não tem regras próprias: avalia o Rego do operador (padrão ./policy, ou QUORUM_CONFTEST_ARGS="--policy <dir>"). Sem políticas, é reportado como error — policy-as-code é opt-in por design (internal/adapter/conftest.go).

4.2 Consenso multi-cloud e K8s multi-engine (crosswalk derivado)

Todos os mapeamentos foram derivados de output real dos scanners (mantendo false split > false merge), sob crosswalk/.

  • IaC (hub AVD): crosswalk/aws.yaml, azure.yaml, gcp.yaml. Cobre S3/IAM/EBS/SG/RDS/KMS/CloudTrail/VPC-flow-logs (AWS), Azure Storage/Key Vault e GCP bucket/firewall/SQL, correlacionando trivy/checkov/kics/terrascan/regula. tfsec auto-correlaciona com trivy por emitir AVD nativo.
  • K8s (hub C-#### do Kubescape): crosswalk/k8s.yaml (schemaVersion: 1), correlacionando kubescape ↔ polaris ↔ kube-score em privilege-escalation, privileged, non-root, limites de cpu/mem, probes, read-only-fs, linux-hardening, automount-SA, network-policy, host-network, host-PID/IPC, capabilities e secrets.
  • RBAC segue single-engine: o RBAC do kubescape exige contexto de cluster, então não há par para consenso — documentado, não deferido silenciosamente.

4.3 Observabilidade e caps operacionais

  • Nova flag --metrics <arquivo>: emite métricas em formato texto Prometheus (textfile) — cmd/quorum/scan.go.
  • Nova flag --log-format text|json: logs de progresso em stderr (json = um objeto por linha).
  • Passthrough por scanner via QUORUM_<SCANNER>_ARGS (ex.: QUORUM_CHECKOV_ARGS="--bc-api-key …" destrava políticas Prisma/Bridgecrew através do Checkov OSS empacotado).
  • Caps contra DoS/OOM: QUORUM_MAX_OUTPUT_BYTES (default 512 MiB) e QUORUM_MAX_TARGET_BYTES (default 20 GiB).

4.4 Endurecimento de supply chain e segurança

  • Supply chain (release.yml, Dockerfile.full, .goreleaser.yaml): atestação SLSA build-provenance e SBOM SPDX atestada (actions/attest-sbom) para imagem e por-binário (GoReleaser/syft), além do sbom: true do BuildKit; cosign keyless com retry; bases pinadas por sha256; kubescape/tfsec/terrascan/regula/conftest verificados por checksum; DB do grype pré-cacheado com GRYPE_DB_VALIDATE_AGE=false (não expira); THIRD_PARTY_NOTICES.md. O knowledge pack + crosswalk agora também recebem uma atestação SLSA build-provenance a cada release (job knowledge do release.yml; verifique com gh attestation verify knowledge/owasp/corpus.yaml).
  • GitHub Action (action.yml, composite): cosign-verifica a imagem; auto-monta /var/run/docker.sock em type: image (evita falso-zero em scan de imagem local); inputs de scanner-args e docker-socket; a tag móvel v0 é avançada automaticamente por tag-major.yml a cada release SemVer. Agora também expõe todos os inputs consultivos (advice, advice-provider, advice-endpoint, advice-model, advice-embed-model, advice-max, advice-cache, advice-allow-egress, advice-api-key, fix), auto-adiciona host-gateway para local e encaminha a API key via env para remote.
  • Hardening de segurança (lacunas fechadas): --output com filepath.Clean e permissão 0600; id da OSV validado e url.PathEscape; target iniciando com - recusado (argument injection); cache aliases.json em 0600 com schemaVersion; redação de segredos (o Match do trivy é redigido); DB do grype não expira. Cobertura de testes reportada no CI. Docs publicados no GitHub Pages (MkDocs Material).

4.5 Camada consultiva (IA opt-in) — Fases 0-3 · Entregue (v0.8.x)

A camada consultiva é o delta da v0.7.4 para a v0.8.3. É opt-in via --advice, apenas de apresentação, e nunca toca correlationKey, fingerprint, confidence, severidade agregada ou o gate --fail-on — sem --advice a saída é byte-idêntica. Isso supera a antiga nota de "sem IA até a v1": o núcleo determinístico continua sem IA; as partes de IA são estritamente opt-in e desligadas por padrão. Todo anexo de IA é rotulado "AI-generated, advisory only". Design completo e guardrails em 21-proposta-ia; enquadramento honesto as-is em 13-ia.

Fase 0 (determinística, sem modelo). Templates de remediação curados + referências OWASP, casados por canonicalControl/ruleId/category/type. Pacote internal/enrich; dados em knowledge/*.yaml (aws/azure/gcp/k8s/image/categories).

Fase 2 (RAG-as-artifact, determinística). Retrieval a partir de um corpus OWASP versionado e pinado por digest (knowledge/owasp/corpus.yaml, pacote internal/rag). Retrieval léxico por padrão (sem modelo); semântico (embeddings) quando o corpus é embedado via quorum advise-index — o scan auto-seleciona semântico quando o corpus tem vetores. É retrieval sobre um artefato imutável, não inferência de LLM.

Fase 1 (LLM local opt-in). --advice-provider=local consulta um endpoint on-host compatível com OpenAI (ex.: Ollama) para uma recomendação em linguagem natural, e --fix=suggest propõe um patch que precisa passar por um re-scan de verify-the-fix (aplicado a uma cópia temporária, re-escaneado com o mesmo scanner, mantido só se o finding sumir e o arquivo ainda parsear; nunca auto-aplicado). Reprodutível via temperature=0 + um cache em disco chaveado por fingerprint+provider+model. Degradação graciosa: se o modelo estiver inacessível, o relatório sai sem a advice de IA e o scan nunca falha. Pacote internal/advisor.

Fase 3 (provedor remoto opt-in). --advice-provider=remote chama uma API externa (auth via QUORUM_ADVICE_API_KEY). Os dados saem do host, então é gated por consentimento explícito (--advice-allow-egress), bloqueado por --offline, e recusa --fix (isso faria upload de código-fonte). Apenas o finding normalizado é enviado — nunca código-fonte.

Nova superfície de CLI. Flags --advice, --advice-provider (none|local|remote), --advice-endpoint, --advice-model, --advice-embed-model, --advice-cache, --advice-max, --advice-allow-egress, --fix (off|suggest); novo subcomando quorum advise-index (embeda o corpus OWASP, preservando o pin de digest). Novos campos de MergedFinding: Remediation, References, Advice (tipos model.Remediation/DocRef/Advice/Fix).

Novas métricas (só sob --advice). quorum_advice_enriched{kind=remediation|references|recommendation}, quorum_advice_provider{provider}, quorum_advice_fix{stage=proposed|verified} (verified/proposed = a taxa de verify-the-fix).

Novos evals. O harness internal/evals mede cobertura de remediação determinística, relevância de referências OWASP e a taxa de verify-the-fix (roda no CI, sem modelo pesado).

Critérios de saída (verificados): - [x] Sem --advice, a saída SARIF/JSON/XML é byte-idêntica a um build sem a camada consultiva. - [x] --advice (Fase 0/2) anexa templates de remediação determinísticos e referências OWASP pinadas por digest, offline, sem modelo. - [x] --advice-provider=local --fix=suggest só expõe um patch que sobrevive ao re-scan de verify-the-fix; nunca é auto-aplicado. - [x] --advice-provider=remote é bloqueado por --offline, recusa --fix, e exige --advice-allow-egress; apenas o finding normalizado é enviado. - [x] Métricas consultivas emitidas apenas sob --advice; evals rodam no CI. - [x] Knowledge pack + crosswalk carregam uma atestação SLSA verificável com gh attestation verify.

Critérios de saída (Expansão, verificados): - [x] list-scanners registra os 12 adapters; cada um coberto por contract test. - [x] Misconfig de mesma classe fundindo entre trivy/checkov/kics/terrascan/regula via canonicalControl (aws/azure/gcp). - [x] Postura K8s fundindo entre kubescape/polaris/kube-score via hub C-####. - [x] --metrics grava textfile Prometheus; --log-format json emite um objeto por linha. - [x] Imagem e binários com SLSA + SBOM SPDX atestados; cosign keyless verificável. - [x] Regras/targets maliciosos (argument injection) recusados; segredos redigidos.

5. V2 — Gate de política, cache persistente e profiles (v1.0.0) · Planejado

Objetivos

Levar o Quorum de "consenso + relatório" para "consenso + política sobre os findings normalizados", mantendo o modelo CLI/Docker. Reduzir custo de rede do alias e simplificar a configuração recorrente em CI.

Nota (o que já existe vs. o que falta): o adapter conftest já entrega policy-as-code como scanner — ele roda o seu Rego contra os arquivos (IaC/manifests) e produz findings MISCONFIG. O que a V2 propõe é diferente e complementar: um gate Rego sobre os findings já normalizados e correlacionados do Quorum (ex.: "bloquear qualquer VULN ≥ HIGH sem baseline aprovada", "exigir confidence ≥ 0.8 para auto-aprovar exceção"). Esse gate ainda não existe.

Entregáveis propostos

  1. Gate de política sobre findings normalizados (OPA/Conftest embutido).
  2. Avaliar o modelo canônico do Quorum contra políticas Rego declarativas, como gate adicional complementar a --fail-on/--min-severity; resultado refletido no exit code (1 = gate de política disparou).
  3. Empacotado de forma que rode offline (sem servidor OPA externo).
  4. Cache persistente de alias.
  5. Hoje os aliases vão para ~/.cache/quorum/aliases.json (local, 0600, com schemaVersion). Proposta: formato compartilhável entre runs/CI (artefato cacheável), com TTL e invalidação; mantém degradação graciosa e respeito a --offline.
  6. Profiles de imagem/scan.
  7. Presets nomeados (ex.: sca-fast, iac-strict, k8s-posture) combinando --scanners, --min-severity, --fail-on, política e crosswalk, para evitar linhas de comando longas e divergência entre pipelines.

Critérios de saída

  • [ ] Política Rego de exemplo (sobre findings normalizados) roda offline e altera o exit code de forma determinística.
  • [ ] Cache de alias persistido e reusado entre dois runs reduz chamadas OSV observáveis (mensurável nos logs).
  • [ ] Pelo menos 3 profiles documentados, cada um reproduzível por uma flag.
  • [ ] Sem regressão de contrato: todos os contract tests verdes.
  • [ ] Documentação de cada recurso novo com exemplo executável em CI.

Nota de escopo (V2): OPA/Conftest aqui é uma biblioteca/binário avaliado localmente dentro do pipeline CLI — não introduz API REST, daemon nem servidor de políticas. Se uma "Proposta futura" exigir servidor, ela cai em Fora de escopo abaixo.

6. V3 — Identidade per-resource, crosswalk++ e novos engines (v1.x) · Planejado

Objetivos

Atacar a principal limitação conhecida de correlação MISCONFIG e ampliar cobertura de controles e engines.

Entregáveis propostos

  1. Identidade per-resource em MISCONFIG.
  2. Limitação atual (ver README §Known limitations): dois recursos distintos do mesmo tipo com o mesmo controle no mesmo arquivo podem over-merge. Proposta: identidade de recurso normalizada (ex.: endereço Terraform aws_s3_bucket.data) para correlacionar com precisão sem violar false split > false merge.
  3. Ampliação do crosswalk.
  4. Mais controles/clouds além do já coberto (S3/IAM/EBS/SG/RDS/KMS/CloudTrail/ VPC-flow-logs, Azure Storage/Key Vault, GCP bucket/firewall/SQL); validação contra catálogos oficiais AVD/CIS; possível ferramenta de lint do crosswalk.
  5. Novos engines.
  6. Avaliação de outros engines OSS conforme demanda (ex.: Docker Scout, Clair, OpenSCAP — hoje deferidos no README por peso de arquitetura/login), sempre via interface Adapter + contract test.

Critérios de saída

  • [ ] Caso de teste com dois recursos do mesmo tipo/controle/arquivo deixa de over-merge e produz dois findings corretos.
  • [ ] Crosswalk lintado contra catálogos oficiais; cobertura documentada.
  • [ ] Cada novo engine registrado em list-scanners com contract test contra fixture real e mapeado na família de engines correta.

7. Longo prazo — Módulo de runtime (v2.x+) · Exploratório

Objetivos

Estender a tese de consenso para sinais de runtime, sem comprometer a natureza CLI/batch do Quorum atual.

Entregáveis propostos

  • Módulo de runtime separado consumindo streams de Falco/Tetragon (modelo de eventos de execução), entregue como componente distinto do orquestrador de scan estático — para não transformar o Quorum em um daemon de propósito geral.

Critérios de saída

  • [ ] Modelo de stream especificado e isolado do model.Finding estático (ou explicitamente versionado/separado).
  • [ ] Prova de conceito que correlaciona um achado estático com um evento de runtime sem acoplar o caminho de scan existente.

Esta fase é exploratória: sujeita a redefinição/cancelamento. Não há compromisso de entrega.

8. Fora de escopo (N/A) — e por quê

Itens frequentemente esperados em roadmaps de produtos de segurança que o Quorum não persegue, por decisão de arquitetura:

Item Status Justificativa
Frontend web / dashboard N/A Quorum é CLI/Docker; relatórios (SARIF/JSON/XML) são consumidos por ferramentas existentes (GitHub code scanning, DefectDojo).
Banco de dados relacional N/A Estado é efêmero por run; persistência limita-se a cache de alias em arquivo.
API REST / daemon de runtime do scanner N/A Modelo é batch em CI/CD com gate por exit code; um servidor mudaria o modelo de confiança.
Autenticação / contas de usuário N/A Sem multi-tenant; identidade é a do pipeline. Verificação de cadeia usa OIDC/cosign, não login.
IA / LLM no núcleo determinístico N/A Consenso é determinístico e auditável; um LLM introduziria não-determinismo no correlationKey/confidence. A camada consultiva opt-in (--advice, §4.5) é apenas de apresentação e nunca toca o núcleo — não é IA de núcleo.
Plataforma SaaS/cloud gerenciada N/A Distribuição é imagem Docker + binário nativo; o consumidor opera o pipeline.

Proposta futura (claramente separada): se houver demanda, um runtime module (Longo prazo) e/ou integrações de exportação (ex.: webhook para sistemas de tracking) poderiam ser estudados como componentes opcionais e separados, sem reverter a decisão de não ter daemon/SaaS no núcleo. A telemetria já existente (--metrics, formato texto Prometheus) é arquivo textfile, não um servidor — coerente com o modelo batch. A camada consultiva, da mesma forma, permanece opt-in e local-first, e pode ser removida sem alterar um único byte do núcleo.

9. Como uma fase "fecha" (definição de pronto)

Independentemente da fase, um item só é considerado entregue quando:

  • [ ] Código segue a interface Adapter (quando aplicável) e o modelo canônico.
  • [ ] Há contract test contra fixture real do output da ferramenta (internal/adapter/testdata).
  • [ ] make test, make vet, make build verdes; CI (ci.yml, com cobertura de testes) e e2e (e2e.yml) passam.
  • [ ] Invariante false split > false merge preservado (sem fusões especulativas; unmapped quando não houver mapeamento).
  • [ ] Status por scanner e supressões de baseline permanecem explícitos ("0 findings is not proof of safety").
  • [ ] Para itens da camada consultiva: sem --advice a saída é byte-idêntica; anexos de IA são rotulados "AI-generated, advisory only"; os evals em internal/evals permanecem verdes no CI.
  • [ ] Documentação atualizada (publicada no GitHub Pages) e, quando aplicável, exemplo de CI em examples/ci/.
  • [ ] Release apenas por tag SemVer v[0-9]+.[0-9]+.[0-9]+, com imagens/binários assinados (cosign keyless) e atestações SLSA build-provenance + SBOM SPDX verificadas (incluindo o knowledge pack + crosswalk).

10. Rastreabilidade README ↔ fases

Mapeamento direto da tabela do README §Roadmap para as fases deste documento:

Linha do README Fase aqui Observação de fidelidade
MVP — Trivy + Grype, vulnId+purl, SARIF+JSON, :full MVP Igual.
v0.2 — Checkov + KICS, crosswalk, category fallback V1 / v0.2 Concluído.
v0.3 — Kubescape + Polaris, Dockle, XML V1 / v0.3 + Expansão Kubescape/Dockle/XML na v0.3; Polaris entregue na Expansão (adapter presente).
Scanner evaluation — Polaris, kube-score, Terrascan, tfsec, Conftest, Regula Expansão Todos Added (adapters presentes); consenso multi-cloud/k8s.
Recomendações com IA / RAG OWASP / auto-remediação Expansão (v0.8.x) Entregue como a camada consultiva opt-in (--advice, Fases 0-3); núcleo segue sem IA.
v1.0 — OPA/Conftest, cache persistente de alias, profiles V2 Conftest-como-scanner já existe; gate Rego sobre findings normalizados ainda planejado.
future — runtime Falco/Tetragon Longo prazo Exploratório, módulo separado.

Premissas

  • Versão de referência: o estado atual é v0.8.3 (revisão 2026-07-04). O número vem do enunciado/README; o literal em cmd/quorum/root.go é version = "0.1.0", um default de build sobrescrito no release via -ldflags "-X main.version=…". O git describe retorna a tag móvel v0 (avançada automaticamente por tag-major.yml), usada para pin do GitHub Action.
  • Camada consultiva: tratada como implementada — --advice e os pacotes internal/enrich (Fase 0), internal/rag (Fase 2) e internal/advisor (Fases 1/3) existem, com o corpus pinado por digest em knowledge/owasp/ e o harness internal/evals no CI. É opt-in e desligada por padrão, apenas de apresentação, e nunca toca o núcleo determinístico; sem --advice a saída é byte-idêntica. Isso supera a premissa anterior de "sem IA até a v1", mantendo o enquadramento honesto: o núcleo não tem IA.
  • Polaris: tratado como implementado — existe internal/adapter/polaris.go e a família "polaris": "k8s" em internal/consensus/consensus.go, com mapeamento no crosswalk/k8s.yaml. Isso corrige a premissa anterior (v0.2.3), quando Polaris ainda era só referência sem adapter.
  • Subfases v0.3 "concluídas": os adapters kubescape/dockle e a saída XML existem no código e passam contract tests; o gap de Polaris foi fechado na Expansão, então v0.3 é marcada como Concluído (não mais "em andamento").
  • Policy-as-code: distinguido em dois níveis — (a) conftest já roda o seu Rego contra arquivos e produz findings MISCONFIG (entregue na Expansão); (b) o gate Rego sobre os findings normalizados/correlacionados do Quorum segue planejado (V2). São recursos distintos e complementares.
  • Crosswalk: todos os mapeamentos são derivados de output real dos scanners (false split > false merge); antes de produção, valide contra os catálogos oficiais AVD/CIS. O knowledge pack + crosswalk agora carregam uma atestação SLSA por release.
  • Datas: nenhuma data de calendário é compromisso; os blocos do Gantt são sequenciais e indicativos. O único gate real de release é uma tag SemVer.
  • Conteúdo das fases V2/V3/Longo prazo: descrito como proposta derivada da linha "v1.0/future" do README; detalhes de implementação (formato de cache, esquema de políticas, nomes de profiles) são ilustrativos e sujeitos a design.
  • Itens "Fora de escopo": derivados explicitamente dos princípios declarados (CLI/Docker only; sem web/DB/REST/auth, sem IA no núcleo); não são funcionalidades removidas, e sim categorias nunca pretendidas para o núcleo. A telemetria --metrics é um arquivo texto Prometheus (não um servidor), coerente com o modelo batch, e a camada consultiva permanece opt-in e local-first.