slsa-verifier, The Binary Verifies Its Own Provenance
slsa-verifier on EL 10 from the GitHub release, pinned by a SHA-256 the role carries (the vendor publishes no checksum file), re-checked by the live test, which then fetches the release's .intoto.jsonl and has the installed binary verify itself against it through Sigstore ('PASSED'); the wrong source tag is refused. Pinned. Original role, live-tested on Rocky Linux 10.
Verification
Live-testedReally deployed to a container sandbox, proven idempotent (a second run changes nothing), verified against the role’s assertions, then torn down.
Conformance
- Static validation (yamllint · ansible-lint)
Provenance
- SHA-256 checksum
- Signature (pending)
Functional
- Live-tested - applied, verified, destroyed
Last verified 2026-09-21 · podman 4.9.3 · ansible 2.21.4 · how we verify
Documentation
slsa-verifier
The SLSA CLI (slsa-verifier) on EL 10 from the vendor's GitHub release,
checked against a SHA-256 pinned beside the version, installed as root's
binary in /usr/local/bin. Original role for EL 10, live-tested with
podman on Rocky Linux 10.
No package, and no checksum file to speak of. EL 10 carries no
slsa-verifier. the project publishes SLSA provenance (an .intoto.jsonl per asset) instead of a checksum file; the live test verifies the installed binary against that provenance. This role pins the SHA-256 per architecture
beside the version, has Ansible's get_url refuse the asset unless it
matches, and the live test checksums the asset on disk again. A new
release is a new pair, on purpose.
Proven to do its work. The live test runs slsa-verifier verify-artifact /usr/local/bin/slsa-verifier --provenance-path /tmp/slsa-verifier-p/provenance.intoto.jsonl --source-uri github.com/slsa-framework/slsa-verifier --source-tag v2.7.1 and
expects "PASSED: SLSA verification passed" - the binary did the provenance-verification work it is
installed for, on an input the test wrote.
The binary verifies its own provenance. The live test fetches the
.intoto.jsonl the project published for this release and runs
slsa-verifier verify-artifact on the installed binary: the provenance
is checked against Sigstore (Rekor and the Fulcio roots, over the
network), the builder identity and the source tag are matched, and the
artifact hash must equal the provenance subject - "PASSED". The same
command with the wrong source tag is expected to fail. This is a
stronger check than the SHA-256 the role pins: it ties the bytes to the
build that produced them.
License
Commercial - IaC Bazaar EULA. (c) IaC Bazaar.
Usage code & full reference need an account
The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.
- Variables
- Test
Related modules
ansible-authelia
Authelia from the upstream release (sha256-verified) as a hardened system service on loopback with file users and sqlite; its secrets are generated once on the host and reach the service as AUTHELIA_*_FILE variables. The live test hashes a password with Authelia's hasher, logs in, sees a wrong password refused and an anonymous visitor sent to the portal. Original role, live-tested on Rocky 10.
ansible-bandit
bandit on EL 10 from PyPI into a venv of its own with a link in the PATH; the live test runs pip check, then scans a module that passes a string to subprocess.call with shell=True (B602, High, exit 1) and a clean module (exit 0). Pinned. Original role, live-tested on Rocky Linux 10.
ansible-base-hardening
SSH hardening drop-in, sysctl security profile, login banner, and time sync. Original, live-tested (Molecule) role.
ansible-boundary
boundary on EL 10 from releases.hashicorp.com; SHA256SUMS is signature-checked against HashiCorp's key before get_url trusts it, the live test re-checks both, then runs authenticate against a dead address ('connection refused') and database init with a throwaway config (parsed, root key loaded, then the database refused). Pinned. Original role, live-tested on Rocky Linux 10.
ansible-dockle
dockle on EL 10 from the GitHub release; get_url refuses it unless its SHA-256 is in the vendor's checksums file, and the live test re-checks it, then scans a one-layer image whose config names no user, expecting CIS-DI-0001 in the output, exit code 1 with --exit-level warn, and the warning counted in the JSON form. Pinned. Original role, live-tested on Rocky Linux 10.
ansible-gitleaks
gitleaks on EL 10 from the GitHub release, refused by Ansible's get_url unless its SHA-256 is the one in the project's checksums file, and re-checked with sha256sum -c by the live test, which then plants a file holding an AWS access key that is not one and runs gitleaks detect over it, expecting 'leaks found: 1'. Original role, live-tested on Rocky Linux 10.