systemd-analyze security scores a service unit from 0.0 to 10.0 for how exposed it is. Higher means less sandboxing applied by systemd. It is a prompt for what to tighten next, not a verdict on whether the service is vulnerable, and a low score does not prove a service is safe.
Run it
With no arguments, the command lists all loaded, long-running services in a terse table. With a unit name it prints a detailed breakdown:
systemd-analyze security --no-pager myservice.service
Each line is a setting systemd checks, with a mark showing whether it is applied, a plain description such as "Service runs as root user", and an exposure value. The last line is the overall level for the unit.
What the manual says the score is
The systemd-analyze manual describes the overall level as an estimation in the range 0.0 to 10.0 indicating how exposed a service is security-wise. High levels indicate very little applied sandboxing, low levels indicate tight sandboxing. Its own example shows systemd-logind.service at 4.1 with an OK label.
Two cautions from the same page deserve repeating:
- A high exposure level does not mean there is no effective sandboxing in the service code itself, nor that the service is actually vulnerable.
- Only systemd's per-service features are counted. Protections the program applies on its own are invisible to the tool.
Why individual settings are not enough
The manual points out that many settings can be circumvented unless combined with others. For example, if a service keeps the privilege to establish or undo mount points, many sandboxing options can be undone by the service code. So fixing one red line at a time can move the number without moving real safety. Look for the combination, such as a non-root user plus dropped capabilities plus a read-only file system.
The tool also cannot see IPC. If a service can talk to D-Bus, it might ask other services to do things that are not under the same restrictions. A full review has to include that access policy.
A practical routine
- Run the table for all services and sort by the worst scores.
- Pick network facing services first.
- Add a few directives, starting with the basic five.
- Re-run the command, restart the service, and run its normal tests.
- Record the before and after numbers in the change ticket.
Some lines will stay red because the service genuinely needs the access. Write down why. That note is the useful artifact.
For code level risk in the same service, Safeguard offers SBOM and dependency scanning and reachability analysis, with a free scan at gold.safeguard.sh/scan.
Quick check
Does a score of 9.0 mean my service is vulnerable?
No. It means little systemd sandboxing is applied. The service may still be well protected by its own code, but it likely benefits from more settings.
Does a low score mean I am done?
No. The tool only sees systemd settings, not application bugs, IPC access or host level controls.
Sources
Last reviewed: 19 October 2026.
