Why does code signing not solve supply chain risk by itself?

Why This Matters for Security Teams

Code signing is often treated as the final trust gate, but that assumption is too narrow for modern software delivery. Signing proves who published an artifact and that the artifact was not altered after signing, yet it says nothing about whether the build environment, dependency graph, or upstream source was already compromised. That distinction matters because supply chain attacks frequently succeed before release engineering ever sees the package.

Security teams can see this pattern in incidents such as the Reviewdog GitHub Action supply chain attack, where trust in a signed or trusted workflow would not have prevented upstream compromise from propagating. The OWASP Non-Human Identity Top 10 also reinforces that machine-to-machine trust needs stronger provenance and secret handling than a signature alone can provide. NHI Management Group research shows why this is urgent: 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection without revocation leaves durable exposure. In practice, many security teams discover the gap only after a signed artifact has already been promoted into production.

How It Works in Practice

Effective supply chain defense starts earlier than signing. The key question is not only whether an artifact was signed, but whether the inputs that produced it were verified, isolated, and reproducible. Current guidance suggests layering provenance controls around the build process so teams can answer where code came from, who changed it, what dependencies were resolved, and whether the build runner itself was trustworthy.

That usually means combining signed releases with:

• source integrity checks, including branch protections and reviewed commits
• dependency pinning and verification to reduce drift from upstream package compromise
• build attestation and provenance metadata so the artifact can be traced to a specific pipeline run
• ephemeral credentials for CI/CD runners, because long-lived secrets in automation become a high-value target
• runtime policy enforcement that can block promotion if provenance is missing or mismatched

This is where NHI and agentic governance overlap with supply chain security. A build pipeline is itself a non-human identity with privileges, secrets, and machine-to-machine trust relationships. The State of Secrets in AppSec highlights how organisations dedicate an average of 32.4% of security budgets to secrets management and code security, which reflects how much risk sits around the pipeline rather than only inside the signed artifact. For implementation guidance, the NIST Cybersecurity Framework 2.0 supports governance, protection, and detection controls that should wrap the signing step, not stop at it. These controls tend to break down when CI/CD runners retain persistent credentials and pull unverified dependencies from shared registries because the compromise happens before the signing key is ever used.

Common Variations and Edge Cases

Tighter provenance controls often increase build complexity and operational overhead, so organisations have to balance release speed against assurance. That tradeoff becomes especially visible in polyglot repositories, monorepos, and third-party action ecosystems where multiple maintainers, package managers, and runners interact in one pipeline.

Best practice is evolving, and there is no universal standard for this yet. Some teams rely on signature verification alone for low-risk internal tools, while others require signed provenance, SLSA-style attestations, and isolated build infrastructure for production releases. The right answer depends on blast radius, regulatory exposure, and how much trust is placed in external dependencies.

Edge cases also matter. A perfectly signed artifact can still be unsafe if malware was introduced into a dependency, if the signing key was stolen, or if the build runner was already compromised. That is why the Shai Hulud npm malware campaign and the LiteLLM PyPI package breach are so instructive: trust in the final package did not eliminate upstream compromise. For teams dealing with high-change pipelines or AI-assisted code generation, the real control objective is not just signature verification, but continuous provenance validation and fast revocation of anything suspicious.

Related resources from NHI Mgmt Group

• Why does supply-chain trust create so much identity risk?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• When does code injection become a supply chain risk?
• What breaks when a third-party identity is compromised in a supply chain attack?