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
Section titled “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)
Section titled “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
Section titled “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)
Section titled “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
Section titled “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.