Track five things: time from request to decision, the age of the oldest open request, the bypass rate, the number of active exceptions, and how often approved items are reopened. Together they show whether the process is fast, used and trusted.
Why a few good numbers beat a dashboard
Intake programs fail quietly. Requests pile up, developers find a workaround, and security reports the number of packages reviewed, which looks fine while the real traffic goes elsewhere. The right metrics expose that gap.
The five metrics
| Metric | What it tells you | How to compute it |
|---|---|---|
| Time to decision | Whether the SLA is met | Median and the slowest tenth, per lane |
| Oldest open request | Whether anything is stuck | Age of the oldest item in the queue |
| Bypass rate | Whether people use the process | Packages in builds that never went through intake, divided by all packages |
| Active exceptions | How much risk is accepted | Count of exceptions in force, with owners and expiry dates |
| Reopen rate | Whether approvals hold up | Approved items later revoked or flagged |
Use the median plus a high percentile for time, because an average hides the slow cases that cause the workarounds.
Bypass rate is the one that matters most
To compute it, take the list of packages that resolved in your builds from the lockfiles, and compare it with the approved list and the mirror logs. Anything present in builds but absent from intake records is a bypass or a gap, such as a transitive package. Separate those two categories, because they need different fixes.
A bypass rate that rises after you tighten a policy usually means the policy is too slow, not that developers are careless.
Exceptions need an expiry
Count exceptions and count how many have passed their review date. An exception without an expiry is a permanent policy change that nobody voted on. Report overdue exceptions to the owner each month.
Reading the numbers together
- Fast decisions and a high bypass rate: the process is fast but the front door is not obvious, or the mirror is easy to avoid.
- Slow decisions and a low bypass rate: egress controls are strong, and you are paying for it in developer time. Staff the queue.
- Low reopen rate with a short queue: healthy, but sample some approvals to make sure reviews are real.
- High reopen rate: checks happen too early or too lightly, or advisories are not feeding back into the list.
Keep it small
Publish these five in one monthly page with a short note on what changed and why. Resist adding more until the first five drive decisions. For the commitments behind the first metric, see what an intake SLA should say.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can provide the list of what is actually in your builds, which is the input to a bypass calculation, and its compliance and evidence automation can help you keep the reports. A free scan shows your current inventory.
Quick check
What is a good target bypass rate?
Aim for zero for direct dependencies and a declining trend overall. Any specific number depends on your setup, so set your own and review it.
How often should the metrics be reviewed?
Monthly is enough for most teams, with the oldest open request checked weekly.
Last reviewed: 19 October 2026.
