Accountability usually spans engineering, platform security, and supply chain governance. Engineering owns dependency selection, platform teams own build isolation and egress controls, and security owns detection and policy enforcement. For regulated environments, the question becomes whether the organisation can prove it had reasonable controls over code provenance and execution.
Why This Matters for Security Teams
A build dependency that exfiltrates source code is not just a software defect. It is a supply chain event that can expose intellectual property, secrets, signed artifacts, and downstream customers in one path. Accountability matters because the failure often sits across several control owners, and that overlap can leave gaps in provenance, code review, and build isolation. NIST control families for software and system integrity, including NIST SP 800-53 Rev 5 Security and Privacy Controls, help structure that ownership.
The practical risk is that teams assume package selection is a developer choice alone, then discover too late that CI runners had broad network access, build credentials were reused, or dependency updates were not subject to policy review. Security teams also need to distinguish between the actor that introduced the dependency, the platform that allowed it to execute, and the governance function that should have detected unusual behaviour. Those are different accountability layers, even when one incident reveals them all.
In practice, many security teams encounter the problem only after source code has already left the build environment, rather than through intentional dependency governance.
How It Works in Practice
Accountability should be assigned by control domain, not by blame. Engineering teams usually own the dependency decision, including whether a library is pinned, reviewed, and sourced from a trusted registry. Platform or DevOps teams typically own the build environment, including ephemeral runners, network egress restrictions, secret handling, and isolation between pipelines. Security and risk functions own policy, monitoring, and exception handling, while legal or procurement may become involved when supplier terms or provenance obligations are in scope.
In a mature program, the organisation should be able to show:
- approved sources for dependencies and maintainers;
- reproducible builds or at least controlled build inputs;
- egress controls that limit where build jobs can send data;
- secret scanning and short-lived credentials in pipelines;
- logging that ties a build to a commit, runner, image, and dependency version.
These expectations map well to software supply chain guidance in the NIST control catalog and to the broader supply chain risk management practices referenced by OWASP and SLSA-style provenance thinking. The key point is that accountability is not the same as operational fault: a developer may have added the package, but the organisation is accountable for whether the environment allowed that package to observe or transmit source data without restraint.
Where this becomes measurable is incident response. Teams should be able to answer who approved the dependency, what permissions the build had, whether the dependency executed during install or test time, and whether any exfiltration controls or alerts fired. These controls tend to break down when legacy CI systems share credentials across jobs because containment and attribution both disappear.
Common Variations and Edge Cases
Tighter dependency controls often increase build friction, requiring organisations to balance developer velocity against supply chain assurance. That tradeoff is real, especially where teams rely on fast-moving open source ecosystems or generated build artifacts.
There is no universal standard for this yet, but current guidance suggests that accountability should shift more heavily toward the platform and governance owners when the organisation permits untrusted code to execute in privileged CI contexts. If the pipeline can reach the internet, access source repositories, and inherit long-lived credentials, then the build environment becomes part of the attack surface and not just a neutral execution layer.
Edge cases matter. In monorepos, one team may own the dependency while another owns the runner image. In outsourced or shared build environments, supplier management may be accountable for control assurance even if engineering approved the package. In regulated sectors, proof of reasonable control often matters more than proving exactly which person caused the event. Frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the software supply chain integrity practices in SLSA are useful because they turn accountability into evidence, not assertion.
The sharpest failure mode appears in fast-moving CI/CD environments where ephemeral trust is assumed but egress, secrets, and provenance are not actually constrained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 set the technical controls, while EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Software and build process integrity are central to limiting dependency abuse. |
| EU Cyber Resilience Act | Product security obligations increasingly include supply chain and update governance. |
Treat dependency governance as a product security requirement and retain proof of controls.
Related resources from NHI Mgmt Group
- Why do source-code leaks from build pipelines matter to IAM and NHI teams?
- Who is accountable when an AI agent or build pipeline introduces malicious code?
- Who is accountable when AI supply chain exposure leaks customer data or source code?
- Who is accountable when a malicious dependency enters a build pipeline?
