Topic starter
25/10/2026 11:01 am
TL;DR: A Jenkins build can now leave a signed attestation collection that records the command, exit code, file digests and every program started, according to Testifysec. Release gates can then fail closed when the jar changes or trace evidence is missing.
Editorial analysis by NHI Mgmt Group, based on content published by Testifysec: “Prove How a Jenkins Build Ran Without Changing the Build Script”.
Key questions
Q: What happens when a CI pipeline has artifact hashes but no trace evidence?
A: A hash alone proves content integrity, not how the artifact was produced.
Q: What are the signs that build provenance controls are too weak?
A: The warning signs are copied pipeline flags, inconsistent release checks and builds that pass without command-level evidence.
Q: How should teams govern build provenance in Jenkins pipelines?
A: Teams should require attested builds, verify them before release and define which stages must produce trace evidence.
Practitioner guidance
- Implement release-time attestation verification Block artifact promotion unless the jar matches a signed attestation collection and the policy checks pass for exit status, expected commands and trace presence.
- Trace the build stages that matter most Start with high-risk Jenkins steps and capture the programs they launch, the files they touch and the environment they run in before expanding coverage.
- Separate artifact integrity from execution evidence Treat digest checks as necessary but not sufficient, because a valid hash does not prove which helper programs executed during the build.
Bottom line: The core risk is not simply a bad jar, but a release process that cannot prove how the jar was built.
Glossary terms: Build provenance, Attestation Collection, Release-Time Verification, Trace Evidence
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:18 pm
Build provenance is now a release-control problem, not a logging problem. The article shows that the useful question is not whether a pipeline ran, but whether the release step can prove exactly what ran and what artifact was produced. That shifts provenance into the same governance class as access control and signing, where evidence must be machine-verifiable before trust is granted. Practitioners should treat attestation as a policy gate, not a post-build report.
A question worth separating out:
Q: Should teams verify build provenance at the source step or at release time?
A: Release-time verification is the decisive control because it is the moment an artifact becomes trusted for deployment. Source-step checks are still useful for visibility, but they do not stop a modified jar from moving forward unless promotion is tied to attestation policy. The safest model is to verify at both points, with release as the enforcement boundary.
👉 Read our full editorial: Attested Jenkins builds make pipeline provenance verifiable
This post was modified 7 days ago by NHI Mgmt Group