Security teams should define policy, ranking logic, and escalation rules, while engineering teams should own fix execution inside the delivery workflow. That split works only when every critical finding has a named owner and a clear path to approval, remediation, and verification. Otherwise, accountability dissolves into backlog noise.
How Engineering and Security Should Divide Open Source Risk Ownership
Open source risk is shared, but the responsibilities are not identical. Security should set the policy baseline, ranking model, and escalation thresholds; engineering should own fix execution in the delivery workflow. The practical test is simple: if a finding can be remediated only by changing code, dependencies, build settings, or release habits, engineering owns the action, while security owns the control system that decides what gets attention first.
That division works only when responsibility is explicit. Every material issue needs a named owner, a remediation path, and a verification step, or the work degrades into backlog noise and unresolved exceptions.
What Security Owns Versus What Engineering Owns
Security owns the governance layer: policy, severity criteria, intake rules, exception handling, and the logic that determines when a finding becomes urgent. Engineering owns the delivery layer: upgrading dependencies, removing risky packages, rotating exposed secrets, adjusting build pipelines, and proving the fix did not break the product. That split keeps security from becoming a ticket queue and keeps engineering from treating open source risk as someone else’s problem.
In mature programs, security also defines what evidence is required before closure. That can include a dependency update, a clean build, a validated replacement package, or a confirmed absence of the vulnerable artifact in the release path. Engineering should not be asked to guess whether a fix is “good enough”; the closure criteria need to be visible before the work starts.
For teams that need a concrete operating model, OpenSSF is useful as a broader reference point for open source supply chain security practices, while XZ Utils backdoor 2024 shows why maintainer trust, release integrity, and review of upstream changes cannot be treated as purely theoretical concerns.
Why Accountability Breaks Down in Practice
The most common failure is not lack of detection, it is ambiguity. Security raises findings that are technically accurate but operationally unfinished, while engineering receives tickets without enough context to prioritise or verify. That gap becomes dangerous when the same dependency appears in multiple products, when a fix requires coordinated release timing, or when a maintainer decision affects many downstream consumers.
The second failure mode is ownership drift. A vulnerability may be “known” but not assigned to a specific product, team, or release train, so it remains open long after it should have been remediated. This is especially risky for secrets leakage, supply chain compromise, and package tampering, because the impact often depends on whether the vulnerable artefact is merely present or actually reachable in production.
PyPI secrets exposure 2023 is a reminder that publishing or yanking a package does not automatically remove embedded secrets from circulation, and LiteLLM PyPI package breach illustrates how open source distribution can become an access-path problem, not just a code-quality problem. In other words, the risk is not limited to “bad code”; it often includes credentials, tokens, and trust boundaries.
How to Make the Handoff Work
The handoff works best when security triages and engineering executes inside the same workflow, not in separate systems with different language. Security should rank findings by exploitability, exposed surface, and business reach. Engineering should receive the finding with enough specificity to decide whether the right action is patch, replace, isolate, revoke, or compensate with a control.
The cleanest operating rule is this: security can declare the condition, but engineering must close the condition. If a package is compromised, a token is exposed, or a build path is untrusted, the fix is not complete until the affected dependency or credential is removed from the reachable path and the release state is verified. That is why open source risk management has to live inside change management, dependency management, and release engineering, not only in a security review queue.
ArtiPACKED 2024 and Nx s1ngularity attack 2025 both show why “fix execution” must include CI/CD hygiene, not just dependency updates. When build artefacts, publishing tokens, or pipeline credentials are exposed, remediation must extend beyond the package itself to the surrounding release machinery.
Risk and Threat Considerations
Open source risk becomes material when trust is misplaced in upstream code, maintainer access, build artefacts, or leaked secrets. The threat is not only exploitation of a vulnerable library, but also abuse of the delivery chain that gets malicious or compromised code into production.
Failure mechanism: Ambiguous ownership leaves exposed dependencies, tokens, or build paths active longer than intended, and attackers can exploit that delay to steal credentials, poison releases, or piggyback on trusted update channels.
Impact: The result can be account compromise, malicious code delivery, wider supply chain exposure, and loss of confidence in the release process, especially when the same dependency or credential is reused across multiple projects.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-18 — Incident Response Management | Open source supply-chain incidents need clear escalation and coordinated response. |
| Recommendation — Define escalation paths and response ownership for compromised dependencies and build assets. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Dependency and build changes are the core execution point for open source remediation. |
| RA-5 — Vulnerability Monitoring and Scanning | Security needs a ranking and intake model for open source findings and exposure. | |
| CA-7 — Continuous Monitoring | Open source risk needs ongoing verification that fixes remain effective over time. | |
| Recommendation — Require controlled review and approval for dependency, build, and release changes. Continuously scan dependencies and prioritize findings by exploitability and reachability. Monitor open source assets and confirm remediations stay effective after release. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Open source findings are technical vulnerabilities requiring defined ownership and remediation. |
| Recommendation — Track, assess, and remediate open source vulnerabilities through an accountable process. | ||
Practitioner Guidance
What to prioritise: Assign remediation ownership at the product or repository level, not just at the team level. If a finding cannot be linked to a release train, a maintainer, and a verification step, it will usually remain open even when everyone agrees it is important.
What to verify: Before closing a high-risk open source issue, verify that the vulnerable package, secret, or pipeline path is no longer reachable in the build or runtime path. A ticket that says “upgraded” is not enough if the old artefact still ships in another service.
Common mistake: Treating security as the owner of the fix because security found the issue. That creates a false division of labour; security should own policy and escalation, while engineering owns the concrete remediation inside the delivery workflow.
Practitioner takeaway: Open source risk is manageable only when policy and prioritisation stay with security and remediation stays with engineering, with one named owner accountable for each critical finding from detection through verification.
Related resources from NHI Mgmt Group
- How do security teams reduce supply-chain risk in open-source release processes?
- How should security teams govern AI-assisted code that may include open source licensing risk?
- Why do malicious open source dependencies create such a high-risk failure mode for application security teams?
- Who is accountable for supply chain risk when maintainers and security teams share responsibility?