Costs¶
Cost reference document for Quorum (
quorum-sec-scan), v0.8.3. Revision: 2026-07-04. Written in en-US, enterprise standard. Every monetary value in this document is an estimate based on explicit assumptions (see Assumptions), not on real invoices. Always check the provider's current pricing.
Quorum is a CLI/Docker consensus security scanning tool. The most important cost consequence is architectural: Quorum does not operate any runtime infrastructure of its own. It runs in the consumer's CI or workstation and terminates the process when the scan finishes. Therefore, the cost of operating the product is mostly shifted onto the consumer (their CI minutes), and the cost of the Quorum project concentrates on build, distribution (supply chain) and maintenance — not runtime cloud.
This document estimates costs under two scenarios — solo OSS maintainer and dedicated team — covering: build/distribution infra (GitHub Actions minutes, GHCR storage), monitoring (N/A today), licensing (Quorum's OSS and the scanners'), staffing, operation/maintenance and scalability. Classic runtime cost components (cloud, database, APM) are declared N/A with justification, in line with 10-infraestrutura.md and 14-observabilidade.md.
Scale shift since v0.2.3. Quorum jumped from 6 to 12 packaged scanners (trivy, grype, checkov, kics, dockle, kubescape, polaris, kube-score, terrascan, tfsec, regula and conftest). The cost effect is concentrated: the
:fullimage got bigger (more binaries + pre-cached grype DB) and there is more recurring maintenance debt (more pins and parsers). The structural assumptions (ephemeral CI, GHCR, no hosted runtime) remain unchanged.
1. Cost mental model¶
flowchart LR
subgraph proj["QUORUM PROJECT COST"]
B["Build / CI<br/>(GitHub Actions minutes)"]
D["Distribution<br/>(GHCR storage + Releases)"]
E["Team<br/>(maintenance, adapters, supply chain)"]
L["Licensing<br/>(Apache-2.0, scanners' OSS)"]
end
subgraph cons["CONSUMER COST (not Quorum's)"]
R["Runtime in their CI<br/>(minutes per scan)"]
P["Image pull / binary download"]
end
B --> D --> P
E --> B
P -.-> R| Cost axis | Who pays | Nature | Relative magnitude |
|---|---|---|---|
| Build / CI | Quorum project | Variable (per push/PR/release) | Low–medium |
| Distribution (storage) | Quorum project | Recurring (storage) | Low |
| Team / maintenance | Quorum project | Recurring (human time) | Dominant |
| Licensing | — | US$ 0 (all Apache-2.0) | Zero monetary |
| Runtime monitoring | — | N/A (no hosted service) | Zero |
| Scan runtime | Consumer | Variable (their CI) | Out of the project's scope |
Early conclusion: Quorum's largest cost is not infra money, it is engineering time (maintaining the 12 adapters, supply chain and tracking scanner versions).
2. Own runtime cost — N/A¶
The project does not provision any continuous-operation resource. Each item below is US$ 0 for the project because it does not exist.
| Component | Status | Technical justification |
|---|---|---|
| Cloud compute (VM/serverless) | N/A — US$ 0 | No hosted service; the binary/image runs in the consumer's environment. |
| Runtime Kubernetes | N/A — US$ 0 | Quorum is a short-lived CLI process; it scans K8s, it does not run on K8s as a product. |
| Relational database | N/A — US$ 0 | Correlation/consensus in memory; the only state is a local alias cache (~/.cache/quorum/aliases.json, perm 0600). |
| REST API / gateway / LB / CDN / WAF | N/A — US$ 0 | No exposed HTTP surface. |
| Hosted APM / metrics / tracing | N/A — US$ 0 | No long-running service; diagnostics via stderr, per-scanner status and, optionally, a local Prometheus textfile (--metrics, see §4). |
| Signing key (HSM/KMS) | N/A — US$ 0 | cosign keyless (GitHub OIDC); nothing to store/rotate. |
| AI / LLM (paid API) | N/A — US$ 0 | The deterministic core has no AI. The opt-in advisory layer (--advice, off by default) runs local inference on-host (no per-token cost) and only reaches an external API under --advice-provider=remote, which the consumer gates (--advice-allow-egress) and pays for — never the project (see 13-ia.md). |
The OSV.dev cost is also US$ 0: it is a public service queried without credentials, with graceful degradation and switchable off via
--offline.
3. Build/distribution infra (the project's real cost)¶
Quorum's "infra" is GitHub Actions (ephemeral build) + GHCR/GitHub Releases (distribution). In a public OSS repository, GitHub offers free Actions and package/artifact storage within the applicable policies — so, in the OSS scenario, the direct monetary cost tends to US$ 0. The estimates below model the private/overage case (when the repo is private or quotas are exceeded), to give a reference range.
3.1 GitHub Actions minutes¶
Real repository workflows:
| Workflow | Trigger | Jobs / steps | Estimated duration* |
|---|---|---|---|
ci.yml |
push to main, PRs |
go vet, go test -race (coverage), build, smoke |
~3–6 min |
e2e.yml |
push/PR, dispatch | installs scanners, grype db update, consensus scans (IaC + K8s + SCA) |
~8–15 min |
release.yml |
semver tag vX.Y.Z, dispatch |
full/slim matrix (Buildx+QEMU, cosign keyless, SLSA build-provenance, attested SPDX SBOM) + GoReleaser (binaries) + knowledge job (attests the advisory knowledge pack + crosswalk) |
~18–35 min |
docs.yml |
docs push (with paths) |
build MkDocs Material + publish GitHub Pages | ~2–4 min |
tag-major.yml |
after a semver release | advances the moving v0 tag |
<1 min |
* Order-of-magnitude estimates on an ubuntu-latest runner. e2e.yml and release.yml are the
priciest because they download/verify scanners, update the grype DB and do multi-arch builds with
QEMU (arm64 emulation is notoriously slow on :slim). With 12 scanners (was 6), e2e.yml
grew: it installs/verifies more binaries by checksum and runs more engines per scan.
Monthly consumption model (estimate, Linux runner):
| Activity | Events/month (est.) | Min/event (est.) | Min/month (est.) |
|---|---|---|---|
| CI on PRs/pushes | 60 | 5 | 300 |
| E2E (consensus, 12 scanners) | 40 | 11 | 440 |
| Release (semver tags + tag-major) | 2 | 28 | 56 |
| Docs (MkDocs, docs-only) | 20 | 3 | 60 |
| Total | — | — | ~856 min/month |
Cost of the minutes (only if private/overage):
| Scenario | Minutes/month | Linux unit price (est.) | Cost USD/month (est.) | Cost BRL/month (est.) |
|---|---|---|---|---|
| OSS (public repo) | ~856 | US$ 0 (free quota) | US$ 0 | R$ 0 |
| Private, within the included quota | ~856 | covered by the plan | ~US$ 0 | ~R$ 0 |
| Private, overage | ~856 | ~US$ 0.008/min | ~US$ 6.8 | ~R$ 38 |
| Private, active team (3× volume) | ~2,570 | ~US$ 0.008/min | ~US$ 21 | ~R$ 113 |
Assumed FX rate: US$ 1 ≈ R$ 5.50 (see Assumptions). The ~US$ 0.008 Linux per-minute price is the typical GitHub Actions overage price; larger/macOS/Windows runners cost multiples of that — Quorum uses only
ubuntu-latest, the cheapest one.
CI cost-reduction levers:
- [x] Use only
ubuntu-latest(already the case). - [x] Cache the Docker build (
cache-from/cache-to: type=gha) already configured inrelease.yml. - [x] Cache Go modules (
actions/setup-go ... cache: true) already inci.yml/e2e.yml. - [x] grype DB pre-cached in the
:fullimage avoids adb updateon the consumer's runtime. - [x] Packaged scanners verified by checksum/digest (avoids re-download in every release job).
- [x]
docs.ymlrestricted bypaths(does not spend minutes on non-docs changes). - [ ] Restrict
e2e.ymlon docs-only PRs viapaths-ignore(gap — see §9). - [ ] Avoid arm64 build via QEMU where possible (slow/expensive) — consider a native arm runner.
3.2 Storage (GHCR + Releases)¶
| Artifact | Where | Est. size* | Note |
|---|---|---|---|
:slim image (amd64+arm64) |
GHCR | ~30–60 MB/arch | Just the binary + ca-certificates + crosswalks |
:full image (amd64) |
GHCR | ~2–3 GB | 12 scanners + Python/Checkov venv + pre-cached grype DB |
| Native binaries (6 targets) | GitHub Releases | ~10–20 MB each | linux/darwin/windows × amd64/arm64 (GoReleaser) |
Per-binary SBOMs (*.sbom.json) |
GitHub Releases | KB–MB | SPDX generated by GoReleaser/syft |
| Signatures/attestations | GHCR/Releases | KB | cosign .sig/.pem, SLSA build-provenance, attest-sbom, knowledge-pack attestation |
* Qualitative estimates derived from the Dockerfiles' contents; not measured in the repo.
:full grew from ~1–2 GB (6 scanners, v0.2.3) to ~2–3 GB because it now packages 12 engines
(includes terrascan with policies via terrascan init, regula, conftest, polaris, kube-score,
tfsec) in addition to Checkov's Python runtime.
:full dominates storage. Each release adds a new versioned tag; without a retention policy the
history grows linearly — and each tag is now bigger.
| Scenario | Est. accumulated storage (12 months) | Cost USD/month (est.) | Cost BRL/month (est.) |
|---|---|---|---|
| OSS (public repo) | tens of GB | US$ 0 (included) | R$ 0 |
| Private, no GC of old tags | ~50–90 GB | ~US$ 8–22 | ~R$ 44–121 |
| Private, with GC (keep last N) | ~8–15 GB | ~US$ 2–4 | ~R$ 11–22 |
Levers:
- [ ] Retention/cleanup policy for old versions in GHCR (gap — see §9).
- [x]
@sha256pinning recommended to the consumer reduces dependence on many moving tags. - [x] The moving
v0tag (advanced bytag-major.yml) gives a stable target without multiplying tags. - [x] Publish
:fullonly on releases (not on every commit) — already the case. - [x] Keep
:slimas the BYO-scanners path for those who do not want the:fullweight.
4. Monitoring / observability — N/A (today)¶
There is no runtime monitoring cost because there is no hosted runtime to monitor (see 14-observabilidade.md). The product's "observability" is:
| Item | Cost | Nature |
|---|---|---|
stderr logs + per-scanner status (ran/skipped/unavailable/error/timeout) |
US$ 0 | Built in; consumed by the user's CI. --log-format text\|json for structured ingestion. |
| SARIF/JSON/XML report as an artifact | US$ 0 | Generated locally |
Prometheus metrics (--metrics <file>) |
US$ 0 | Local textfile; the consumer decides whether to collect it via node-exporter/pushgateway (their cost, not Quorum's). Under --advice, advisory-only counters are also emitted (quorum_advice_enriched, quorum_advice_provider, quorum_advice_fix) — same local textfile, no extra service. |
| Hosted APM/Datadog/Grafana/Prometheus | N/A | No long-running service on the project's side |
Future proposal (NOT implemented)¶
Should the separate runtime module mentioned in DESIGN §13 (Falco/Tetragon/OpenSCAP as a standalone product) materialize, then there would be a continuous observability cost (stream collection, event storage, dashboards). Out of scope for Quorum v0.8.x.
5. Licensing¶
5.1 Quorum's license¶
| Item | Value |
|---|---|
| Project license | Apache License 2.0 (see LICENSE) |
| Cost of use/redistribution | US$ 0 — permissive, royalty-free, with a patent grant |
| Obligations | Keep copyright/license notices; state modifications; (if any) include NOTICE |
Apache-2.0 imposes no copyleft on those who use/integrate Quorum, and grants an explicit patent license (clause 3). Quorum's monetary licensing cost: zero.
5.2 Packaged scanners' licenses¶
Quorum orchestrates third-party OSS scanners. Each has its own license; Quorum invokes them
as external processes (via os/exec, see internal/adapter/adapter.go) and
packages them in the :full image. The licenses below are confirmed and documented in
THIRD_PARTY_NOTICES.md:
at the versions pinned in Dockerfile.full,
all 12 scanners are Apache-2.0.
| Scanner | Project/origin | License | Cost | Shipped in :full? |
|---|---|---|---|---|
| Trivy | aquasecurity/trivy | Apache-2.0 | US$ 0 | Yes (image pinned by @sha256) |
| Grype | anchore/grype | Apache-2.0 | US$ 0 | Yes (official installer, checksum) |
| Syft (Grype support) | anchore/syft | Apache-2.0 | US$ 0 | Yes (official installer, checksum) |
| Checkov | bridgecrewio/checkov (Prisma) | Apache-2.0 | US$ 0 | Yes (pip install in an isolated venv) |
| KICS | Checkmarx/kics | Apache-2.0 | US$ 0 | Yes (image pinned by @sha256) |
| Dockle | goodwithtech/dockle | Apache-2.0 | US$ 0 | Yes (tarball + checksum) |
| Kubescape | kubescape/kubescape (CNCF) | Apache-2.0 | US$ 0 | Yes (binary pinned by SHA256) |
| Polaris | FairwindsOps/polaris | Apache-2.0 | US$ 0 | Yes (tarball + checksum) |
| kube-score | zegl/kube-score | Apache-2.0 | US$ 0 | Yes (tarball + checksum) |
| tfsec | aquasecurity/tfsec | Apache-2.0 | US$ 0 | Yes (binary + checksum; emits AVD, correlates with Trivy) |
| Terrascan | tenable/terrascan | Apache-2.0 | US$ 0 | Yes (tarball + checksum; terrascan init offline) |
| Regula | fugue/regula | Apache-2.0 | US$ 0 | Yes (tarball + checksum) |
| Conftest | open-policy-agent/conftest | Apache-2.0 | US$ 0 | Yes (tarball + checksum; runs YOUR Rego from ./policy) |
The image also includes Alpine Linux base packages and, for Checkov, a Python runtime with Checkov's dependency tree (several OSI licenses). The authoritative bill of materials is the SPDX SBOM of each release — attested for the image (
actions/attest-sbom; verify withgh attestation verify) and published per-binary (*.sbom.json). The table above is the human summary of the top-level scanners.Licensing watch points (non-monetary, but compliance-related): - Vulnerability databases (e.g. the grype DB) may carry their own terms distinct from the scanner's code.
:fullfreezes the grype DB at build time (withGRYPE_DB_VALIDATE_AGE=false, no expiration) — confirm the DB's redistribution terms. Known gap. - Trademarks: Apache-2.0 (clause 6) grants no right over the scanners' names/marks. Packaging them does not authorize using the mark to promote Quorum. - License/attribution notices are already consolidated inTHIRD_PARTY_NOTICES.md— once a gap, now closed.
Total monetary licensing cost (Quorum + 12 scanners): US$ 0. The cost here is one of compliance/attribution, not financial.
Advisory knowledge pack. The opt-in advisory layer ships curated remediation templates and a digest-pinned OWASP corpus (
knowledge/*.yaml) — data, not code, all under the project's Apache-2.0 license, so US$ 0. As of v0.8.3 the pack and crosswalk also get their own SLSA build-provenance attestation each release (release.ymlknowledgejob; verify withgh attestation verify knowledge/owasp/corpus.yaml). No paid model is bundled: local inference is BYO on-host, remote is opt-in and paid by the consumer (see §2 and 13-ia.md).
6. Team (profiles and ranges)¶
The project's dominant cost is human time. The salary ranges below are market estimates (fully-loaded annual USD and the approximate BRL equivalent) and vary enormously by geography and seniority — treat as order of magnitude, not a quote.
| Profile | Responsibility in Quorum | USD/year range (est.) | BRL/month range (est.) |
|---|---|---|---|
| Go / Platform eng. (senior) | Core (orchestrator, correlate, consensus, model), 12 adapters | US$ 120k–200k | R$ 18k–40k |
| Security / AppSec eng. | Crosswalk (AVD/CIS + kubescape's C-#### hub for K8s), severity, consensus validation, threat model | US$ 110k–180k | R$ 16k–35k |
| DevOps / Supply-chain eng. | CI/CD, cosign/SLSA, attested SBOM, GHCR, GoReleaser, image hardening | US$ 110k–180k | R$ 16k–35k |
| Tech writer / DevRel (partial) | Docs (this set, published to GitHub Pages), README, examples, adoption | US$ 80k–130k | R$ 10k–22k |
| Maintainer/PM (partial) | Issue/PR triage, releases, roadmap | US$ 100k–160k | R$ 14k–28k |
BRL conversions are approximate and assume fully-loaded ÷ 12 at an R$ 5.50 FX rate; Brazilian charges and taxes (CLT/PJ) are not modeled in detail.
6.1 Composition per scenario¶
| Scenario | Typical composition | Total FTE (est.) | Annual cost USD (est.) | Monthly cost BRL (est.) |
|---|---|---|---|---|
| Solo OSS maintainer | 1 person covering all roles, part-time/volunteer | 0.1–0.3 FTE | US$ 0 (volunteer) to ~US$ 50k | R$ 0 to ~R$ 23k |
| Lean team | 1 senior Go + 1 hybrid AppSec/DevOps + partial writer | ~2.3 FTE | ~US$ 350k–500k | ~R$ 160k–230k |
| Dedicated team | 2 Go + 1 AppSec + 1 DevOps + writer + partial maintainer | ~4.5–5 FTE | ~US$ 650k–950k | ~R$ 300k–435k |
In the solo OSS scenario, the real financial cost is usually near zero (volunteer work + GitHub's free OSS quotas). The true cost is bus-factor risk and limited maintenance velocity — aggravated by 12 scanners to keep up with.
7. Operation and maintenance (recurring)¶
Even without hosted runtime, there is continuous maintenance — and this is where the project's real cost lives. With twice the scanners, this is the line that grew the most since v0.2.3.
| Recurring activity | Frequency (est.) | Effort (est.) | Why |
|---|---|---|---|
Scanner version bumps (Dockerfile.full ARGs, 12 pins) |
monthly/quarterly | 1–3 days | Scanners ship fast; pins go stale; kubescape/tfsec/terrascan/regula/conftest require re-resolving the checksum |
:full image rebuild (frozen grype DB) |
per release / when the DB ages | automated + review | The DB freezes at build (GRYPE_DB_VALIDATE_AGE=false); without a rebuild it goes stale |
| Tracking scanner output changes | at each scanner major | 1–5 days | Parsers/adapters break if the JSON changes (12 parsers now) |
Contract-test maintenance (fixtures in internal/adapter/testdata) |
alongside bumps | hours | Ensure faithful parsing to the canonical model; coverage in CI |
| Crosswalk (rule→AVD/CIS control and kubescape's C-#### hub) | as new rules appear | hours–days | Map new rules; IaC consensus (aws/azure/gcp) and K8s |
| Issue/PR triage + release | continuous | variable | OSS project health |
| Supply-chain hardening (digest pins, base image, SLSA/SBOM, knowledge-pack attestation) | quarterly | hours | Keep attestations and bases pinned by @sha256 |
| Go dependency refresh (Dependabot/manual) | monthly | hours | Security/currency |
Monetized maintenance cost (estimate, over team time):
| Scenario | Maintenance effort/month (est.) | Monthly cost USD (est.) | Monthly cost BRL (est.) |
|---|---|---|---|
| Solo OSS | 3–8 days (volunteer) | US$ 0 (or opportunity cost) | R$ 0 |
| Lean team | ~0.5–0.7 FTE allocated | ~US$ 8k–14k | ~R$ 44k–77k |
| Dedicated team | ~1–1.3 FTE allocated | ~US$ 15k–22k | ~R$ 82k–121k |
Recurring infra cost (Actions + storage) is marginal next to the time cost: even in the worst estimated private case (§3) it adds up to ~US$ 25–45/month — a fraction of a single engineering day.
8. Scalability cost¶
Quorum's scalability has two distinct cost vectors, and it is important not to conflate them.
8.1 Scaling the product (more adapters, more coverage)¶
Adding a scanner = adding an Adapter (see internal/adapter/); nothing in the core changes.
The cost is linear and predictable, dominated by engineering, not infra. The move from 6 to
12 scanners is the exact materialization of this vector.
flowchart LR
A["New scanner wanted"] --> B["Write adapter<br/>(Name/Version/Supports/Capabilities/Run + parser)"]
B --> C["Contract test + fixtures<br/>(internal/adapter/testdata)"]
C --> D["Rule crosswalk<br/>(if MISCONFIG/K8S_POSTURE)"]
D --> E["Package into :full<br/>(version ARG, pin/checksum)"]
E --> F["Recurring cost:<br/>maintain the pin + parser"]| Cost item when adding 1 adapter | One-time effort (est.) | Recurring cost |
|---|---|---|
| Implement adapter + parser | 2–5 eng-days | — |
| Contract test + fixtures | 0.5–1 eng-day | maintenance at each scanner major |
| Crosswalk (if misconfig/K8s posture) | 0.5–2 eng-days | update as new rules appear |
Package into :full (ARG/pin/checksum) |
hours | +image size; +build time; +recurring bump |
| Increase in the consumer's scan time | — | scanners run in parallel (goroutines), but compete for CPU/RAM/IO |
Each new packaged scanner increases
:full's size (more storage, more pull time for the consumer) and adds recurring maintenance debt (one more pin, one more parser to track). With 12 engines, this is the most underestimated long-term cost — and the one that weighed most in v0.8.x.
8.2 Scaling the build/CI (more commits, more releases)¶
| Growth driver | Cost effect | Mitigation |
|---|---|---|
| More PRs/commits | more CI/E2E minutes | paths-ignore, cache (already in use) |
| More releases | more :full builds (slow, ~2–3 GB) + more GHCR tags |
retention/GC; less frequent releases |
| arm64 build via QEMU | expensive minutes (emulation) | native arm runner (future) |
More scanners in :full |
longer build + bigger image | keep :slim as the BYO-scanners path |
8.3 Scaling adoption (more consumers)¶
| Driver | Who pays | Cost to the project |
|---|---|---|
More docker pull / downloads |
GHCR/GitHub edge | ~US$ 0 (egress covered by GitHub) |
| More scan executions | Consumer (their CI) | US$ 0 for Quorum |
More advisory (--advice) usage |
Consumer (on-host model / their remote API) | US$ 0 for Quorum (no per-token cost to the project) |
| More issues/support | Team | time (see §7) |
Key property of the CLI model: adoption scales with no runtime cost to the project. More users do not raise Quorum's cloud bill (there is no cloud); they only raise the support/maintenance load (human time). The advisory layer keeps this property: local inference is BYO on the consumer's host and remote is the consumer's opt-in paid API — neither bills the project. The GitHub Action (
action.yml, composite) and the movingv0tag reduce adoption friction without shifting runtime cost to the project.
9. Cost executive summary¶
| Category | Solo OSS (est.) | Lean team (est.) | Dedicated team (est.) |
|---|---|---|---|
| Build/CI (Actions) | US$ 0 (public) | ~US$ 0–21/month | ~US$ 21–60/month |
| Storage (GHCR/Releases) | US$ 0 (public) | ~US$ 0–22/month | ~US$ 8–22/month |
| Runtime monitoring | N/A (US$ 0) | N/A | N/A |
| Licensing (Quorum + 12 scanners) | US$ 0 | US$ 0 | US$ 0 |
| Team + maintenance | US$ 0 (volunteer) | ~US$ 350k–500k/year | ~US$ 650k–950k/year |
| Dominant total cost | volunteer time | payroll | payroll |
pie showData
title Cost composition (dedicated team, estimate)
"Team / maintenance" : 96
"Build/CI" : 1
"Storage" : 1
"Licensing" : 0
"Hosted runtime" : 0Central message: >95% of the cost is team/time. Build/distribution infra is marginal (even with the bigger
:fullfrom 12 scanners); licensing and hosted runtime are zero. Optimizing cost = optimizing maintenance efficiency (automating the 12 pin bumps, keeping contract tests green, reducing adapter debt).
Cost-governance checklist¶
- [ ] Define a retention/GC policy for GHCR tags (controls storage; even more relevant with a ~2–3 GB
:full). - [ ] Add
paths-ignorefor docs-only PRs ine2e.yml/ci.yml(cuts minutes). - [ ] Automate the bump of the 12 scanner versions (e.g. Dependabot/Renovate for Dockerfile ARGs) incl. re-resolving checksums.
- [x] Document the licenses/attributions of each scanner packaged in
:full(THIRD_PARTY_NOTICES.md+ attested SPDX SBOM). - [ ] Confirm the grype DB redistribution terms for the DB frozen in
:full. - [ ] Evaluate a native arm runner to avoid slow QEMU in the
:slimbuild. - [ ] Track Actions minute consumption monthly (alert before overage, if private).
Assumptions¶
- FX rate: US$ 1 ≈ R$ 5.50. BRL values are approximate conversions; they do not account for Brazilian charges/taxes (CLT/PJ) in detail.
- Public OSS repository:
quorum-sec-scanis assumed public, so GitHub Actions and package/artifact storage fall under free quotas — hence the "US$ 0" scenarios. The paid ranges model the private/overage case only as a reference. - Actions minute price (Linux): ~US$ 0.008/min (typical overage). Quorum uses only
ubuntu-latest(cheapest); macOS/Windows/large runners are not used. - CI event volume (PRs, E2E, releases, docs per month) and workflow durations are
order-of-magnitude estimates, not measurements — derived from the real workflows
(
ci.yml,e2e.yml,release.yml,docs.yml,tag-major.yml). - Image/artifact sizes are not measured in the repository; they are qualitative, inferred from
the Dockerfiles' contents (
:fullpackages the 12 scanners + Python/Checkov + grype DB;:slim, just the binary). See 10-infraestrutura.md §3. - Salary ranges are fully-loaded market estimates and vary heavily by geography/seniority; treat as order of magnitude.
- Scanners' licenses: confirmed as Apache-2.0 at the versions pinned in
Dockerfile.full, perTHIRD_PARTY_NOTICES.md. The authoritative and complete list (incl. transitive dependencies and Checkov's Python runtime) is the attested SPDX SBOM of each release. Quorum's license is confirmed as Apache-2.0 viaLICENSE. - Advisory layer is opt-in and adds no project runtime cost:
--adviceis off by default and presentation-only; Phase 0/2 are deterministic (no model), Phase 1 (--advice-provider=local) runs on the consumer's host, and Phase 3 (--advice-provider=remote) calls an external API the consumer consents to and pays for. No paid model is bundled or hosted by the project. - No hosted runtime: the product runs in the consumer's CI/workstation; scan operation costs are the consumer's, outside the project's budget scope.