The exposure window is the time a vulnerable, reachable component runs in production after a fix is possible. Measure it in stages, shrink the longest stage first, and automate the waiting steps. The short answers below cover the questions teams ask most, with links to deeper posts.
What are the stages?
Advisory published, alert raised, triage decided, fix ready, merged, deployed, verified. NIST SP 800-40 Rev. 4 defines patch management as identifying, prioritizing, acquiring, installing and verifying, which maps neatly onto these. See our mapping post.
What should I measure?
Per fix, record timestamps for each stage, then report the median and a high percentile per stage and in total. Group by service tier, as DORA advises against blending metrics across very different services. A dashboard layout is in this post.
Which stage should I shrink first?
The longest one in your own data. Run a one hour baseline to find it. Often it is waiting before or after the fix, not the fix itself.
What can I automate?
Alert routing, enrichment, fix PR creation, tests, deploy steps and verification. Keep exceptions and major upgrades with people. Details are in what to automate first.
Does deploy speed matter?
Yes. DORA defines change lead time as the time from commit to production, and your normal rhythm sets a floor under every fix. See deployment frequency and the exposure window.
Why did no fix PR appear?
The fix may not exist, may need a parent upgrade, may sit outside the files the bot reads, or may be filtered by a rule. See why no fix PR appeared.
Do cooldowns add exposure?
Not for security updates in the bots documented there, but check your configuration. See the cooldown post.
A summary table
| Question | Short answer |
|---|---|
| Where does the clock start? | Pick one definition, such as advisory published, and keep it |
| Where does it stop? | When the fix is running and verified |
| Mean or median? | Median plus a high percentile |
| What hides the tail? | Averages and percent patched |
| What is the cheapest win? | Fix ownership and idle waits |
| What is the riskiest shortcut? | Counting merge as done |
Common mistakes
- Stopping the clock at merge.
- Mixing services of different criticality in one number.
- Setting one total target with no stage targets.
- Automating before you have a baseline.
- Letting rules or schedules quietly delay security fixes.
What good looks like
A team that knows its stage medians, owns every alert, runs reachability to sort the queue, deploys on merge with gates, and verifies what is running. None of this needs a perfect tool. It needs definitions, timestamps and a weekly look at the numbers.
Try it yourself
Open the continuous monitoring demo to see why a single point in time check leaves gaps.
Click through it at your own pace, or open it full screen.
Safeguard offers dependency scanning, reachability analysis and remediation tracking. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Is there a standard target for the window?
Targets depend on your obligations and risk. Set them per tier from your own history, and check any regulatory text directly.
Where do I start?
Pick three services and compute stage times from their last few fixes.
Sources
Last reviewed: 19 October 2026.
