An open source program office, or OSPO, is the team that sets and runs a company's rules for using and contributing to open source. For security, it owns the intake process, the approved package list, license and vulnerability policy together, and the inventory of what is actually in use.
The security duties, in order of value
Most companies that start an OSPO begin with licensing. Security duties tend to be added after the first scare. It is quicker to plan for both from the start, because the same intake form answers both questions.
| Duty | What it looks like in practice |
|---|---|
| Intake and approval | A short request form, a risk tier, a decision and an owner |
| Approved list | A maintained list of packages and versions teams may use |
| Policy | One document covering license rules and vulnerability response times |
| Inventory | A current list of open source in every product and service |
| Exceptions | A time limited waiver process with a named approver |
| Contribution rules | What employees may publish, and from which accounts |
Where it sits
There is no single correct shape. Some companies place it in engineering, some in legal, some in security. What matters is that it has a named lead, a budget line and the authority to say no. If it can only advise, teams will route around it.
A small company does not need a department. One engineer with a few hours a week, one person from legal for license questions and one from security can cover the table above. Write down who decides, and what happens when they disagree.
What an OSPO should not do
It should not review every package by hand. That does not scale and teaches teams to avoid asking. Use tiers: low risk packages pass automatically against agreed rules, and only unusual cases get a person.
It should not own every fix. The team that owns the product owns the vulnerability. The OSPO owns the policy that says how fast, and the report that shows whether it happened.
First 90 days
- Build an inventory from lockfiles and container images, even if it is rough.
- Write a one page policy covering allowed licenses, vulnerability response times and the exception route.
- Publish an intake form and promise an answer time.
- Route all package downloads through one internal proxy so you can see what is used.
- Pick three numbers to report monthly, such as open requests, average decision time and overdue vulnerabilities.
The NIST Secure Software Development Framework, SP 800-218, is a reasonable reference for the secure development practices an OSPO policy should line up with. It describes a core set of high level practices that can be fitted into any development process.
Try it yourself
Click through it at your own pace, or open it full screen. This is the kind of inventory view an OSPO needs as its starting point.
Quick check
Do we need an OSPO if we only consume open source?
Consumers benefit most, since intake, inventory and policy are consumer problems. It can be a part time role rather than a team.
Should the OSPO sit in security or legal?
Either can work. Pick the place where it will have authority and a budget, and make sure both functions have a seat in decisions.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Sources
- NIST, SP 800-218, Secure Software Development Framework version 1.1 (February 2022): description of the framework.
Last reviewed: 19 October 2026.
