5.3 KiB
5.3 KiB
Here’s a simple, big‑picture primer on how a modern, verifiable supply‑chain security platform fits together—and what each part does—before we get into the practical wiring and artifacts.
Topology & trust boundaries (plain‑English)
Think of the system as four layers, each with a clear job and a cryptographic handshake between them:
- Edge (where users & CI/CD touch the system)
- StellaRouter / UI receive requests, authenticate users/agents (OAuth2/OIDC), and fan them into the control plane.
- Trust boundary: everything from the outside must present signed credentials/attestations before it’s allowed deeper.
- Control Plane (brains & policy)
- Scheduler: queues and routes work (scan this image, verify that build, recompute reachability, etc.).
- Policy Engine: evaluates SBOMs, VEX, and signals against policies (“ship/block/defer”) and produces signed, replayable verdicts.
- Authority: key custody & identity (who can sign what).
- Attestor: issues DSSE/in‑toto attestations for scans, verdicts, and exports.
- Timeline / Notify: immutable audit log + notifications.
- Trust boundary: only evidence and identities blessed here can influence decisions.
- Evidence Plane (facts, not opinions)
- Sbomer: builds SBOMs from images/binaries/source (CycloneDX 1.6 / SPDX 3.0.1).
- Excititor: runs scanners/executors (code, binary, OS, language deps, “what’s installed” on hosts).
- Concelier: correlates advisories, VEX claims, reachability, EPSS, exploit telemetry.
- Reachability / Signals: computes “is the vulnerable code actually reachable here?” plus runtime/infra signals.
- Trust boundary: raw evidence is tamper‑evident and separately signed; opinions live in policy/verdicts, not here.
- Data Plane (do the heavy lifting)
- Horizontal workers/scanners that pull tasks, do the compute, and emit artifacts and attestations.
- Trust boundary: workers are isolated per tenant; outputs are always tied to inputs via cryptographic subjects.
Artifact association & tenant isolation (why OCI referrers matter)
- Every image/artifact becomes a subject in the registry.
- SBOMs, VEX, reachability slices, and verdicts are published as OCI referrers that point back to that subject (no guessing or loose coupling).
- This lets you attach multiple, versioned, signed facts to the same build without altering the image itself.
- Tenants stay cryptographically separate: different keys, different trust roots, different namespaces.
Interfaces, dataflows & provenance hooks (what flows where)
-
Workers emit:
- SBOMs in CycloneDX 1.6 and/or SPDX 3.0.1.
- VEX claims (affected/not‑affected, under‑investigation, fixed).
- Reachability subgraphs (the minimal “slice” proving a vuln is or isn’t callable in this build).
- All wrapped as DSSE/in‑toto attestations and attached via OCI referrers to the image digest.
-
Policy Engine:
- Ingests SBOM/VEX/reachability/signals, applies rules, and emits a signed verdict (OCI‑attached).
- Verdicts are replayable: same inputs → same output, with the exact inputs hashed and referenced.
-
Timeline:
- Stores an audit‑ready record of who ran what, with which inputs, producing which attestations and verdicts.
Why this design helps in real life
- Audits become trivial: point an auditor at the image digest; they can fetch all linked SBOMs/VEX/attestations/verdicts and replay the decision.
- Noise collapses: reachability + VEX + policy means you block only what matters for this build in this environment.
- Multi‑tenant safety: each customer’s artifacts and keys are isolated; strong boundaries reduce blast radius.
- No vendor lock‑in: OCI referrers and open schemas (CycloneDX/SPDX/in‑toto/DSSE) let you interoperate.
Minimal “starter” policy you can adopt Day‑1
- Gate on any CVE with reachability=“reachable” AND severity ≥ High, unless a trusted VEX source says “not affected” with required evidence hooks (e.g., feature flag off, code path pruned).
- Fail on unknowns above a threshold (e.g., >N packages with missing metadata).
- Require signed SBOM + signed verdict for prod deploys; store both in Timeline.
Quick glossary
- SBOM: Software Bill of Materials (what’s inside).
- VEX: Vulnerability Exploitability eXchange (is a CVE actually relevant?).
- Reachability: graph proof that vulnerable code is (not) callable.
- DSSE / in‑toto: standardized ways to sign and describe supply‑chain steps and their outputs.
- OCI referrers: a registry mechanism to hang related artifacts (SBOMs, attestations, verdicts) off an image digest.
A tiny wiring sketch
User/CI → Router/UI → Scheduler ─→ Workers (Sbomer/Excititor)
│ │
│ └─→ emit SBOM/VEX/reachability (DSSE, OCI-referrers)
│
Policy Engine ──→ signed verdict (OCI-referrer)
│
Timeline/Notify (immutable audit, alerts)
If you want, I can turn this into a one‑pager architecture card, plus a checklist your PMs/engineers can use to validate each trust boundary and artifact flow in your Stella Ops setup.