ASVS 5.0 V15.1.5 is a Level 3 requirement. Application documentation must highlight the parts of the application where "dangerous functionality" is used.
The standard does not give a fixed list. You define it for your stack and then say where it appears.
Why it matters
Certain language features and APIs turn small input mistakes into serious compromise: running shell commands, evaluating code from strings, deserializing untrusted objects, building file paths from user input, loading templates dynamically, disabling certificate checks, calling native code, and writing raw SQL.
When these are scattered and undocumented, reviewers miss them and new developers copy them. When they are listed, you can review each one on purpose and notice when a new one appears.
How to implement it
Start with a definition for your language. For a Python and JavaScript shop it might be:
eval,exec,Functionconstructorsubprocesswithshell=True,child_process.execpickle.loads,yaml.loadwithout a safe loader, JavaObjectInputStreaminnerHTML,dangerouslySetInnerHTML- raw SQL string building
- disabled TLS verification
- file system access built from request data
Find where they occur with a code scan, then record each place.
grep -rnE "eval\(|exec\(|shell=True|pickle\.loads|innerHTML|dangerouslySetInnerHTML|child_process" src/ \
| grep -v "/tests/"
Turn the results into a maintained register that sits with the code:
## Dangerous functionality register
| Location | What | Why needed | Safeguard | Owner |
|---|---|---|---|---|
| src/reports/render.py:88 | subprocess call to PDF tool | No library available | Fixed argument list, no shell, input validated by allowlist | reports team |
| web/components/Editor.tsx:41 | dangerouslySetInnerHTML | Rich text preview | Sanitized with DOMPurify before render | web team |
Keep it current by making it part of the pull request: a rule in the repository that flags new matches of the patterns above and asks the author to add or update an entry.
Static analysis is better than grep for this because it understands code structure and data flow. The SAST code scan demo shows the kind of findings a scan produces, which you can use as the starting list for the register.
Click through it at your own pace, or open it full screen.
How to test it
- Read the definition of dangerous functionality. It should be specific to your languages and frameworks.
- Run a search or static scan for those patterns across the repository.
- Compare the results with the register. Every real occurrence should have an entry, and every entry should still exist.
- For two entries, verify the stated safeguard in the code, for example that
shell=Trueis not used and arguments are not built from user data. - Check the history: a recent commit that added a new occurrence should have updated the register.
Common mistakes
- Treating the register as a one time deliverable.
- Listing the feature without the safeguard.
- Missing dangerous behavior that comes from dependencies and configuration, such as an XML parser with external entities enabled or a framework debug switch.
- Excluding test and build scripts, which also run with real credentials.
- A definition so broad that nobody reads the list.
Quick check
Who decides what counts as dangerous?
You do, for your stack. Start from the common categories, add what your own incidents and reviews have taught you, and write it down.
Is documenting enough to be secure?
No. The document directs review and records safeguards. The safeguards themselves still have to be correct in code.
