Signed does not mean safe, provenance does not mean reviewed, and a Build level is not a security score. Here are eight common myths about signing, provenance and attestations, each set against what the SLSA, in-toto and Sigstore documents actually say.
Myth versus fact
| Myth | Fact |
|---|---|
| A valid signature means the software is safe | A signature shows who signed and that bytes are unchanged. It says nothing about intent |
| Provenance proves the code was reviewed | Provenance describes the build. Source level threats belong to the Source track |
| Provenance shows the package was published to my registry | SLSA says provenance claims an artifact was built, not published to a particular registry |
| SLSA L3 means no vulnerabilities | Build levels cover build integrity. SLSA says dependency threats are not explicitly addressed in this version |
| Verifying the signature is enough | You must also check identity, expectations and the digest |
| Short lived certificates mean old signatures fail | Log entries and timestamps prove signing during validity |
| A VSA means I can stop checking | A VSA does not protect against a compromised verifier |
| Attestations are only for big vendors | SLSA Build L2 is defined around a hosted platform generating and signing provenance, which a small team can use too |
A closer look at four of them
Signed is not safe. A producer could sign malicious code on purpose. SLSA states this kind of attack cannot be directly mitigated through its controls, so consumers lean on review, reputation and incentives.
Check the identity. For keyless signing, the verify command needs the expected certificate identity and issuer. For commits, the gitsign README warns that the plain git verify commands do not verify cert claims. A signature from the wrong identity is valid cryptography and a failed trust check.
Levels are about the build. Build L2 means a hosted platform generates and signs provenance. Build L3 adds isolation and protected signing keys. Neither says anything about whether the dependencies are clean.
Old signatures survive. The bundle spec requires a log timestamp or RFC 3161 timestamp whenever short lived certificates may be verified after expiry, which is how old signatures stay checkable.
A short checklist that avoids all eight
- Verify the signature against roots you chose.
- Check the signer identity and issuer.
- Match the subject digest to your artifact.
- Compare provenance to expectations: builder, repository, build type, parameters.
- Scan the content separately for vulnerabilities.
- Keep the bundle and verification record.
Where Safeguard fits
Safeguard covers the content side of that checklist with SBOM and dependency scanning, reachability analysis and policy gates. Start with the free scan.
Quick check
What is the single biggest misunderstanding?
That a signature or level equals safety. Both describe process and identity, not whether the contents are vulnerable or malicious.
Should small projects bother with provenance?
If a hosted platform can generate it cheaply, yes. It gives consumers something concrete to check.
Sources
- SLSA v1.2 Threats
- SLSA v1.1 Levels
- SLSA v1.1 Verification Summary
- Sigstore bundle format
- gitsign README
Last reviewed: 19 October 2026.
