Tag every finding with the stage that first caught it (IDE, pull request, build, proxy or scheduled scan), then compare how many each caught, how fast they were fixed, and how often a stage was bypassed. Use your own data. No external benchmark describes your pipeline, and this post does not offer one.
Why measure at all
You probably run several stages already. The question is which are earning their cost, which overlap, and where gaps remain. Without data, decisions follow opinion, and the loudest opinion wins.
The metrics
| Metric | How to compute | What it tells you |
|---|---|---|
| First catch stage | For each finding, the earliest stage that reported it | Where the work is actually being done |
| Escape count | Findings first seen at a later stage than they could have been | Gaps in earlier stages |
| Time to fix by stage | Fix date minus first catch date, grouped by stage | Which stage produces actionable findings |
| Block rate | Share of pull requests blocked by the gate | Whether the gate is too loose or too tight |
| Exception rate | Exceptions granted per period | Whether rules fit reality |
| Bypass signals | Direct registry traffic, skipped hooks, disabled checks | Whether people route around the controls |
| Repeat findings | Same package flagged again after being fixed | Weak fixes or missing guardrails |
All of these come from records most teams already have: scan output, pull request history, issue tracker, registry logs.
How to run a first measurement
- Pick a period you can look back on, such as the last quarter.
- Export findings with timestamps and the stage that reported them.
- For a sample of findings, work out the earliest stage that could have caught each one. This is manual and approximate, so be transparent about the sample.
- Group the results by stage and write down what you see, including surprises.
- Choose one change to test, such as adding a proxy rule or tightening a threshold, and re-measure after the next period.
Reading the results
- Most findings first caught at build or scheduled scans: earlier stages are missing or too lenient. Consider a pull request gate.
- Many escapes from the pull request stage: transitive coverage may be weak. See whether pull request scans cover transitive dependencies.
- Long fix times for scheduled findings: ownership is unclear, or findings lack a fix path.
- Rising bypass signals: the controls are costing more than people will pay, so fix speed and exceptions.
What to avoid
- Counting findings as a measure of success. More findings can mean better coverage, not worse code.
- Comparing yourself to another organisation's numbers. Your stack, history and tools differ.
- Reporting without a decision attached. Every metric should point at a change you might make.
Where Safeguard fits
Safeguard provides dependency scanning, SBOM generation, and compliance and evidence automation, which gives you records to measure from. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is a higher number of findings a good sign?
Not by itself. It can mean better coverage. Look at fix times and escapes alongside it.
How often should we repeat this review?
Once a quarter is a workable rhythm, or after any significant change to your pipeline.
Last reviewed: 19 October 2026.
