SLSA Build Provenance — Self-Attestation

SLSA (Supply-chain Levels for Software Artifacts) is an industry framework for build integrity — it grades how tamper-resistant a software artifact's build and provenance are, not just whether the final file is signed. This page is OWL's honest self-assessment against SLSA: what we do today, and what we still need to do to claim a higher build level.

Part of NDEVR's compliance & conformity program · See also secure development.

Self-attested; level is aspirational. Signed releases are necessary but not sufficient for a high SLSA level — the levels are mostly about automatically generated, tamper-resistant provenance from an isolated build. Our release provenance is not yet automatically generated, so we describe the gap plainly rather than claim a level we have not earned.

Contents

  1. What we do today
  2. Mapping to SLSA requirements
  3. Target & roadmap
  4. Scope & honesty

1. What we do today

OWL's release and update path already implements several supply-chain integrity controls:

  • Signed updates. The update-check response is signed with Ed25519 (the public key is pinned in the client; the private key is held operator-side). The signed manifest binds the SHA-256 of the installer, so the client refuses a tampered download before writing it to disk. (Caveat: the update-check signature fails open if absent, but the download-hash check fails closed — see secure development.)
  • Integrity-verified artifacts. Clients verify the SHA-256 of a downloaded release against the signed manifest, so a substituted or corrupted artifact is rejected.
  • A CycloneDX SBOM. We produce and track a Software Bill of Materials, which underpins dependency and vulnerability response (available on request).
  • A scripted build. Releases are produced by a checked-in, repeatable build script (e.g. the Linux File-Server AppImage is built in a pinned debian:13 container), rather than ad-hoc on a developer's machine without record.

2. Mapping to SLSA requirements

SLSA's Build track ranges from L0 (no guarantees) to L3 (hardened, isolated build producing non-forgeable provenance). Here is where OWL stands:

SLSA build requirementOWL status
Scripted / repeatable buildMet — releases are built from a checked-in script in a pinned container image.
Release artifacts signed & integrity-verified by consumersMet — Ed25519-signed manifest binding a SHA-256 hash; clients reject tampered downloads.
Software Bill of MaterialsMet — CycloneDX SBOM tracked and available on request.
Provenance generated for each release (a signed statement of how/where/from-what the artifact was built)In progress — not yet automatically generated. This is the main gap between "signed artifact" and SLSA Build L1.
Provenance generated by a hosted/isolated build service (developer cannot forge it)Not yet — builds are developer-initiated rather than produced by an isolated, hosted build platform.
Hardened, non-forgeable provenance (Build L3)Not yet — depends on the two items above.

3. Target & roadmap

We are working toward SLSA Build Level 1 first: generating signed build provenance (in-toto / SLSA format) for each release as part of the build script, and publishing it alongside the artifact and its SBOM. Reaching Build Level 2+ would mean moving release builds onto a hosted, isolated build service that produces the provenance so it cannot be forged by a developer. We will update the table above as each item lands.

4. Scope & honesty

This is a point-in-time self-attestation, not a third-party SLSA assessment. "Signed releases" alone is not a high SLSA level, and we do not claim one. If you rely on build provenance to evaluate OWL, contact security@ndevr.org — and our vulnerability disclosure program is the place to report any supply-chain concern.