Who should own developer risk controls in software supply chain security?

Why Ownership Matters in Supply Chain Risk Controls

Developer risk controls fail when everyone assumes someone else is handling them. In software supply chain security, the question is not whether security, engineering, and identity teams all contribute; it is whether one function is accountable for each control, exception, and signal. Without explicit ownership, build integrity, dependency review, signing, access governance, and alert response become fragmented, and that fragmentation creates predictable gaps.

That matters because supply chain weaknesses often sit at the boundary between code, identity, and runtime trust. Security policy can define the standard, but engineering usually controls the delivery pipeline, while platform, identity, and endpoint teams control the accounts, devices, and credentials that make the pipeline trustworthy. NIST’s Cybersecurity Framework 2.0 is useful here because it reinforces that governance, protection, detection, and recovery only work when responsibilities are assigned and observable.

In practice, many organisations discover ownership gaps only after a dependency, signing, or privileged access failure has already been exploited rather than through intentional control design.

How Ownership Should Be Split Across Teams

The cleanest model is shared execution with single-point accountability. Security should own the policy intent, risk thresholds, and monitoring rules for supply chain controls. Engineering should own secure implementation in the SDLC and CI or CD pipeline, because the team that operates the delivery system is best placed to make controls usable. Identity teams should own access governance for human and non-human credentials that can alter source, build, or release systems. Endpoint teams should own the device trust conditions that determine whether those credentials and workflows are allowed to operate.

This division works because each team controls a different failure surface. Security defines what must be true, engineering makes it true in the pipeline, identity reduces the chance that compromised access can reach critical systems, and endpoint controls reduce the chance that an untrusted device can sign, approve, or deploy code. The practical mistake is to assign the control to the team that notices the problem last, rather than the team that can prevent the failure first.

• Security owns control requirements, alert thresholds, and exception criteria.
• Engineering owns pipeline enforcement, code review gates, and release discipline.
• Identity owns privileged access, token lifecycle, and approval paths.
• Endpoint teams own device posture, hardening, and trust enforcement for build and release workstations.

That operating model breaks down when a control crosses too many handoffs, because delays in one layer quickly become bypasses in another.

Shared Responsibility Without Shared Ambiguity

Tighter supply chain control often increases coordination overhead, requiring organisations to balance stronger assurance against slower delivery and more exception handling. The tradeoff is real: if ownership is too fragmented, no one can close a gap; if it is too centralised, the control becomes detached from the systems that actually produce risk.

The edge cases are usually about boundaries. A platform team may operate the CI/CD tooling, but the application team still owns dependency choices and signing discipline. A security team may mandate controls, but it cannot be the day-to-day owner of every build rule unless it also runs the pipeline. Where there is disagreement, the decision rule should be simple: the team that can change the risky behaviour fastest should own implementation, while the team that can judge acceptable risk should own policy and escalation. For software supply chain security, that often means a RACI-style model, but the exact structure matters less than whether every control has one named owner and one named backup. The common failure is assuming that “shared” means “everyone is responsible,” which usually means nobody is accountable.

Practitioner Guidance

What to prioritise: Assign ownership by control layer, not by organisational convenience. Policy, pipeline enforcement, access governance, and device trust should each have a primary owner and an escalation path.

Decision rule: If a control can be bypassed by changing build behaviour, engineering must own the implementation; if it can be bypassed by changing access, identity must own it; if it can be bypassed by changing trust criteria, security must own the standard and verification.

What to verify: Confirm that every critical pipeline control has a named operator, a measurable condition for success, and a documented exception process. If any of those are missing, the control is not truly owned.

Practitioner takeaway: The best ownership model is the one that prevents gaps between policy, access, and execution, because software supply chain failures usually emerge in the seams rather than inside a single team’s remit.

Related resources from NHI Mgmt Group

• Why do security teams need granular policy controls for software supply chain risk?
• What do security teams get wrong about software supply chain risk?
• How should security teams govern software supply chain risk in application delivery?
• How should security teams govern software supply chain risk when CI/CD identities can publish code?