The security model on one page
This page is written to be sent as-is to a CISO or a security auditor. Every claim carries its requirement number (SRS) and its delivery status. Nothing on this page is aspirational unless explicitly marked as upcoming.
The five commitments
Section titled “The five commitments”1 — Tobby signs nothing. Tobby transports content; it never creates authenticity. It holds no signing key, in any mode, ever. Signatures are produced upstream by the organization’s qualification pipeline and only verified by Tobby (FR-033, ADR-0007 — delivered v0.3.0). The verifier is deliberately verify-only code.
2 — The destination’s trust roots are the only authority. Verification always runs against the public keys configured on the receiving instance. Trust roots found on transport media are ignored by requirement (FR-054): compromising a media never compromises the destination’s trust anchor. Delivered for the verification engine (v0.3.0) and for the media path (v0.5.0), where a trust-root file planted on a medium is ignored — a test plants one to prove it.
3 — The media manifest is integrity, not trust. The inventory written on removable media (paths, sizes, digests, zone identity) detects corruption and incompleteness. It is deliberately unsigned — see commitment 1 — and is never what makes content trustworthy: only recipe signatures verified against the destination’s trust roots do that (FR-054, ADR-0006, ADR-0016 — delivered v0.5.0). Each covered file is checked against its own content address as well as against the inventory, which is what keeps the unsigned inventory from being load-bearing. See media security.
4 — Secure by default. Authentication is on by default in both modes (FR-075 — delivered v0.4.0). Every security-reducing setting is an explicit opt-in, visible in the configuration report, logged, audit-logged, and — where it changes what a user faces — announced by a permanent UI banner. No default or omitted setting weakens the instance.
5 — No undeclared outbound connection. Tobby makes no network connection the operator did not configure: no telemetry, no crash reporting, no update check (NFR-019 — delivered v0.1.x). This is proven, not promised: every acceptance run starts with an egress canary that must fail from the isolated zone, and e2e runs behind an egress-capturing proxy record connections to configured endpoints only. See tests and proofs.
Security feature status
Section titled “Security feature status”The table below is rendered from the same data file as the project status page — a single source of truth, never a second hand-maintained table.
Status as of v0.5.0 (2026-08-28)
| Feature | Status | Milestone |
|---|---|---|
| 1.1 Secure build chain (reproducible, SLSA L3, signed SBOM) | Available | — |
| R-09 End-to-end run identifier | Available | — |
| R-12 Security audit logFoundation, authentication, token and media-override events shipped; scan events at milestone 6. | Partial | J6 |
| R-01 Secure guided first start (no open UI, tool-computed hashes) | Available | — |
| 3.4 Cosign signature verification at entry (trust roots, scopes, both layouts) | Available | — |
| 4.2 Registry allowlist, refused before any transfer | Available | — |
| 4.3 Authentication and RBAC, secure by default (basic, tokens, three roles) | Available | — |
| 4.4 Enterprise network: authenticated proxies, private PKI, server TLS | Available | — |
| R-02 Media screen: guided operator journey with per-step verdicts | Available | — |
| R-28 Media identity and freshness (stale media refused by default) | Available | — |
| R-16 Secrets never travel on the transportable store | Available | — |
| 5.3 Zone identity guard and media inventory | Available | — |
| R-19 Fine-grained blocking on a tampered medium (per-recipe verdicts) | Available | — |
| 5.4 Destination-side operation (full re-verification, then differential push) | Available | — |
| 6.1 Vulnerability scanning with policy (Trivy, blocking or advisory) | Upcoming | J6 |
| R-13 Guaranteed freshness of the vulnerability database | Upcoming | J6 |
| R-14 Authentication hardening (rate limiting, session and token expiry)Failed-authentication rate limiting shipped in v0.4.2; session and token expiry land with milestone 6. | Partial | J6 |
| 6.2 Offline vulnerability database, carried by Tobby itself | Upcoming | J6 |
| R-25 Tobby updates through its own channel, across the air gap | Upcoming | J6 |
| R-22 Reduced-trust content stays visibly marked everywhere | Upcoming | J6 |
| R-20 Continuity when the enterprise directory is down | Upcoming | J6 |
| 6.3 Enterprise identity: OIDC, then SAML 2.0 | Upcoming | J6 |
| R-31 On-demand store integrity verification with timestamped report | Upcoming | J6 |
| R-30 One-step redacted diagnostic bundle | Upcoming | J7 |
| R-32 Clock-sanity detection in isolated zones | Upcoming | J7 |
| R-15 Scoped, expiring vulnerability exceptions (VEX-convergent) | Upcoming | J7 |
| 7.3 Hardening proven by tests (fuzzing, CSRF, OCI conformance suite) | Upcoming | J7 |
| R-21 Documented emergency path (scoped, visible, organization-signed)Documentation-only feature; no code path. | Upcoming | J7 |
| R-17 Per-content provenance and trust class, visible everywhere | Upcoming | J7 |
Threats covered and not covered
Section titled “Threats covered and not covered”Covered today, with the detail pages that substantiate each line:
- Unsigned or tampered content — blocked at import and before push (FR-033): content trust.
- Content pulled from or pushed to an unapproved registry — refused before any transfer (FR-030): content trust.
- Unauthenticated or under-privileged access to any surface (FR-074, FR-075): authentication and RBAC.
- Secrets leaking through logs, errors, or configuration dumps (NFR-015): secrets.
- Hidden network behavior (NFR-019): threat model.
- Untraceable security actions (FR-094): audit log.
- Tampered, stale or misaddressed removable media — re-verified before any push, any serving and any local write (FR-054, R-19, R-28): media security.
- Secrets travelling on a medium — the instance refuses to start when a configured secret path resolves under the store root (NFR-020, R-16): secrets.
Covered at milestone 6: known CVEs in transported content (FR-031), authentication brute-force hardening beyond the per-origin throttling shipped in v0.4.2 (R-14).
Not covered by design, stated plainly: Tobby does not qualify upstream content, does not purge destination registries, and its audit log is operational evidence rather than a signed trust anchor (limits, threat model).
Vulnerability scanning
Section titled “Vulnerability scanning”Policy-driven Trivy scanning — severity thresholds, blocking or advisory, with an offline vulnerability database transported by Tobby itself — arrives at milestone 6 (FR-031, FR-032, ADR-0008). Until it ships there is deliberately no scanning page in this documentation; track the line on the project status page.
Verify these claims
Section titled “Verify these claims”The build chain behind the binary you run — SLSA Build L3 provenance, bit-for-bit reproducible builds, signed SBOMs (NFR-004, NFR-005, NFR-006, ADR-0011) — is independently checkable: verify a release.