ASVS 5.0 V15.2.5 requires extra protection around parts of the application documented as dangerous functionality or built on risky third party libraries. It is Level 3. Use sandboxing, containers, separate processes or network isolation so an attacker who breaks one part cannot pivot to the rest.
Why it matters
Some code is inherently hazardous: document converters, image and archive parsers, template engines, anything that runs user supplied logic. These components have long vulnerability histories. Assume one will fail eventually and limit what failure can reach.
How to implement it
Document which components qualify, then isolate each one. A common pattern is a separate worker with no secrets and no inbound access from the internet:
services:
converter:
image: registry.example.com/doc-converter:1.4.2
read_only: true
user: "10001:10001"
cap_drop: [ALL]
security_opt: ["no-new-privileges:true"]
networks: [internal_only]
mem_limit: 512m
pids_limit: 64
networks:
internal_only:
internal: true
The converter can read its input and write its output, and nothing else. No database credentials, no outbound internet.
How to test it
From inside the isolated component, try to reach the database, the metadata service and the internet. All should fail. Confirm it cannot write outside its scratch directory and has none of the main application's environment variables.
Common mistakes
- Running the risky parser inside the main process because it is faster.
- Sharing a service account between the sandbox and core services.
- Having a document but never reviewing which libraries are on the risky list.
Quick check
Is a container boundary the same as a sandbox?
Not quite. Containers share a kernel. For hostile input, add dropped capabilities, seccomp profiles or a stronger runtime.
