What are the signs that a software supply chain control is only proving one layer?

When a control is only proving provenance, not enforcing trust

A weak software supply chain control often looks reassuring because it answers one narrow question, then leaves the real trust boundary untouched. If the control can tell you who built or published an artifact but not who can change source, approve merges, or alter maintainer access, it is documenting lineage rather than constraining abuse.

Another sign is that the control stops at the artifact boundary. Build attestations, signatures, or package metadata matter, but they do not compensate for weak branch protection, unreviewed direct pushes, or maintainer accounts that can still be phished, reused, or hijacked. A compromised upstream account can still poison the pipeline if the path into publish rights remains open.

Useful examples of this split show up in practice. The HashiCorp GPG key exposure 2021 case shows why release signing is only one layer when the signing material itself is exposed. Likewise, the Ledger Connect Kit npm compromise 2023 and coa and rc npm hijacks 2021 incidents show that publisher trust collapses fast when account recovery, MFA, or offboarding are weak.

What the trust boundary should actually cover

The control is proving only one layer when it cannot connect source change, build execution, signing, and publication into one coherent chain of custody. If you can verify the package checksum but not the commit that produced it, or verify the commit but not the identity that published the release, an attacker can still insert malicious code through the untouched link in the chain.

That gap is especially obvious when the release process depends on implicit trust in a single maintainer or automation token. A strong control should reduce the chance that a compromised individual account, a stolen publishing token, or a malicious dependency can reach production without an independent check. A weak control merely adds evidence after the fact.

For broader supply chain hardening, SLSA is useful because it shifts attention from “can we sign it?” to “can we verify how it was built?” The NIST SSDF (SP 800-218) also helps because it ties release integrity to secure development practices rather than treating signing as a standalone assurance step.

What practitioners should inspect to find the gap

Start by tracing whether the control covers all of these decisions: who may change source, who may approve it, who may build it, who may sign it, and who may publish it. If those decisions live in different systems with different owners, you need to test the weakest handoff, not the strongest checkpoint.

What to verify: branch protection is enforced, maintainer access is reviewed, secrets are rotated, and publish permissions are not held by accounts that can be casually phished or reused. If any one of those is missing, the control is probably proving provenance while leaving a live path to compromise.

Common mistake: treating artifact signing, SBOMs, or trusted publishing as complete supply chain security. Those mechanisms are useful, but they are incomplete if upstream accounts, build triggers, or repository permissions can still be abused to produce a legitimate-looking malicious release.

Risk and Threat Considerations

The main risk is false confidence. A control that only proves one layer can make teams slower to detect compromise because it creates a paper trail that looks stronger than the actual enforcement boundary. Attackers target the missing layer, often upstream in maintainer identity, CI access, or repository control, because that is where a valid release can be turned malicious without breaking the outward proof.

Failure mechanism: the organisation verifies artifact lineage while leaving source authority or publish authority weak, so a compromised maintainer account, token, or build path can still produce trusted-looking output.

Impact: malicious code can enter downstream systems with legitimate metadata, which increases blast radius, slows incident response, and forces teams to distrust controls that should have been authoritative.

Practitioner Guidance

Decision rule: if the control answers “who signed it?” but not “who could have changed it?”, treat it as partial assurance and investigate the handoff between source control, CI, and publish rights before accepting the release as trusted.

What to measure: the percentage of releases that are protected by enforced branch rules, verified build provenance, and scoped publishing permissions, not just signatures or attestations. If one maintainer account or one token can still override the process, the control is not yet enforcing trust.

Practitioner takeaway: supply chain assurance is only as strong as its weakest upstream authority, so the right question is whether the control prevents unauthorized change, not merely whether it can later prove where the artifact came from.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• Why does AI make software supply chain risk harder to control?
• Which control should teams prioritise first in software supply chain governance?
• What breaks when software supply chain security relies only on version control controls?