TL;DR: A Jenkins build can produce a signed attestation collection recording the command, exit code, file digests and every program started, according to Testifysec research, then be blocked at release time if the jar changes or tracing is missing. The operational shift is that provenance becomes enforceable evidence, not just build metadata, when policy verifies the trace before release.
At a glance
What this is: This is a Jenkins pipeline provenance case study showing how cilock records build execution and blocks release when the artifact or trace fails verification.
Why it matters: It matters because identity and access decisions increasingly depend on trusted build provenance, especially when pipeline steps can start helper programs, write artifacts and release software into production.
Context
Build provenance is the ability to prove how an artifact was produced, which commands ran, and whether the recorded output matches what was released. In CI/CD, that matters because a successful job is not the same thing as a trusted build, especially when pipelines invoke helper tools and multiple identities can touch the same workspace.
SLSA and build provenance is the closest governance lens here because the article is not about application logic, but about evidence, attestation and release-time verification. The underlying problem is common across mature pipelines: teams inherit scripts they do not want to change, yet still need proof that the build path is intact.
Key questions
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. The key decision is not whether a build finished, but whether the release path can prove the commands, helper processes and artifact digests that led to the jar. Without that, provenance remains a narrative instead of a control.
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. If the trace is missing, policy cannot confirm which commands ran or whether the expected build path was observed, so a release gate should fail closed. That prevents teams from trusting an artifact whose build history is incomplete.
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. If the security team cannot point to the exact policy that blocks an untraced or mismatched artifact, then provenance is advisory rather than enforceable. Mature controls make the release outcome depend on evidence, not operator memory.
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.
Technical breakdown
How attestation collections record build execution
The article describes an execution trace that is turned into a signed attestation collection after the build finishes. The attestation records the command, the exit code, the files read and written, and every program started during the run, including helper processes launched by git. That gives release tooling an evidence object, not just a build log. The signed Merkle tree for the jar digest matters because it makes the artifact content tamper-evident, while the trace records the build path that produced it. See the SLSA and Build Provenance Guide.
Practical implication: Use attestation data to prove both artifact integrity and build-path integrity before release.
Why verification must happen at release time
A trace by itself does not secure the pipeline. The release step must verify the jar against the attestation collection and the signed policy before promotion, otherwise the trace is only forensic evidence. In the article, the policy checks three things: exit code 0, expected programs such as git, javac and jar, and proof that the build was traced. That pattern separates observed execution from approved execution, which is the core control boundary in provenance-based release gating.
Practical implication: Place verification in the promotion path so unsigned or incomplete builds cannot move forward.
Why untraced builds still matter to provenance controls
The article shows that an untraced build can still produce a signed attestation collection, but with a different evidentiary value. That is important because the control is not only about blocking obvious tampering, it is about proving what happened when policy needs that answer. Without --trace, the system cannot prove which programs actually ran, so the attestation is less useful for policy that depends on command-level visibility. This is a practical distinction between artifact integrity and execution transparency.
Practical implication: Decide which pipeline steps require trace-level evidence and enforce that requirement explicitly.
Threat narrative
Attacker objective: The objective is to slip an unverified or modified build artifact through a pipeline that lacks enforceable provenance checks.
- Entry occurs through the normal Jenkins pipeline command path, where python3 build.py invokes git, javac and jar without changing the script itself.
- Credential or artefact trust is not the issue here, but the attack surface is the build path, where an untraced or altered run can undermine release confidence even when the job succeeds.
- Impact occurs at release time if the jar is promoted without a matching attestation collection, because the team can no longer prove how the artifact was built.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Untraced CI work creates a verification gap that policy cannot safely ignore. The article’s most important finding is that a build can still finish and still produce an attestation, yet leave no trustworthy record of which programs executed when tracing is absent. That is a governance gap, not a tooling quirk, because release policy that depends on command provenance cannot prove its own conditions. CI/CD security becomes relevant here because pipeline governance has to distinguish execution visibility from artifact integrity.
Named concept: provenance sufficiency gap. This is the point at which a team believes it has enough build evidence, but the policy cannot actually confirm the commands, helper processes or workspace actions that matter. The gap appears when artifact digests exist but execution context is incomplete, and that is exactly where release assurance breaks down. Practitioners should define which pipeline stages need trace-level evidence before they trust the release path.
This pattern reinforces why build identity and pipeline identity need to be governed together. The article shows that a Jenkins job, its helper programs and its release verifier each play a different trust role, even when the build script itself is untouched. That means the security model has to account for who or what is allowed to produce, sign and verify build evidence. Practitioners should align provenance checks with pipeline identity boundaries, not just with source control events.
Read next: SLSA and Build Provenance Guide
What this signals
Provenance controls will increasingly be judged by what they can prove at release, not by what they record during the build. That changes procurement and architecture discussions for CI/CD because teams need evidence that survives handoffs between developers, shared libraries and release gates. The practical question is whether the policy can reject a build when the recorded execution path is incomplete, not whether the build log looks healthy.
Build identity and pipeline identity are converging governance concerns. When a controller can wrap every shell step, the control plane becomes part of the trust model, not just the place where jobs run. Practitioners should prepare for tighter separation between who authors the pipeline, who signs the evidence and who is allowed to verify it before promotion.
For practitioners
- 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.
- Standardise how pipeline teams apply cilock Use one shared execution pattern for Jenkinsfiles so release policy can be changed centrally instead of copied into every pipeline definition.
Key takeaways
- The core risk is not simply a bad jar, but a release process that cannot prove how the jar was built.
- The article shows that attestation collections can block both modified artifacts and builds that lack required trace evidence.
- Teams need release-time verification, because provenance only becomes a control when policy can reject an incomplete build path.
Related NHI Mgmt Group resources: CI/CD Security Guide · SLSA and Build Provenance Guide · CI/CD Pipeline Identity Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while SLSA, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI pipelines and build steps can expose sensitive evidence and credentials if execution is not governed. |
| Recommendation — Scan pipeline execution paths for exposed secrets and restrict build-step access to only what each job needs. | ||
| SLSA | L3 — Build provenance | The article is centered on signed build evidence and release-time verification of artifact provenance. |
| Recommendation — Adopt provenance checks that bind artifacts to the exact build steps that produced them. | ||
| MITRE ATT&CK | TA0002;TA0007 — Execution; Discovery | The build trace records execution details and exposes what ran inside the pipeline environment. |
| Recommendation — Map suspicious pipeline execution to TA0002 and hunt for unexpected build-time discovery activity. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The control focus is secure build and release handling for software artifacts. |
| Recommendation — Apply application software security controls to require attestation before deployment. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity | Signed digests and verification checks are about preserving the integrity of the release artifact. |
| Recommendation — Enforce integrity checks so only artifacts with matching attestation evidence can be promoted. | ||
Key terms
- Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.
- Attestation Collection: An attestation collection is a signed bundle of evidence about a build or release, such as executed commands, file digests and exit status. It is used to prove what happened during a pipeline run and to support policy checks before an artifact is trusted.
- Release-Time Verification: Release-time verification is the control point where a build artifact is checked against signed evidence before it is promoted. It matters because integrity claims are only enforceable when policy can reject an artifact whose provenance, trace or digest does not match expectations.
- Trace Evidence: Trace evidence is the complete record of what an agent did, under which authority, with which inputs, and with what outcome. It is more than observability because it must support governance decisions, not just troubleshooting, and it has to remain tied to the exact version that ran.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and machine identity security alongside the control models that support secure release paths. It helps practitioners connect identity governance to the build and release decisions their programmes rely on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org