An open source program office usually owns the policy, the intake guidance, training and a company-wide view of what open source is in use. The security team owns vulnerability triage and incident response. Legal owns license opinions. Engineering owns the fixes. Overlap is normal, so write the split down.
Why the question comes up
Dependency governance sits between several teams, and each one assumes another has it. The OSPO book from the TODO Group describes an OSPO as the center of competency for an organization's open source work, setting policies on use, selection and auditing, training developers and supporting legal compliance. It also notes that an OSPO can live in R&D, the office of the CTO, Engineering or Legal, or be a "virtual" group drawn from across the business. So the same job can sit in different places in different companies.
That flexibility is useful, but it means you cannot copy an org chart from another firm. You need a task list and a named owner for each line.
A starting split
The table below is a suggested split built from the activities the OSPO book lists. It is our reading, not a standard. Adjust it to your company.
| Task | Usual lead | Support |
|---|---|---|
| Open source usage and contribution policy | OSPO | Legal, security |
| Guidance on selecting and consuming projects | OSPO | Engineering |
| Training for developers and managers | OSPO | Security |
| Inventory of open source in use | OSPO or enterprise architecture | Engineering |
| Vulnerability triage and incident response | Security | Engineering, OSPO |
| License opinions and obligations | Legal | OSPO |
| Fixing or upgrading a dependency | Engineering | Security |
The OSPO book notes that the enterprise architecture team is often the one tracking open source components in applications, with the OSPO acting as subject matter expert. That is a good reminder that "who tracks it" and "who sets the rules" can be different teams.
Where the handoffs break
Three handoffs fail most often.
First, the inventory. If the OSPO keeps a list and security keeps a different list, neither is trusted during an incident. Pick one source of truth and make the other team read from it.
Second, exceptions. A developer asks for a license or a risky package and the answer depends on both legal and security. Name one person who collects both opinions and records the decision. See who approves open source policy exceptions by company size for options.
Third, response. When an advisory lands, security triages, but the OSPO usually knows which projects matter strategically. Agree in advance who tells engineering to act.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a single finding passes through triage, ownership and fix, and ask which of your teams would hold each step.
How Safeguard fits
Safeguard provides SBOM and dependency scanning, policies and gates, and asset discovery, so the OSPO and the security team can read from one inventory. You can try a free scan at gold.safeguard.sh/scan. For wider context, see open source governance in the enterprise.
Quick check
Does every company need an OSPO to govern dependencies?
No. The OSPO book describes OSPOs ranging from large multi-layer offices to informal, self-organized groups. What matters is that each governance task has a named owner.
Who should own the inventory?
Whoever can keep it current. Some companies use the OSPO, others use enterprise architecture. The key is a single list that security, legal and engineering all read.
Sources
- OSPO Book, Chapter 1: Introduction to Open Source Program Offices
- OSPO Book, Chapter 2: The Value of Open Source Program Offices
- OSPO Book, Chapter 4: Day-to-Day Operations
Last reviewed: 19 October 2026.
