TL;DR: Software supply chain failures now sit alongside broken access control and cryptographic failures in the 2025 OWASP Top 10, and Codenotary says continuous artifact trust scoring is meant to expose hidden dependency and build-system risk before it cascades across development pipelines. The governance problem is not just provenance, but sustained trust and re-evaluation across the artifact lifecycle.
At a glance
What this is: Codenotary argues that continuous trust scoring for software artifacts is needed because supply chain failures can cascade through dependencies, build systems, and CI/CD pipelines.
Why it matters: IAM, NHI, and platform security teams should treat software artifacts, build credentials, and pipeline trust as governed identities and not as static assets.
Context
Software supply chain security fails when teams trust artifacts, dependencies, and build outputs without continuous validation. The gap is not just provenance at creation time, but whether every component remains trustworthy as it moves through CI/CD, release, and deployment workflows. For identity and access teams, that also means the credentials and approvals used inside pipelines need the same governance discipline as any other privileged access path.
The practical challenge is scale. Modern software estates contain deep dependency chains, multiple build systems, and third-party signals that are rarely assessed together. Without an operating model for continuous trust, teams inherit unknown risk from code, containers, packages, and signing workflows rather than managing it explicitly.
Key questions
Q: How should teams govern supply chain risk in CI/CD environments?
A: Use separate identities for build, sign, and deploy, and make credential scope as narrow as the task allows. Governance should cover what can execute, what can authenticate, and what can be reused after execution. If a workflow can both run untrusted code and reach production, the control boundary is too loose.
A: Weak governance increases risk because software supply chain decisions depend on consistent evidence, risk tolerance, and escalation. Without baseline risk factors and documented scoring, teams cannot compare suppliers or dependencies reliably, prove due diligence, or route substantial risks to the right senior officials. That creates gaps in accountability, delays remediation, and makes risk acceptance harder to justify.
Q: What signs show that artifact trust controls are not working?
A: Warning signs include stale approvals, no re-evaluation when vulnerabilities change, weak visibility into dependency lineage, and build or release paths that cannot explain why an artifact is trusted. If teams cannot rapidly identify which outputs are affected by a new upstream issue, the trust control is too static to be useful.
Q: What should teams do when a previously trusted artifact becomes high risk?
A: They should be able to isolate the artifact, stop further promotion, identify all affected downstream systems, and re-score related builds or packages immediately. The governance objective is containment and decision speed. If the organisation cannot revoke trust quickly, the original compromise will continue to spread through legitimate software processes.
Technical breakdown
Why artifact trust has to be continuous, not one-time
A software artifact can be trusted at build time and unsafe later if a dependency is replaced, a signing key is abused, or an upstream vulnerability changes its risk profile. Continuous trust scoring treats provenance, integrity, and external threat signals as living inputs rather than a one-off attestation. That matters because build outputs, container images, and libraries often travel farther than the teams that produced them, which makes stale trust the real failure mode. In practice, this is a control problem as much as a tooling problem: the organisation must be able to re-assess trust after the artifact leaves the pipeline. See the Software Supply Chain Security Guide. See the Software Supply Chain Security Guide.
Practical implication: Track artifact trust as an ongoing control, not a release gate that is checked once.
How internal build data and external threat signals combine
Trust scoring becomes more useful when internal evidence and external intelligence are evaluated together. Internal signals include build metadata, attestations, and lineage, while external signals include vulnerability severity, open source project risk, and newly identified malicious patterns. The article points to a central lesson in supply chain governance: no single source of truth sees enough of the attack surface on its own. This is where security teams need correlation rather than raw inventory. Once the model can re-score artifacts retroactively, the organisation can identify which outputs were safe before and are now high risk because the upstream context changed. See the Open Source Security Guide. See the Open Source Security Guide.
Practical implication: Correlate provenance data with threat intelligence so newly disclosed risk can re-score affected artifacts.
Why CI/CD governance now includes trust and identity control
Software supply chain attacks often move through CI/CD because pipeline identities can publish, sign, or promote artifacts at scale. That makes the pipeline itself part of the trust perimeter, not just the code repository. A trust model that ignores build credentials, publishing tokens, and signing workflows misses the mechanism attackers exploit most often: legitimate automation used at high speed and high volume. For IAM and NHI practitioners, the intersection is direct. CI/CD service accounts, tokens, and signing identities need scope, lifecycle, and revocation controls that match their production blast radius. See the CI/CD Pipeline Identity Security Guide. See the CI/CD Pipeline Identity Security Guide.
Practical implication: Govern pipeline identities, publishing tokens, and signing permissions as privileged access paths.
Threat narrative
Attacker objective: The attacker wants to turn trusted software distribution into a propagation channel for malicious code, stolen secrets, or downstream compromise.
- Entry occurs through a compromised dependency, build component, or pipeline trust path that is already embedded in the software supply chain.
- Credential or artifact trust is then abused when the malicious component is accepted as legitimate by build and release workflows.
- Impact follows when the tainted artifact propagates into downstream services, where the compromise can spread across multiple teams and environments.
Breaches seen in the wild
- 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.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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
Continuous trust scoring is becoming the missing control plane for software supply chain governance. Provenance alone tells teams where an artifact came from, but not whether its risk changed after creation. The article is right to frame trust as something that must be re-evaluated across the lifecycle, especially when dependencies and build systems move faster than manual review. Practitioners should treat trust scoring as an operational governance layer, not a reporting metric.
Software supply chain risk is now an identity problem as much as a code problem. Build systems, publishing workflows, and signing processes rely on service accounts, tokens, and delegated permissions that can be abused at machine speed. That is where CI/CD pipeline identity security becomes central, because the real control gap is often not the artifact itself but the privileged identity that can produce or promote it. Practitioners should govern pipeline identities with the same rigor as production administrators.
Unknown unknowns are the defining failure mode in modern artifact governance. The article highlights deep dependencies and delayed detection as the reason insecure artefacts escape notice for months or years. That failure mode is best understood as trust drift: an artifact starts acceptable and becomes risky as upstream context changes. Practitioners should assume static approval states are obsolete unless they are continuously revalidated.
Open source risk signals need to be operationalised, not merely observed. Internal metadata and external scores only matter if they change enforcement decisions when a package, container, or build output becomes suspect. This is where supply chain governance moves from inventory management to risk prioritisation. Practitioners should wire external trust intelligence into policy decisions that can actually block, quarantine, or re-score artifacts.
Continuous validation should reshape how regulated organisations think about software assurance. Financial services and critical infrastructure teams cannot rely on periodic audits when build ecosystems change daily. The practical standard is whether an organisation can explain, at any point, why a given artifact is trusted and whether that answer changes when upstream risk changes. Practitioners should make that question answerable before the next release cycle completes.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: Software Supply Chain Security Guide
What this signals
Trust drift is now a core software assurance concept. The relevant question is not whether an artifact was once validated, but whether its risk state still matches current upstream conditions. As CI/CD pipelines accelerate, teams need controls that can re-score and re-approve artifacts when dependency or vulnerability context changes, not just when a release is cut.
92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. That figure matters here because software supply chains are increasingly driven by delegated service identities, publishing tokens, and automated approvals. Practitioners should assume that artifact trust and NHI governance are converging control problems, especially where pipeline credentials can be reused across tools and environments.
For practitioners
- Implement continuous artifact re-scoring Re-evaluate trust for build outputs, containers, and packages whenever upstream vulnerability or lineage signals change, rather than only at release time.
- Inventory pipeline identities and publishing paths Map service accounts, tokens, signing identities, and release permissions that can create or promote artifacts across CI/CD.
- Blend internal lineage with external risk feeds Correlate attestations, build metadata, open source risk scores, and vulnerability feeds so affected artifacts can be flagged quickly.
- Set quarantine rules for high-risk artifacts Define when a trust score drop should block deployment, trigger review, or remove an artifact from promotion workflows.
Key takeaways
- The article frames software supply chain failures as a lifecycle governance problem, not just a provenance problem.
- Trust scoring matters because artifact risk can change after creation when upstream signals, dependencies, or vulnerability data change.
- Pipeline identities and release permissions are part of the attack surface and need governance alongside the artifacts they create.
Related NHI Mgmt Group resources: CI/CD Pipeline Identity Security Guide · Open Source Security Guide · Software Supply Chain Security Guide · reviewdog Action compromise 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Supply chain abuse often turns trusted build identities and artifacts into paths for credential theft and propagation. |
| Recommendation — Map compromised pipeline behavior to TA0006 and TA0008, then hunt for stolen tokens and downstream propagation. | ||
| CIS Controls v8 | CIS-5 — Account Management | Pipeline service accounts and publishing identities need lifecycle control to prevent trusted abuse. |
| Recommendation — Apply CIS-5 to inventory, review, and revoke pipeline accounts and release permissions that exceed their purpose. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article hinges on governing who can build, sign, and promote artifacts across CI/CD. |
| Recommendation — Use PR.AA-05 to limit artifact-publishing and signing entitlements to the minimum required scope. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party build components and delegated pipeline identities are central to the attack surface described. |
| NHI-07 — Long-Lived Secrets | CI/CD tokens and publishing secrets can remain valid long after their initial trust context has changed. | |
| Recommendation — Treat third-party build identities and dependencies as NHI assets that need inventory, review, and revocation paths. Reduce the lifetime of pipeline secrets and rotate them before trust context or ownership changes. | ||
Key terms
- Artifact Trust: Artifact trust is the decision to accept a component based on who published it, which version is running, and whether it has changed. It covers models, packages, servers, and other build artifacts. The control is necessary, but it does not by itself limit what the component can do at runtime.
- Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
- Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
- Claim Trust Drift: Claim trust drift is the gap between where a token was issued and where it is later accepted without enough restriction. It happens when audience, issuer, or lifetime controls are too broad, allowing a valid cryptographic token to create invalid access across systems.
Deepen your knowledge
NHI Foundation Level course covers NHI governance, machine identity security, and secrets management for practitioners who need to connect identity controls to software trust. It helps security and platform teams align identity governance with the release processes their programmes depend 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