Custos¶
Documento de referência de custos do Quorum (
quorum-sec-scan), v0.8.3. Revisão: 2026-07-04. Escrito em pt-BR, padrão corporativo. Todo valor monetário neste documento é uma estimativa baseada em premissas explícitas (ver Premissas), não em faturas reais. Sempre confira o preço atual do provedor.
O Quorum é uma ferramenta CLI/Docker de consensus security scanning. A consequência de custo mais importante é arquitetural: o Quorum não opera nenhuma infraestrutura de runtime própria. Ele roda no CI ou na estação de trabalho do consumidor e encerra o processo quando o scan termina. Portanto, o custo de operar o produto é majoritariamente transferido para o consumidor (os minutos de CI dele), e o custo do projeto Quorum se concentra em build, distribuição (cadeia de suprimentos) e manutenção — não em nuvem de runtime.
Este documento estima custos sob dois cenários — mantenedor OSS solo e equipe dedicada — cobrindo: infra de build/distribuição (minutos de GitHub Actions, armazenamento no GHCR), monitoramento (N/A hoje), licenciamento (o OSS do Quorum e o dos scanners), pessoal, operação/manutenção e escalabilidade. Componentes clássicos de custo de runtime (nuvem, banco de dados, APM) são declarados N/A com justificativa, em linha com 10-infraestrutura.md e 14-observabilidade.md.
Mudança de escala desde a v0.2.3. O Quorum saltou de 6 para 12 scanners empacotados (trivy, grype, checkov, kics, dockle, kubescape, polaris, kube-score, terrascan, tfsec, regula e conftest). O efeito de custo é concentrado: a imagem
:fullficou maior (mais binários + DB do grype pré-cacheado) e há mais dívida de manutenção recorrente (mais pins e parsers). As premissas estruturais (CI efêmero, GHCR, sem runtime hospedado) permanecem inalteradas.
1. Modelo mental de custo¶
flowchart LR
subgraph proj["CUSTO DO PROJETO QUORUM"]
B["Build / CI<br/>(minutos de GitHub Actions)"]
D["Distribuição<br/>(armazenamento GHCR + Releases)"]
E["Equipe<br/>(manutenção, adapters, cadeia de suprimentos)"]
L["Licenciamento<br/>(Apache-2.0, OSS dos scanners)"]
end
subgraph cons["CUSTO DO CONSUMIDOR (não do Quorum)"]
R["Runtime no CI dele<br/>(minutos por scan)"]
P["Pull da imagem / download do binário"]
end
B --> D --> P
E --> B
P -.-> R| Eixo de custo | Quem paga | Natureza | Magnitude relativa |
|---|---|---|---|
| Build / CI | Projeto Quorum | Variável (por push/PR/release) | Baixa–média |
| Distribuição (armazenamento) | Projeto Quorum | Recorrente (armazenamento) | Baixa |
| Equipe / manutenção | Projeto Quorum | Recorrente (tempo humano) | Dominante |
| Licenciamento | — | US$ 0 (tudo Apache-2.0) | Zero monetário |
| Monitoramento de runtime | — | N/A (sem serviço hospedado) | Zero |
| Runtime do scan | Consumidor | Variável (CI dele) | Fora do escopo do projeto |
Conclusão preliminar: o maior custo do Quorum não é dinheiro de infra, é tempo de engenharia (manter os 12 adapters, a cadeia de suprimentos e acompanhar as versões dos scanners).
2. Custo de runtime próprio — N/A¶
O projeto não provisiona nenhum recurso de operação contínua. Cada item abaixo é US$ 0 para o projeto porque não existe.
| Componente | Status | Justificativa técnica |
|---|---|---|
| Compute em nuvem (VM/serverless) | N/A — US$ 0 | Sem serviço hospedado; o binário/imagem roda no ambiente do consumidor. |
| Kubernetes de runtime | N/A — US$ 0 | O Quorum é um processo CLI de curta duração; ele escaneia K8s, não roda em K8s como produto. |
| Banco de dados relacional | N/A — US$ 0 | Correlação/consenso em memória; o único estado é um cache local de aliases (~/.cache/quorum/aliases.json, perm 0600). |
| API REST / gateway / LB / CDN / WAF | N/A — US$ 0 | Nenhuma superfície HTTP exposta. |
| APM / métricas / tracing hospedados | N/A — US$ 0 | Sem serviço de longa duração; diagnóstico via stderr, status por scanner e, opcionalmente, um textfile local do Prometheus (--metrics, ver §4). |
| Chave de assinatura (HSM/KMS) | N/A — US$ 0 | cosign keyless (GitHub OIDC); nada para armazenar/rotacionar. |
| IA / LLM (API paga) | N/A — US$ 0 | O núcleo determinístico não tem IA. A camada consultiva opcional (--advice, desligada por padrão) roda inferência local no host (sem custo por token) e só alcança uma API externa sob --advice-provider=remote, que o consumidor habilita (--advice-allow-egress) e paga — nunca o projeto (ver 13-ia.md). |
O custo do OSV.dev também é US$ 0: é um serviço público consultado sem credenciais, com degradação graciosa e desligável via
--offline.
3. Infra de build/distribuição (o custo real do projeto)¶
A "infra" do Quorum é GitHub Actions (build efêmero) + GHCR/GitHub Releases (distribuição). Em um repositório OSS público, o GitHub oferece Actions e armazenamento de pacotes/artefatos gratuitos dentro das políticas aplicáveis — então, no cenário OSS, o custo monetário direto tende a US$ 0. As estimativas abaixo modelam o caso privado/excedente (quando o repo é privado ou as cotas são ultrapassadas), para dar uma faixa de referência.
3.1 Minutos de GitHub Actions¶
Workflows reais do repositório:
| Workflow | Gatilho | Jobs / passos | Duração estimada* |
|---|---|---|---|
ci.yml |
push para main, PRs |
go vet, go test -race (cobertura), build, smoke |
~3–6 min |
e2e.yml |
push/PR, dispatch | instala scanners, grype db update, scans de consenso (IaC + K8s + SCA) |
~8–15 min |
release.yml |
tag semver vX.Y.Z, dispatch |
matriz full/slim (Buildx+QEMU, cosign keyless, SLSA build-provenance, SBOM SPDX atestado) + GoReleaser (binários) + job knowledge (atesta o pacote de conhecimento consultivo + crosswalk) |
~18–35 min |
docs.yml |
push em docs (com paths) |
build MkDocs Material + publica GitHub Pages | ~2–4 min |
tag-major.yml |
após um release semver | avança a tag móvel v0 |
<1 min |
* Estimativas de ordem de grandeza em um runner ubuntu-latest. e2e.yml e release.yml são os
mais caros porque baixam/verificam scanners, atualizam o DB do grype e fazem builds multi-arch com
QEMU (a emulação de arm64 é notoriamente lenta no :slim). Com 12 scanners (eram 6), o
e2e.yml cresceu: instala/verifica mais binários por checksum e roda mais engines por scan.
Modelo de consumo mensal (estimativa, runner Linux):
| Atividade | Eventos/mês (est.) | Min/evento (est.) | Min/mês (est.) |
|---|---|---|---|
| CI em PRs/pushes | 60 | 5 | 300 |
| E2E (consenso, 12 scanners) | 40 | 11 | 440 |
| Release (tags semver + tag-major) | 2 | 28 | 56 |
| Docs (MkDocs, só docs) | 20 | 3 | 60 |
| Total | — | — | ~856 min/mês |
Custo dos minutos (só se privado/excedente):
| Cenário | Minutos/mês | Preço unitário Linux (est.) | Custo USD/mês (est.) | Custo BRL/mês (est.) |
|---|---|---|---|---|
| OSS (repo público) | ~856 | US$ 0 (cota gratuita) | US$ 0 | R$ 0 |
| Privado, dentro da cota incluída | ~856 | coberto pelo plano | ~US$ 0 | ~R$ 0 |
| Privado, excedente | ~856 | ~US$ 0,008/min | ~US$ 6,8 | ~R$ 38 |
| Privado, equipe ativa (3× volume) | ~2.570 | ~US$ 0,008/min | ~US$ 21 | ~R$ 113 |
Câmbio assumido: US$ 1 ≈ R$ 5,50 (ver Premissas). O preço de ~US$ 0,008 por minuto Linux é o preço típico de excedente do GitHub Actions; runners maiores/macOS/Windows custam múltiplos disso — o Quorum usa apenas
ubuntu-latest, o mais barato.
Alavancas de redução de custo de CI:
- [x] Usar apenas
ubuntu-latest(já é o caso). - [x] Cache do build Docker (
cache-from/cache-to: type=gha) já configurado norelease.yml. - [x] Cache dos módulos Go (
actions/setup-go ... cache: true) já emci.yml/e2e.yml. - [x] DB do grype pré-cacheado na imagem
:fullevita umdb updateno runtime do consumidor. - [x] Scanners empacotados verificados por checksum/digest (evita rebaixar em cada job de release).
- [x]
docs.ymlrestrito porpaths(não gasta minutos em mudanças que não são de docs). - [ ] Restringir
e2e.ymlem PRs só de docs viapaths-ignore(gap — ver §9). - [ ] Evitar build arm64 via QEMU onde possível (lento/caro) — considerar um runner arm nativo.
3.2 Armazenamento (GHCR + Releases)¶
| Artefato | Onde | Tamanho est.* | Nota |
|---|---|---|---|
Imagem :slim (amd64+arm64) |
GHCR | ~30–60 MB/arch | Só o binário + ca-certificates + crosswalks |
Imagem :full (amd64) |
GHCR | ~2–3 GB | 12 scanners + venv Python/Checkov + DB do grype pré-cacheado |
| Binários nativos (6 alvos) | GitHub Releases | ~10–20 MB cada | linux/darwin/windows × amd64/arm64 (GoReleaser) |
SBOMs por binário (*.sbom.json) |
GitHub Releases | KB–MB | SPDX gerado por GoReleaser/syft |
| Assinaturas/atestados | GHCR/Releases | KB | cosign .sig/.pem, SLSA build-provenance, attest-sbom, atestado do pacote de conhecimento |
* Estimativas qualitativas derivadas do conteúdo dos Dockerfiles; não medidas no repo. A
:full cresceu de ~1–2 GB (6 scanners, v0.2.3) para ~2–3 GB porque agora empacota 12 engines
(inclui terrascan com políticas via terrascan init, regula, conftest, polaris, kube-score,
tfsec) além do runtime Python do Checkov.
A :full domina o armazenamento. Cada release adiciona uma nova tag versionada; sem uma política de
retenção o histórico cresce linearmente — e cada tag agora é maior.
| Cenário | Armazenamento acumulado est. (12 meses) | Custo USD/mês (est.) | Custo BRL/mês (est.) |
|---|---|---|---|
| OSS (repo público) | dezenas de GB | US$ 0 (incluído) | R$ 0 |
| Privado, sem GC de tags antigas | ~50–90 GB | ~US$ 8–22 | ~R$ 44–121 |
| Privado, com GC (manter as últimas N) | ~8–15 GB | ~US$ 2–4 | ~R$ 11–22 |
Alavancas:
- [ ] Política de retenção/limpeza para versões antigas no GHCR (gap — ver §9).
- [x] Pinagem por
@sha256recomendada ao consumidor reduz a dependência de muitas tags móveis. - [x] A tag móvel
v0(avançada portag-major.yml) dá um alvo estável sem multiplicar tags. - [x] Publicar a
:fullapenas em releases (não a cada commit) — já é o caso. - [x] Manter a
:slimcomo o caminho BYO-scanners para quem não quer o peso da:full.
4. Monitoramento / observabilidade — N/A (hoje)¶
Não há custo de monitoramento de runtime porque não há runtime hospedado a monitorar (ver 14-observabilidade.md). A "observabilidade" do produto é:
| Item | Custo | Natureza |
|---|---|---|
Logs em stderr + status por scanner (ran/skipped/unavailable/error/timeout) |
US$ 0 | Nativo; consumido pelo CI do usuário. --log-format text\|json para ingestão estruturada. |
| Relatório SARIF/JSON/XML como artefato | US$ 0 | Gerado localmente |
Métricas Prometheus (--metrics <arquivo>) |
US$ 0 | Textfile local; o consumidor decide se coleta via node-exporter/pushgateway (custo dele, não do Quorum). Sob --advice, contadores exclusivamente consultivos também são emitidos (quorum_advice_enriched, quorum_advice_provider, quorum_advice_fix) — mesmo textfile local, sem serviço extra. |
| APM/Datadog/Grafana/Prometheus hospedados | N/A | Sem serviço de longa duração do lado do projeto |
Proposta futura (NÃO implementada)¶
Caso o módulo de runtime separado mencionado no DESIGN §13 (Falco/Tetragon/OpenSCAP como produto independente) se materialize, haveria então um custo contínuo de observabilidade (coleta de streams, armazenamento de eventos, dashboards). Fora do escopo do Quorum v0.8.x.
5. Licenciamento¶
5.1 Licença do Quorum¶
| Item | Valor |
|---|---|
| Licença do projeto | Apache License 2.0 (ver LICENSE) |
| Custo de uso/redistribuição | US$ 0 — permissiva, livre de royalties, com concessão de patente |
| Obrigações | Manter avisos de copyright/licença; declarar modificações; (se houver) incluir NOTICE |
A Apache-2.0 não impõe copyleft a quem usa/integra o Quorum, e concede uma licença de patente explícita (cláusula 3). Custo monetário de licenciamento do Quorum: zero.
5.2 Licenças dos scanners empacotados¶
O Quorum orquestra scanners OSS de terceiros. Cada um tem sua própria licença; o Quorum os
invoca como processos externos (via os/exec, ver internal/adapter/adapter.go) e
os empacota na imagem :full. As licenças abaixo estão confirmadas e documentadas em
THIRD_PARTY_NOTICES.md:
nas versões pinadas em Dockerfile.full,
todos os 12 scanners são Apache-2.0.
| Scanner | Projeto/origem | Licença | Custo | Vai no :full? |
|---|---|---|---|---|
| Trivy | aquasecurity/trivy | Apache-2.0 | US$ 0 | Sim (imagem pinada por @sha256) |
| Grype | anchore/grype | Apache-2.0 | US$ 0 | Sim (instalador oficial, checksum) |
| Syft (suporte ao Grype) | anchore/syft | Apache-2.0 | US$ 0 | Sim (instalador oficial, checksum) |
| Checkov | bridgecrewio/checkov (Prisma) | Apache-2.0 | US$ 0 | Sim (pip install em venv isolado) |
| KICS | Checkmarx/kics | Apache-2.0 | US$ 0 | Sim (imagem pinada por @sha256) |
| Dockle | goodwithtech/dockle | Apache-2.0 | US$ 0 | Sim (tarball + checksum) |
| Kubescape | kubescape/kubescape (CNCF) | Apache-2.0 | US$ 0 | Sim (binário pinado por SHA256) |
| Polaris | FairwindsOps/polaris | Apache-2.0 | US$ 0 | Sim (tarball + checksum) |
| kube-score | zegl/kube-score | Apache-2.0 | US$ 0 | Sim (tarball + checksum) |
| tfsec | aquasecurity/tfsec | Apache-2.0 | US$ 0 | Sim (binário + checksum; emite AVD, correlaciona com o Trivy) |
| Terrascan | tenable/terrascan | Apache-2.0 | US$ 0 | Sim (tarball + checksum; terrascan init offline) |
| Regula | fugue/regula | Apache-2.0 | US$ 0 | Sim (tarball + checksum) |
| Conftest | open-policy-agent/conftest | Apache-2.0 | US$ 0 | Sim (tarball + checksum; roda o SEU Rego de ./policy) |
A imagem também inclui pacotes base do Alpine Linux e, para o Checkov, um runtime Python com a árvore de dependências do Checkov (várias licenças OSI). O bill of materials autoritativo é o SBOM SPDX de cada release — atestado para a imagem (
actions/attest-sbom; verifique comgh attestation verify) e publicado por binário (*.sbom.json). A tabela acima é o resumo humano dos scanners de topo.Pontos de atenção de licenciamento (não monetários, mas de compliance): - Bancos de dados de vulnerabilidades (ex.: o DB do grype) podem ter termos próprios distintos do código do scanner. A
:fullcongela o DB do grype no build (comGRYPE_DB_VALIDATE_AGE=false, sem expiração) — confirmar os termos de redistribuição do DB. Gap conhecido. - Marcas registradas: a Apache-2.0 (cláusula 6) não concede direito sobre nomes/marcas dos scanners. Empacotá-los não autoriza usar a marca para promover o Quorum. - Avisos de licença/atribuição já estão consolidados emTHIRD_PARTY_NOTICES.md— antes um gap, agora fechado.
Custo monetário total de licenciamento (Quorum + 12 scanners): US$ 0. O custo aqui é de compliance/atribuição, não financeiro.
Pacote de conhecimento consultivo. A camada consultiva opcional traz templates de remediação curados e um corpus OWASP fixado por digest (
knowledge/*.yaml) — dados, não código, todos sob a licença Apache-2.0 do projeto, logo US$ 0. A partir da v0.8.3 o pacote e o crosswalk também ganham seu próprio atestado SLSA de build-provenance a cada release (jobknowledgedorelease.yml; verifique comgh attestation verify knowledge/owasp/corpus.yaml). Nenhum modelo pago é embutido: a inferência local é BYO no host, a remota é opcional e paga pelo consumidor (ver §2 e 13-ia.md).
6. Equipe (perfis e faixas)¶
O custo dominante do projeto é tempo humano. As faixas salariais abaixo são estimativas de mercado (USD anual fully-loaded e o equivalente aproximado em BRL) e variam enormemente por geografia e senioridade — trate como ordem de grandeza, não como cotação.
| Perfil | Responsabilidade no Quorum | Faixa USD/ano (est.) | Faixa BRL/mês (est.) |
|---|---|---|---|
| Eng. Go / Plataforma (sênior) | Núcleo (orquestrador, correlate, consenso, model), 12 adapters | US$ 120k–200k | R$ 18k–40k |
| Eng. Segurança / AppSec | Crosswalk (AVD/CIS + hub C-#### do kubescape para K8s), severidade, validação de consenso, threat model | US$ 110k–180k | R$ 16k–35k |
| Eng. DevOps / Supply-chain | CI/CD, cosign/SLSA, SBOM atestado, GHCR, GoReleaser, hardening de imagem | US$ 110k–180k | R$ 16k–35k |
| Tech writer / DevRel (parcial) | Docs (este conjunto, publicado no GitHub Pages), README, exemplos, adoção | US$ 80k–130k | R$ 10k–22k |
| Mantenedor/PM (parcial) | Triagem de issues/PRs, releases, roadmap | US$ 100k–160k | R$ 14k–28k |
As conversões em BRL são aproximadas e assumem fully-loaded ÷ 12 ao câmbio de R$ 5,50; encargos e impostos brasileiros (CLT/PJ) não são modelados em detalhe.
6.1 Composição por cenário¶
| Cenário | Composição típica | FTE total (est.) | Custo anual USD (est.) | Custo mensal BRL (est.) |
|---|---|---|---|---|
| Mantenedor OSS solo | 1 pessoa cobrindo todos os papéis, meio período/voluntário | 0,1–0,3 FTE | US$ 0 (voluntário) a ~US$ 50k | R$ 0 a ~R$ 23k |
| Equipe enxuta | 1 Go sênior + 1 híbrido AppSec/DevOps + writer parcial | ~2,3 FTE | ~US$ 350k–500k | ~R$ 160k–230k |
| Equipe dedicada | 2 Go + 1 AppSec + 1 DevOps + writer + mantenedor parcial | ~4,5–5 FTE | ~US$ 650k–950k | ~R$ 300k–435k |
No cenário OSS solo, o custo financeiro real costuma ser próximo de zero (trabalho voluntário + cotas gratuitas de OSS do GitHub). O verdadeiro custo é o risco de bus-factor e a velocidade de manutenção limitada — agravado por 12 scanners para acompanhar.
7. Operação e manutenção (recorrente)¶
Mesmo sem runtime hospedado, há manutenção contínua — e é aqui que mora o custo real do projeto. Com o dobro de scanners, esta é a linha que mais cresceu desde a v0.2.3.
| Atividade recorrente | Frequência (est.) | Esforço (est.) | Por quê |
|---|---|---|---|
Bumps de versão dos scanners (ARGs do Dockerfile.full, 12 pins) |
mensal/trimestral | 1–3 dias | Scanners lançam rápido; pins ficam obsoletos; kubescape/tfsec/terrascan/regula/conftest exigem re-resolver o checksum |
Rebuild da imagem :full (DB do grype congelado) |
por release / quando o DB envelhece | automatizado + revisão | O DB congela no build (GRYPE_DB_VALIDATE_AGE=false); sem rebuild fica obsoleto |
| Acompanhar mudanças de output dos scanners | a cada major de scanner | 1–5 dias | Parsers/adapters quebram se o JSON muda (agora 12 parsers) |
Manutenção dos contract-tests (fixtures em internal/adapter/testdata) |
junto com os bumps | horas | Garantir parsing fiel ao modelo canônico; cobertura no CI |
| Crosswalk (regra→controle AVD/CIS e hub C-#### do kubescape) | conforme novas regras surgem | horas–dias | Mapear novas regras; consenso IaC (aws/azure/gcp) e K8s |
| Triagem de issues/PRs + release | contínuo | variável | Saúde do projeto OSS |
| Hardening de supply-chain (pins por digest, imagem base, SLSA/SBOM, atestado do pacote de conhecimento) | trimestral | horas | Manter atestados e bases pinados por @sha256 |
| Atualização de dependências Go (Dependabot/manual) | mensal | horas | Segurança/atualidade |
Custo de manutenção monetizado (estimativa, sobre o tempo da equipe):
| Cenário | Esforço de manutenção/mês (est.) | Custo mensal USD (est.) | Custo mensal BRL (est.) |
|---|---|---|---|
| OSS solo | 3–8 dias (voluntário) | US$ 0 (ou custo de oportunidade) | R$ 0 |
| Equipe enxuta | ~0,5–0,7 FTE alocado | ~US$ 8k–14k | ~R$ 44k–77k |
| Equipe dedicada | ~1–1,3 FTE alocado | ~US$ 15k–22k | ~R$ 82k–121k |
O custo de infra recorrente (Actions + armazenamento) é marginal perto do custo de tempo: mesmo no pior caso privado estimado (§3) soma ~US$ 25–45/mês — uma fração de um único dia de engenharia.
8. Custo de escalabilidade¶
A escalabilidade do Quorum tem dois vetores de custo distintos, e é importante não confundi-los.
8.1 Escalar o produto (mais adapters, mais cobertura)¶
Adicionar um scanner = adicionar um Adapter (ver internal/adapter/); nada no núcleo muda. O
custo é linear e previsível, dominado por engenharia, não por infra. A passagem de 6 para 12
scanners é a materialização exata deste vetor.
flowchart LR
A["Novo scanner desejado"] --> B["Escrever adapter<br/>(Name/Version/Supports/Capabilities/Run + parser)"]
B --> C["Contract test + fixtures<br/>(internal/adapter/testdata)"]
C --> D["Crosswalk de regras<br/>(se MISCONFIG/K8S_POSTURE)"]
D --> E["Empacotar no :full<br/>(ARG de versão, pin/checksum)"]
E --> F["Custo recorrente:<br/>manter o pin + parser"]| Item de custo ao adicionar 1 adapter | Esforço único (est.) | Custo recorrente |
|---|---|---|
| Implementar adapter + parser | 2–5 dias-eng | — |
| Contract test + fixtures | 0,5–1 dia-eng | manutenção a cada major de scanner |
| Crosswalk (se misconfig/postura K8s) | 0,5–2 dias-eng | atualizar conforme novas regras surgem |
Empacotar no :full (ARG/pin/checksum) |
horas | +tamanho da imagem; +tempo de build; +bump recorrente |
| Aumento no tempo de scan do consumidor | — | scanners rodam em paralelo (goroutines), mas competem por CPU/RAM/IO |
Cada novo scanner empacotado aumenta o tamanho da
:full(mais armazenamento, mais tempo de pull para o consumidor) e acrescenta dívida de manutenção recorrente (mais um pin, mais um parser para acompanhar). Com 12 engines, este é o custo de longo prazo mais subestimado — e o que mais pesou na v0.8.x.
8.2 Escalar o build/CI (mais commits, mais releases)¶
| Driver de crescimento | Efeito de custo | Mitigação |
|---|---|---|
| Mais PRs/commits | mais minutos de CI/E2E | paths-ignore, cache (já em uso) |
| Mais releases | mais builds da :full (lentos, ~2–3 GB) + mais tags no GHCR |
retenção/GC; releases menos frequentes |
| Build arm64 via QEMU | minutos caros (emulação) | runner arm nativo (futuro) |
Mais scanners na :full |
build mais longo + imagem maior | manter a :slim como caminho BYO-scanners |
8.3 Escalar a adoção (mais consumidores)¶
| Driver | Quem paga | Custo para o projeto |
|---|---|---|
Mais docker pull / downloads |
edge do GHCR/GitHub | ~US$ 0 (egress coberto pelo GitHub) |
| Mais execuções de scan | Consumidor (CI dele) | US$ 0 para o Quorum |
Mais uso de consultoria (--advice) |
Consumidor (modelo no host / API remota dele) | US$ 0 para o Quorum (sem custo por token para o projeto) |
| Mais issues/suporte | Equipe | tempo (ver §7) |
Propriedade-chave do modelo CLI: a adoção escala sem custo de runtime para o projeto. Mais usuários não aumentam a conta de nuvem do Quorum (não há nuvem); só aumentam a carga de suporte/manutenção (tempo humano). A camada consultiva mantém essa propriedade: a inferência local é BYO no host do consumidor e a remota é a API paga opcional do consumidor — nenhuma delas fatura o projeto. A GitHub Action (
action.yml, composite) e a tag móvelv0reduzem a fricção de adoção sem transferir custo de runtime para o projeto.
9. Resumo executivo de custos¶
| Categoria | OSS solo (est.) | Equipe enxuta (est.) | Equipe dedicada (est.) |
|---|---|---|---|
| Build/CI (Actions) | US$ 0 (público) | ~US$ 0–21/mês | ~US$ 21–60/mês |
| Armazenamento (GHCR/Releases) | US$ 0 (público) | ~US$ 0–22/mês | ~US$ 8–22/mês |
| Monitoramento de runtime | N/A (US$ 0) | N/A | N/A |
| Licenciamento (Quorum + 12 scanners) | US$ 0 | US$ 0 | US$ 0 |
| Equipe + manutenção | US$ 0 (voluntário) | ~US$ 350k–500k/ano | ~US$ 650k–950k/ano |
| Custo total dominante | tempo voluntário | folha | folha |
pie showData
title Composicao de custo (equipe dedicada, estimativa)
"Equipe / manutencao" : 96
"Build/CI" : 1
"Armazenamento" : 1
"Licenciamento" : 0
"Runtime hospedado" : 0Mensagem central: >95% do custo é equipe/tempo. A infra de build/distribuição é marginal (mesmo com a
:fullmaior por causa dos 12 scanners); licenciamento e runtime hospedado são zero. Otimizar custo = otimizar eficiência de manutenção (automatizar os 12 bumps de pin, manter os contract-tests verdes, reduzir a dívida dos adapters).
Checklist de governança de custos¶
- [ ] Definir uma política de retenção/GC para tags do GHCR (controla armazenamento; ainda mais relevante com uma
:fullde ~2–3 GB). - [ ] Adicionar
paths-ignorepara PRs só de docs eme2e.yml/ci.yml(corta minutos). - [ ] Automatizar o bump das 12 versões dos scanners (ex.: Dependabot/Renovate para os ARGs do Dockerfile) incl. re-resolver checksums.
- [x] Documentar as licenças/atribuições de cada scanner empacotado na
:full(THIRD_PARTY_NOTICES.md+ SBOM SPDX atestado). - [ ] Confirmar os termos de redistribuição do DB do grype para o DB congelado na
:full. - [ ] Avaliar um runner arm nativo para evitar o QEMU lento no build
:slim. - [ ] Acompanhar mensalmente o consumo de minutos do Actions (alertar antes do excedente, se privado).
Premissas¶
- Câmbio: US$ 1 ≈ R$ 5,50. Valores em BRL são conversões aproximadas; não consideram encargos/impostos brasileiros (CLT/PJ) em detalhe.
- Repositório OSS público: assume-se que
quorum-sec-scané público, então GitHub Actions e o armazenamento de pacotes/artefatos caem em cotas gratuitas — daí os cenários "US$ 0". As faixas pagas modelam apenas o caso privado/excedente como referência. - Preço do minuto de Actions (Linux): ~US$ 0,008/min (excedente típico). O Quorum usa apenas
ubuntu-latest(o mais barato); runners macOS/Windows/grandes não são usados. - Volume de eventos de CI (PRs, E2E, releases, docs por mês) e durações dos workflows são
estimativas de ordem de grandeza, não medições — derivadas dos workflows reais
(
ci.yml,e2e.yml,release.yml,docs.yml,tag-major.yml). - Tamanhos de imagens/artefatos não são medidos no repositório; são qualitativos, inferidos do
conteúdo dos Dockerfiles (
:fullempacota os 12 scanners + Python/Checkov + DB do grype;:slim, só o binário). Ver 10-infraestrutura.md §3. - Faixas salariais são estimativas de mercado fully-loaded e variam muito por geografia/senioridade; trate como ordem de grandeza.
- Licenças dos scanners: confirmadas como Apache-2.0 nas versões pinadas em
Dockerfile.full, conformeTHIRD_PARTY_NOTICES.md. A lista autoritativa e completa (incl. dependências transitivas e o runtime Python do Checkov) é o SBOM SPDX atestado de cada release. A licença do Quorum é confirmada como Apache-2.0 viaLICENSE. - A camada consultiva é opcional e não adiciona custo de runtime ao projeto:
--adviceé desligada por padrão e presentation-only; as Fases 0/2 são determinísticas (sem modelo), a Fase 1 (--advice-provider=local) roda no host do consumidor, e a Fase 3 (--advice-provider=remote) chama uma API externa que o consumidor consente e paga. Nenhum modelo pago é embutido ou hospedado pelo projeto. - Sem runtime hospedado: o produto roda no CI/estação de trabalho do consumidor; os custos de operação do scan são do consumidor, fora do escopo de orçamento do projeto.