ASVS 5.0 V15.1.1 is a Level 1 requirement. Your application documentation must define risk based time frames for remediating vulnerable third party component versions and for updating libraries in general, to reduce the risk those components carry.
It asks for two things in writing: how fast you fix known vulnerabilities, and how often you update even when nothing is known to be wrong.
Why it matters
Most applications are mostly other people's code. Vulnerabilities in dependencies are published every day, and attackers start scanning for the serious ones within hours or days. Without a stated target, patching depends on who remembers, and the long tail of "we will get to it" grows.
A written time frame gives developers a clear rule, gives managers a measure, and gives auditors something to check.
How to implement it
Write a short policy that ties the deadline to risk, not only to the CVSS score. Reachability and exposure matter: a critical flaw in a function you never call is lower priority than a medium flaw in a public login path.
Example structure:
| Situation | Target |
|---|---|
| Known exploited in the wild, reachable, internet facing | 48 hours |
| Critical, reachable | 7 days |
| High, reachable | 30 days |
| High or critical, not reachable | 60 days or next scheduled update |
| Medium and low | 90 days or next release |
| Library with no known issue | Update at least quarterly |
Those numbers are examples. Choose values you can actually meet, then meet them.
Also record who decides exceptions and how they are logged:
# security/remediation-policy.yaml
exceptions:
approver: appsec-lead
maximum_duration_days: 30
require: [compensating_control, ticket_link, expiry_date]
Automate the clock. Open an issue when a new finding appears, stamp it with a due date from the table, and report on overdue items weekly. Automated update pull requests keep the "update in general" part moving:
{
"extends": ["config:recommended"],
"schedule": ["before 6am on monday"],
"vulnerabilityAlerts": { "labels": ["security"], "prPriority": 10 }
}
Reachability analysis helps you tell the urgent items from the noisy ones. The vulnerability management demo shows how findings can be prioritized and tracked against a deadline, and the free in browser scan at gold.safeguard.sh/scan gives you a first list of vulnerable dependencies to apply the policy to.
Click through it at your own pace, or open it full screen.
How to test it
- Find the policy in the application documentation. It must name time frames, not just say "promptly".
- Pull the open vulnerability list for the application and check each item against its deadline.
- Sample three resolved items from the last quarter and confirm they were closed within target, or that an approved exception exists.
- Check the age of the oldest dependency. Compare it with the "update in general" rule.
Common mistakes
- A policy that exists but has no numbers.
- Using one deadline for every severity, which is either unrealistic or too slow.
- Ignoring transitive dependencies, which are most of the tree.
- Exceptions with no expiry, which become permanent.
- Measuring detection but not time to fix.
Quick check
Does the policy have to use CVSS?
No. It has to be risk based. CVSS can be one input, alongside exploitation evidence, reachability and exposure.
What does "updating libraries in general" mean?
Routine updates even without a known vulnerability, so that you are never many major versions behind when a real fix lands.
