Writable root filesystem
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
securityContext.readOnlyRootFilesystem: false leaves the container root filesystem writable, so an attacker can drop tools or modify binaries.
Why it matters
readOnlyRootFilesystem: false leaves the container root filesystem writable. An attacker who lands in the container can then drop tools, modify binaries, or persist between restarts. A read-only root filesystem forces writes into named volumes you control and makes tampering obvious. This is a defense-in-depth setting, so the finding is low severity.
How to fix it
Set readOnlyRootFilesystem: true and mount an emptyDir volume for each path the application legitimately writes to (often /tmp, a cache, or a run directory). Start the app, watch for read-only filesystem errors, and add a volume for each one until it runs cleanly.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo