Who is accountable when a pipeline accepts an unsigned dependency?

Why This Matters for Security Teams

An unsigned dependency is not just a packaging issue, it is a control failure in the software supply chain. If build systems accept artefacts without verification, teams lose assurance about provenance, integrity, and change accountability. That creates space for dependency confusion, tampering, and malicious updates to reach production. The governance question matters because the technical failure often reflects an ownership gap, not a tooling gap. NIST SP 800-53 Rev 5 Security and Privacy Controls treats supply chain and integrity-related safeguards as an organisational responsibility, which is the right lens for this problem.

Security teams often assume that a signature check alone solves the issue, but accountability is broader. Someone defines the policy for trusted sources, someone approves exceptions, and someone decides whether the release proceeds when verification fails. If those responsibilities are unclear, teams may silently bypass checks to keep delivery moving. In practice, many security teams encounter unsigned dependencies only after a compromised package has already been promoted through the pipeline, rather than through intentional control design.

How It Works in Practice

Operational accountability should be assigned across three decision points: ingestion, verification, and release approval. At ingestion, platform or developer experience teams usually maintain the pipeline rules that decide whether unsigned dependencies are blocked, quarantined, or reviewed. At verification, security or supply chain owners define what counts as trusted evidence, such as package signatures, maintainer keys, checksums, provenance metadata, or an internal allowlist. At release, application owners or release managers should own the final decision to proceed when a dependency cannot be validated.

In mature environments, this is not left to informal judgment. The policy should state:

• which repositories, registries, and signing keys are trusted
• who can add or rotate trusted keys
• who can approve a temporary exception
• how exceptions expire and are reviewed
• what happens when verification fails in a release branch

That approach aligns with supply chain guidance such as the NIST supply chain risk management guidance, which emphasises governance over artefact trust, not just technical scanning. It also fits wider software integrity practice described in SLSA, where provenance and build integrity are part of release assurance. Where organisations use automation, the pipeline should fail closed by default, then route exceptions into a documented approval path with audit evidence. These controls tend to break down when legacy build systems, urgent hotfixes, and decentralised repository access all exist at the same time because exception handling becomes faster than governance.

Common Variations and Edge Cases

Tighter dependency controls often increase delivery friction, requiring organisations to balance build velocity against trust assurance. That tradeoff becomes sharper in open-source-heavy environments, monorepos, and rapid release pipelines where dependencies change frequently. The right answer is not always to block everything unsigned, because some internal packages may still lack mature signing practices. Current guidance suggests treating those cases as temporary risk acceptances, not normal operating mode.

There is also a difference between unsigned, unverified, and unverifiable. An artefact may be unsigned but still internally reviewed, or signed by a key that the pipeline does not trust. Those are different governance problems. Teams should not blur them. If a dependency is allowed through because a release deadline is near, the exception owner should be explicit and the risk should be time-bound. Where agentic build automation is involved, the identity of the agent or service account performing the import should be part of the control record, especially when OWASP guidance on agentic and LLM-related risks intersects with automated dependency selection. Best practice is evolving here, and there is no universal standard for this yet.

Related resources from NHI Mgmt Group

• Who is accountable when a malicious dependency enters a build pipeline?
• Who is accountable when a pipeline secret is leaked or reused?
• Who is accountable when a sign-up flow accepts sanctioned-region accounts?
• Who is accountable when a product ships with unsafe defaults or weak dependency hygiene?