Time to first security feedback is the time from a developer pushing a change to the moment they see the first security result about it. Measure it per pull request, report the median and a high percentile, and shorten it by running quick checks first.
Why this metric helps
Developers work in small cycles. If security feedback arrives while they are still in context, fixing it costs minutes. If it arrives after they have moved on to something else, the same fix costs a context switch. The wait is a form of friction that no failure count reveals.
It also helps to separate it from the time the full pipeline takes. A developer cares about when the first useful signal arrives, even if slower checks keep running afterwards.
Define it precisely
Choose start and end events and write them down.
- Start: the push or the pull request update event.
- End: the first security check result visible on the pull request, whether pass or fail.
Decide what counts as a security check. A dependency check, a policy check or a scan of changed files might all qualify. Do not count a result that only says "queued".
How to collect it
- Record the push timestamp from your source host.
- Record the timestamp of each security check result posted to the pull request.
- Take the earliest security result per push as the end event.
- Store the interval with repository, check type and trigger.
Most CI systems let you pull creation and completion times for checks through an API, and the source host records the push time.
Which checks should come first
| Check | Typical speed | Put it |
|---|---|---|
| Lockfile and manifest diff against policy | Fast | First |
| Dependency vulnerability lookup for changed packages | Fast to moderate | Early |
| Scan of changed source files | Moderate | After the quick ones |
| Full repository or image scan | Slow | On schedule or after merge, if risk allows |
Ordering matters more than raw speed. A quick check that catches the common problem gives most of the value early.
Things that shorten it
- Scan only what changed on pull requests, and run the full scan on a schedule.
- Cache vulnerability data and package metadata.
- Start security jobs in parallel with tests, not after them.
- Make sure runners are available, since queue time counts toward the interval.
Things to watch
Speed bought by checking less is not a win. Pair this metric with coverage and with escape measures, such as findings that surface after merge. If time to first feedback falls and escapes rise, you traded accuracy for speed.
Quick check
Is a pending status the first feedback?
No. Count the first result that says something about the change, such as pass or a finding.
Should I set a target?
Set an agreed expectation with developers, review it with them, and use the metric to find problems rather than to rank teams.
How Safeguard fits
Safeguard's dependency scanning and policy gates can run on pull requests, with an IDE and CLI surface for earlier feedback. You can also run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
