ASVS 5.0 V15.1.4 is a Level 3 requirement. Your application documentation must highlight the third party libraries you consider "risky components".
Why it matters
Not every dependency carries the same risk. A library that parses untrusted input, has one maintainer, has had no release in years, or has a history of serious flaws deserves more attention than a date formatting helper. Naming them tells reviewers where to look, and tells the team to plan for replacement.
How to implement it
Define criteria, then keep a short register.
Typical criteria: unmaintained or archived, single maintainer, parses untrusted data, runs native code, needs broad permissions, repeated past vulnerabilities, or lacks a clear license.
# docs/risky-components.yaml
- name: legacy-xml-parser
version: 2.3.1
reason: [unmaintained, parses untrusted input]
mitigation: "Runs in a sandboxed worker, input size capped"
owner: platform-team
review_by: 2026-12-01
replacement_plan: "Move to maintained parser in Q1"
Generate candidates from your dependency data. Reachability analysis shows whether a risky library sits on a path that handles real input, which makes the ranking more honest. See the dependency inventory demo for an example of what that data looks like.
How to test it
Open the register. Pick three components from the SBOM that match your criteria and confirm each is listed. Confirm every entry has an owner, a mitigation and a review date that has not passed.
Common mistakes
- Using popularity as a proxy for safety.
- A register written once and never reviewed.
- Listing the risk without any mitigation.
Quick check
Does a risky component have to be removed?
No. It has to be identified, understood and mitigated, with a plan if the risk is high.
