TL;DR: Recent Trivy and LiteLLM incidents show the difference between what a workflow intended to run and what evidence it can prove, according to Testifysec, especially when signatures, attestations, and trusted producers are confused. The security problem is not absence of evidence but over-trusting evidence without policy-bound producer identity and scope control.
At a glance
What this is: This analysis separates workflow intent from execution evidence and shows why signed attestations still fail when producer trust, scope, or policy is assumed rather than verified.
Why it matters: It matters because CI/CD and agent pipelines increasingly rely on attestations to prove provenance, and identity teams need to govern which producers, keys, and evidence boundaries are trusted.
Context
Software supply-chain controls often fail when teams treat a signed statement, an attestation, and a workflow log as interchangeable proof. They are not the same thing. A workflow describes intended execution, while an attestation only proves something about the recorded subject within the capture and trust boundaries that were configured.
The article’s core governance issue is producer trust. That becomes an identity problem as soon as build systems, agents, or pipelines can sign evidence on behalf of a control owner. In that model, the question is not only whether the artifact was signed, but whether the signing identity, the evidence scope, and the policy binding were all under deliberate organisational control.
Key questions
Q: What breaks when signed attestations are treated as proof of trusted execution?
A: The main failure is assuming authenticity proves authority. A valid signature only shows that a producer created the statement, not that the producer was authorised to make that claim about that subject. If the workflow, agent, or signing key is compromised, the attestation can still verify while the underlying evidence becomes untrustworthy.
Q: Why do supply-chain incidents expose identity governance gaps in CI/CD?
A: Because CI/CD increasingly depends on machine identities to create, sign, and publish evidence. When those identities are over-scoped, reusable, or poorly separated from the work they certify, a compromise can turn trusted infrastructure into a release path for malicious content. Identity governance has to cover evidence authority, not just access rights.
Q: What signs show that an attestation model is too weak for release decisions?
A: Look for broad producer permissions, unclear subject binding, shared signing paths, and evidence that cannot be tied back to a specific workflow boundary. If a verifier accepts any fluent or signed record without checking who produced it, what it covers, and whether the producer was authorised, the model is too permissive.
Q: Should teams trust a signed build artifact without checking the producer and scope?
A: No. A signed artifact is only useful when the signing identity, the subject of the statement, and the policy around both are explicitly controlled. Teams should treat producer trust, capture scope, and release authority as separate decisions, because a signature alone does not prove safe provenance.
Technical breakdown
Workflow intent versus execution evidence
A workflow file is declarative intent, not proof of runtime behaviour. Attestations, logs, and traces each capture different parts of execution, and each can be bounded by permissions, selectors, and collection settings. That means a verifier can only trust what the chosen capture path actually observed. In supply-chain governance, the mistake is assuming a signed record is equivalent to complete evidence of what happened. It is only evidence of what the configured system chose to record.
Practical implication: Treat the attestation boundary as a control boundary and validate what the capture path can and cannot observe.
Producer identity and signature trust
A signature binds a statement to a producer identity, but that identity only matters if the organisation has decided to trust it for that claim. If an agent, workflow, or signing service can replace the test result, alter the subject, or misuse the trusted key, the signature still verifies while the claim becomes untrustworthy. This is an identity governance problem for machine actors, not just a cryptography problem. The control question is who is allowed to produce evidence for which subject.
Practical implication: Separate proof of authenticity from approval of authority, and scope each signing identity to a narrow evidentiary purpose.
Attestations, policy, and SLSA alignment
Build attestations can support supply-chain assurance, but they do not automatically satisfy higher assurance levels or framework expectations. A signed build is not automatically strong provenance, and the presence of evidence does not prove isolation, independence, or restricted authority. For agentic or CI-driven systems, policy has to evaluate the producer, the subject, and the pipeline conditions together. Otherwise, a fluent or signed result can look compliant while still carrying a compromised or over-permissioned execution path.
Practical implication: Map each evidence type to the exact assurance claim it supports before using it for release or compliance decisions.
Threat narrative
Attacker objective: The attacker aims to turn trusted supply-chain machinery into a delivery mechanism for malicious code and secret exposure.
- Entry occurs when a maintainer token or workflow control is compromised and used to alter the supply chain path.
- Credential access then enables poisoning of action tags or package releases so malicious content is distributed under trusted names.
- Impact follows when downstream CI systems consume the poisoned release and expose secrets or execute attacker-controlled code.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
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
Producer trust is the real control plane in supply-chain evidence. Attestations only work when the organisation has explicitly defined which producer identities may create evidence for which claims. If the trusted signer, workflow, or agent can be repurposed, the evidence remains syntactically valid but governance-invalid. The practitioner conclusion is to treat producer identity as a release gate, not a background implementation detail.
Machine identities now sit inside the assurance model, not beside it. Build systems, agents, and signing services are non-human identities that can assert claims on behalf of the platform. That means identity lifecycle, key scope, and evidentiary authority must be governed together, especially where CI/CD or agent workspaces can generate statements consumed by policy. The practitioner conclusion is to align NHI governance with release assurance.
Supply-chain guidance is moving from artifact trust to evidence trust. The Trivy and LiteLLM incidents show that the deciding factor is not whether a statement exists, but whether it was produced by the right identity under the right boundary. That shift changes how teams think about provenance, attestation, and verification in agentic workflows. The practitioner conclusion is to design controls around provenance authority, not just build output.
Signed evidence does not close the gap created by mutable workflow execution. A workflow can be edited, a test can be faked, and a trusted signer can be abused to legitimise the wrong thing. The governance assumption that “verified” means “safe” no longer survives contact with adversarial pipelines. The practitioner conclusion is to verify both the subject and the producer before release decisions are made.
From our research library:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Evidence trust is becoming a governance problem for machine identities. As more build systems, agents, and signing services issue statements on behalf of the organisation, the control question moves from “was it signed?” to “which non-human identity was allowed to sign this claim?” That is a lifecycle and authority issue, not a tooling issue.
Provenance controls now need the same discipline as access controls. If a workflow can edit the subject, publish the evidence, and activate the release path, then verification is only as strong as the weakest identity boundary in the chain. Teams should expect evidence-boundary reviews to sit beside credential reviews and release approvals.
Supply-chain exposure extends beyond the immediate build path. 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. That scale makes producer trust and offboarding discipline central to CI/CD governance rather than edge cases.
For practitioners
- Define trusted producer identities for evidence Restrict which build, agent, or signing identities are allowed to create attestations for release decisions, and bind each one to a specific evidentiary scope.
- Verify the attested subject, not just the signature Check that the recorded subject matches the artifact or change you intended to assess, then confirm the signer is authorised to speak for that subject.
- Separate policy signing from evidence production Do not let the same workflow path publish policy, generate evidence, and approve activation without independent controls over each role.
- Test representative envelopes before relying on them Validate the exact attestation formats, identity claims, and verifier behaviour you plan to use across the environments where decisions will be made.
- Recheck assurance claims against the actual build isolation Confirm that the build path, the signing authority, and the release boundary satisfy the assurance level you intend to claim, rather than assuming a signature implies that level.
Key takeaways
- Signed attestations are only useful when the producer identity, subject binding, and policy scope are all tightly governed.
- The Trivy and LiteLLM incidents show that compromised workflow paths can turn trusted evidence into a delivery channel for malicious content.
- Identity teams should treat machine signers, build services, and agent workspaces as governed producers, not passive infrastructure.
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 NIST CSF 2.0, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Compromised workflow and signing secrets are central to the article's evidence-trust problem. |
| NHI-05 — Overprivileged NHI | The article hinges on machine identities that can overreach their evidentiary authority. | |
| NHI-10 — Human Use of NHI | The article highlights humans relying on machine-produced evidence as if it were direct proof. | |
| Recommendation — Scan attestation and signing paths for leaked credentials and revoke exposed machine secrets immediately. Scope signing and evidence-producing identities to the narrowest possible release authority. Prevent human approval from substituting for validation of the underlying machine-produced claim. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The incidents involve stolen tokens and downstream movement through trusted supply-chain channels. |
| Recommendation — Map token theft and downstream abuse to TA0006 and TA0008 to prioritise detection and containment. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Evidence producers need tightly governed permissions and entitlements in CI/CD trust chains. |
| Recommendation — Apply PR.AA-05 to enforce narrow permissions for signing and attestation-producing identities. | ||
| CIS Controls v8 | CIS-5 — Account Management | Machine signing accounts and workflow identities require disciplined lifecycle and offboarding control. |
| Recommendation — Use CIS-5 to inventory, restrict, and retire build and signing accounts that no longer need authority. | ||
| SLSA | L3 — Build provenance and tamper resistance | The article explicitly questions whether signed builds meet the claimed assurance level. |
| Recommendation — Check that provenance evidence really satisfies the SLSA level you intend to claim. | ||
Key terms
- Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
- Producer identity: Producer identity is the machine or human identity that creates a statement, signature, or evidence record. In supply-chain governance, it matters because the same signed output can be trusted or rejected depending on whether the producer was authorised to assert that specific claim.
- Evidence Boundary: The line between what the system has actually proven and what it only infers or narrates. A thin evidence boundary means the model can sound decisive without having enough proof, which creates governance and audit problems even when the output appears polished.
- Supply chain provenance: The ability to trace where code, packages, and build artefacts came from and how they were produced. It is essential for software trust because it turns opaque assembly into an auditable chain of custody that security, compliance, and operations teams can verify.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to release assurance across modern delivery pipelines.
Published by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org