SSDF practice PO.5 asks you to separate and protect each environment used to build software, and to harden developer endpoints. Use multi factor authentication, network segmentation, restricted access and monitoring, and keep configuration and log records as evidence that the protections exist.
The two tasks
- PO.5.1 Separate and protect each environment involved in software development.
- PO.5.2 Secure and harden development endpoints using a risk based approach.
Environments here include development, build, test and distribution. The aim is to stop a compromise of the environment from becoming a compromise of the software.
Environment protections from the examples
SP 800-218 version 1.1 lists, for PO.5.1:
- Multi factor, risk based authentication and conditional access for each environment
- Network segmentation to separate environments from production and from each other
- Tight limits on connections in and out, with internet access only where needed
- Minimal direct human access to build services, with monitoring of privileged use
- Regular logging and review of trust relationships between environments
- Continuous logging and monitoring across the environment components
Endpoint protections
For PO.5.2 the examples include approved hardening guides, least functionality and least privilege, multi factor authentication for access, dedicated development endpoints on non production networks, and monitoring of security posture.
Evidence map
| Protection | Evidence to keep |
|---|---|
| MFA on environments | Identity provider policy export |
| Segmentation | Network diagram and rule export |
| Build access | Access list and privileged use log |
| Endpoint hardening | Baseline document and compliance report |
| Monitoring | Alert configuration and sample alerts |
PO.5 examples also say to configure the security tools involved to generate artifacts, so the records come from the controls themselves.
Priorities for a small team
- Turn on MFA everywhere developers and build systems log in.
- Remove standing human access to build servers.
- Keep production credentials out of build and test.
- Baseline laptops and review the baseline once a year.
Do not forget the pipeline credentials
Build systems hold some of the most valuable secrets in a company, such as deploy keys and registry tokens. Treat them as part of PO.5. Keep them in a secrets store rather than in repository variables where possible, limit which jobs can read them, and rotate them on a schedule. Record the schedule and the last rotation. This single area is where many environment compromises begin, so evidence here carries weight with a careful reviewer.
Quick check
Does PO.5 cover the CI system?
Yes. Build environments are named in the practice, and the examples call out build services and toolchain systems.
Is zero trust required?
The examples mention following a zero trust architecture as one option. They are notional examples, not mandates.
Where tooling helps
Safeguard offers asset discovery and compliance and evidence automation for recording what exists and what was checked. Hardening itself is done in your own systems. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
