ASVS 5.0 V15.2.1: Keep Components Inside Fix Deadlines

ASVS 5.0 requirement V15.2.1 says the application may only contain components that have not breached your documented update and remediation time frames. It is a Level 1 requirement, so it applies to every application that claims ASVS conformance. In short: write down how fast you fix vulnerable or outdated dependencies, then prove that nothing in production is older than that deadline allows.

Why it matters

Most breaches through dependencies involve a flaw that already had a patch. The gap was not knowledge, it was time. A documented deadline turns "we should update that" into a measurable rule with an owner.

The requirement has two halves. The first is a written policy. The second is evidence that the policy is met. Teams often have the policy and no evidence, or evidence of a dashboard nobody acts on.

How to implement it

Start with the policy. A workable example:

• Known exploited vulnerabilities: 48 hours to patch or mitigate.
• Critical: 7 days.
• High: 30 days.
• Medium: 90 days.
• Unmaintained components (no release in 24 months): reviewed each quarter, replaced or formally accepted.

Then enforce it where code enters production. The simplest control is a CI step that reads your lockfile, looks up known vulnerabilities, and fails the build when a finding is older than its deadline. Here is a small Python check that takes a findings file and applies the deadlines:

import json, sys
from datetime import datetime, timezone

DEADLINE_DAYS = {"critical": 7, "high": 30, "medium": 90}

def overdue(findings, now=None):
    now = now or datetime.now(timezone.utc)
    bad = []
    for f in findings:
        limit = DEADLINE_DAYS.get(f["severity"].lower())
        if limit is None:
            continue
        found = datetime.fromisoformat(f["first_seen"])
        if found.tzinfo is None:
            found = found.replace(tzinfo=timezone.utc)
        if (now - found).days > limit:
            bad.append(f)
    return bad

if __name__ == "__main__":
    with open(sys.argv[1]) as fh:
        late = overdue(json.load(fh))
    for f in late:
        print("OVERDUE", f["package"], f["version"], f["severity"])
    sys.exit(1 if late else 0)

The important field is first_seen. Deadlines run from when you learned about the flaw, not from when you last scanned. Store that date somewhere durable.

Reachability matters here. A critical flaw in a function your code never calls can reasonably get a different treatment than one on a live request path, as long as the policy says so and the decision is recorded. Safeguard's reachability analysis helps you document that call, and the free in-browser dependency scan at https://gold.safeguard.sh/scan is a quick way to see what your manifest contains today.

Click through it at your own pace, or open it full screen.

How to test it

1. Ask for the written policy. If it does not exist, the requirement fails regardless of the code.
2. Export the current component inventory from the production build, not from the repository head.
3. Run a vulnerability lookup against that inventory and list every finding with its first seen date.
4. For each finding, compare age to the policy. Anything past its deadline needs either a fix, a documented mitigation, or a signed risk acceptance with an expiry date.
5. Intentionally add a known vulnerable package version on a branch and confirm the pipeline fails the build.

Common mistakes

• Measuring deadlines from the CVE publish date for some findings and the scan date for others.
• Scanning the repository but shipping a container image with a different set of packages.
• Risk acceptances with no expiry, which quietly become permanent.
• Ignoring transitive dependencies because the manifest only lists direct ones.
• Counting a pull request as a fix before it is merged and deployed.

Quick check

Sources

• OWASP Application Security Verification Standard 5.0
• Free in-browser dependency scan