An OSPO should track metrics that answer a question tied to a goal, not whatever is easy to count. The goal-question-metric method works in three steps: state the goal, write the questions that show progress, then choose metrics that answer them. Here it is applied to dependency governance.
Why numbers alone mislead
The OSPO book's metrics chapter, developed with the CHAOSS project, gives three example numbers: the average age of issues is 10.3 days, 121 pull requests last month, three new companies joined in 15 days. Without context, it says, these provide no insight. It recommends the goal-question-metric approach so that metrics support goals rather than work against them.
The three steps are simple. Identify and understand your organizational goals. Break them into specific, actionable questions. Develop operational, data-driven metrics to answer those questions. The chapter adds that some good data points, such as commit counts, may not be relevant to the question you actually need to answer.
An example for dependency governance
Here is one way to apply it. The goal and questions are ours, built on the chapter's organizational impact theme, which asks about inbound open source, which products and infrastructure contain it, and how OSPO strategy lines up with company strategy.
Goal: Know what open source we depend on and keep the risky parts under control.
| Question | Possible metric |
|---|---|
| What open source do our products contain? | Share of products with a current inventory |
| Do we know who our suppliers rely on? | Share of suppliers that provide a bill of materials |
| Are dependencies reviewed before use? | Share of new dependencies with an approved request |
| How quickly do we act on known problems? | Median time from fix available to fix deployed |
| Are we relying on projects that might disappear? | Number of critical dependencies with a single maintainer or no recent release |
The supplier question comes from the chapter itself, which lists the percentage of suppliers that provide open source bills of materials as a sample question under ecosystem impact.
Choosing what to leave out
The chapter's guidance on project health is blunt: it is too time-consuming and expensive to measure everything, so decide which aspects matter most for your needs, start small and refine. Apply the same rule to your dashboard. Five metrics that someone reads every month beat twenty that nobody does.
For each metric, write down what you would do if it moved. If the answer is nothing, drop it. The chapter's own phrasing on each goal is to consider what other information you need to feel confident about what a rise or fall would mean.
Reporting
Keep the report to one page: the goal, the questions, the current value of each metric and one sentence on what changed. See five numbers an open source program should report monthly for a concrete shortlist.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the figures that would answer one of your questions, such as how long a finding stays open.
How Safeguard fits
Safeguard provides SBOM and dependency scanning and compliance and evidence automation, which produce the underlying data for several of these metrics. Try gold.safeguard.sh/scan to see an inventory.
Quick check
How many metrics should an OSPO report?
Few. The chapter advises starting small and refining. A handful tied to explicit questions is enough.
Who defines the goals?
The OSPO together with its stakeholders, aligned to company goals, as the chapter recommends.
Sources
Last reviewed: 19 October 2026.
