Compliance mapping

This page maps requirement families from four reference frameworks to the Tobby mechanism that answers them and to the proof you can check. It is a mapping, not a certification claim: none of these frameworks certifies a product, and Tobby claims no label. Use the rows as raw material for an accreditation or audit file; verify each proof yourself — that is what the verification page is for.

Statuses: delivered (in the current release, proof available) or upcoming (with its milestone — track them on project status).

SLSA v1.0

SLSA v1.0 defines Build levels L0–L3. Tobby targets and claims Build L3 — the highest defined level — plus reproducibility on top. Documents citing an “L4” refer to the retired v0.1 draft (ADR-0011).

Requirement	Tobby mechanism	Proof	Status
Provenance generated by a builder isolated from the project’s own workflow	slsa-github-generator trusted-builder reusable workflows (binaries and image), referenced by tag as the verifier requires	release.yml, ADR-0011	delivered (since v0.1.0)
Provenance available and verifiable by consumers	Exact slsa-verifier commands embedded in every release’s notes and in the docs	Verify a release	delivered
Beyond L3: reproducible builds	Bit-identical rebuild enforced by an independent double-build gate before any release publishes; consumer rebuild path documented	verify-reproducibility job in release.yml; independent rebuild	delivered

NIST SSDF (SP 800-218)

Practice group	Tobby mechanism	Proof	Status
PO — Prepare the organization	Pinned toolchain (mise.toml), protected trunk with mandatory review, DCO on every commit, published security policy	CONTRIBUTING.md, SECURITY.md	delivered
PS — Protect the software	Signed releases, SHA256SUMS under SLSA provenance, actions pinned by full commit SHA, third-party tools checksum-verified	release.yml, ci.yml	delivered
PW — Produce well-secured software	Numbered, testable requirements (SRS); strict lint with zero suppressions; race detector and anti-flaky double run; per-package coverage floor; full-history secret scanning	Tests and proofs, SRS	delivered; parser fuzzing and input-validation review upcoming (milestone 7)
RV — Respond to vulnerabilities	Trivy and govulncheck as merge and release gates; weekly image rebuild behind a Trivy gate; coordinated disclosure with patch releases	ci.yml, weekly-rebuild.yml, SECURITY.md	delivered

OWASP SCVS

Control family	Tobby mechanism	Proof	Status
V1 — Inventory	One SBOM per release binary, plus native image SBOMs generated at build time (not scanner-reconstructed)	release assets; ADR-0011	delivered
V2 — SBOM	CycloneDX, cosign-signed, verification command published	Verify a release	delivered
V3 — Build environment	Isolated trusted builder, SHA-pinned actions, reproducibility gate, declarative image build (melange+apko, no Dockerfile)	release.yml, ADR-0011	delivered
V4 — Package management	Locked module graph (go.sum, sumdb-verified installs), renovate-driven updates, checksum-pinned downloaded tools	repository root, ci.yml	delivered
V5 — Component analysis	Trivy (critical/high block), govulncheck with symbol-level reachability, dependency-license allowlist gate	ci.yml jobs vulnerabilities, govulncheck, licenses	delivered
V6 — Pedigree and provenance	SLSA L3 provenance per artifact, DCO sign-off per commit, changelog naming defects with root causes	release.yml, dco.yml, CHANGELOG	delivered

NIS2 (Directive 2022/2555)

NIS2 regulates entities, not software products. These rows map the Article 21(2) measure families a regulated operator must implement to what Tobby gives that operator — or applies to itself as a supplier in the operator’s supply chain.

Measure family	Tobby mechanism	Proof	Status
Supply-chain security (21(2)(d))	Verification at entry: cosign signatures against the destination’s own trust roots, pinned digests, registry allowlist; Tobby’s own releases verifiable end to end	Content trust, Verify a release	delivered
Vulnerability handling and disclosure (21(2)(e))	Published CVD process with patch releases for Tobby itself; policy-driven CVE scanning of the content Tobby moves, with an offline-updatable database	SECURITY.md; scanning: upcoming (milestone 6)	mixed — see cells
Cryptography (21(2)(h))	Sigstore/cosign verification, argon2id credential storage, TLS everywhere with private-CA support and no global “skip verify”	Security one-pager, milestone-4 audit (“zero InsecureSkipVerify”)	delivered
Access control (21(2)(i))	Authentication on by default, three-role RBAC on UI, API and registry, last-administrator invariant; enterprise identity (OIDC, SAML)	Auth and RBAC; OIDC/SAML: upcoming (milestone 6)	mixed — see cells
Logging and incident evidence (supports 21(2)(b))	Stable-schema security audit log, end-to-end run ID; the audit trail crosses the air gap on the medium	Audit log, tracing a transfer	delivered

Reading the table honestly

Two things this page will not do: claim a certification, and hide a gap behind a green row. Where a mechanism is partly delivered, the row says which part. The limits page states what Tobby does not do at all — no upstream qualification, no destination purge, no signing of anything — because a mapping that omits its negative space is marketing, and this section is for auditors.