SSDF PW.5 asks you to follow secure coding practices suited to your languages, and PW.6 asks you to use compilers and build tools with security features and approved configurations. Evidence is a written coding standard, build settings kept as code, and build logs showing the settings were applied.
PW.5: secure coding practices
PW.5.1 says to follow all secure coding practices appropriate to the development languages and environment, to meet the organization's requirements. SP 800-218 version 1.1 gives these examples:
- Validate all inputs, and validate and encode outputs
- Avoid unsafe functions and calls
- Detect and handle errors gracefully
- Provide logging and tracing
- Use linters and formatters to standardize style
- Check for vulnerabilities common to the language and environment
- Let developers review their own code to complement, not replace, review by others
Evidence: the coding standard, linter configuration in the repository, and review records.
PW.6: compilers, interpreters and build tools
PW.6.1 asks for tools that offer features to improve executable security. PW.6.2 asks you to decide which features to use, configure them, and use the approved configuration.
| Example from the document | What to keep |
|---|---|
| Use up to date tool versions | Pinned version in build config |
| Change management for tool updates | Ticket or pull request for each update |
| Warnings that flag poorly secured code | Compiler flags in the repository |
| Clean build, warnings treated as errors | Build log with zero unexplained warnings |
| Dedicated, controlled build environment | Build system description |
| Verify the approved settings are used | A check that fails when settings drift |
| Approved settings as configuration as code | The shared config file itself |
Making the evidence automatic
- Keep build and lint settings in version control.
- Make the pipeline fail when the settings are missing.
- Store build logs with the release record.
- Review the settings once a year or when tools change.
Document the exceptions. A warning marked as a false positive should have a note saying why.
Try it yourself
Open the demo and look at how code scanning reports findings on source. Think of the findings list as a record that PW.5 practices are being checked, not only followed.
Click through it at your own pace, or open it full screen.
Quick check
Which secure coding standard must we use?
PW.5.1 does not name one. It asks you to follow practices appropriate to your languages and environment and to meet your own requirements.
What is a clean build?
An example in PW.6.2: treat all compiler warnings as errors and eliminate them, except those judged false positives or irrelevant.
Where tooling helps
Safeguard offers SBOM and dependency scanning, reachability analysis and policies and gates on pull requests, which can record checks against your standards. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
