PR.PS-06 says secure software development practices are integrated, and their performance is monitored throughout the software development life cycle. If you write software, this is your outcome. It asks for security checks as part of normal work, plus numbers that show whether they work.
CSF is voluntary guidance. There is no CSF certification, and no one should describe a product as "NIST compliant" on the strength of this outcome.
What good looks like
Source code, build systems, and artifacts are protected from tampering and unauthorized access. Releases ship with minimal known vulnerabilities. Software in production is maintained, and it is securely retired when no longer needed. Teams can say how many issues they found and fixed, and how long it took.
NIST's examples point to three themes: protect all components of in house software, secure what you produce, and maintain production software until it is safely disposed of.
How to implement it
- Protect the pipeline. Require code review, protect main branches, use short lived credentials in CI, and restrict who can change build definitions.
- Add automated checks to every pull request: secret scanning, static analysis, and dependency scanning.
- Generate a software bill of materials for each release so you know what shipped.
- Use reachability analysis to separate vulnerabilities in code paths your application calls from those that sit unused. It keeps the fix queue focused.
- Gate releases on agreed rules. For example, block a build with a reachable critical issue unless an owner signs an exception.
- Sign build artifacts and keep a record of where each came from.
- Track metrics: open findings by severity, median time to fix, percent of releases passing gates, and exceptions granted.
- Retire services deliberately. Remove access, data, and infrastructure when decommissioning.
Try it yourself
Click through it at your own pace, or open it full screen.
You can also scan a dependency manifest for free in your browser at https://gold.safeguard.sh/scan to see what a typical pre merge check reports.
A worked example
A 25 person product team ships weekly. Before adopting these practices, scanning happened once a quarter before an audit. Now every pull request runs secret scanning, static analysis, and a dependency check. Findings appear in the review itself. The main branch is protected, and builds run with short lived credentials. Each release produces a software bill of materials and a signed artifact.
After three months, the team reports four numbers to leadership: open critical and high findings, median days to fix, percentage of repositories with scanning enabled, and number of release exceptions. All four have trended in the right direction, and the numbers double as evidence for customer security reviews.
Protecting the pipeline itself
Attackers increasingly target build systems and dependencies instead of the application. Treat the pipeline as production. Limit who can edit workflows. Pin third party actions and plugins to specific versions. Keep secrets out of repositories and rotate any that leak. Use separate credentials for each environment, and make production deploys require review.
Using reachability to stay focused
Dependency scanners can produce hundreds of findings, most of them in code your application never calls. Reachability analysis identifies the findings whose vulnerable code is actually invoked, so engineers can fix those first and schedule the rest. A free in browser dependency scan at https://gold.safeguard.sh/scan is a quick way to see what your manifest contains today.
Measure, then improve
The outcome asks for performance to be monitored, so choose a few honest metrics and review them monthly. A metric that never changes, or that nobody discusses, is a signal to adjust the practice or retire the measure.
Where to start if you have nothing
Week one: turn on branch protection and required review for your main repositories, and enable secret scanning. Week two: add dependency scanning to pull requests and fix the findings that are reachable and critical. Week three: generate a software bill of materials in your release pipeline and store it with each build. Week four: write a one page secure development standard that describes what you now do, and set the first four metrics.
That sequence gives you real protection and real evidence within a month, without a large program.
Third party and open source code
Most of what you ship was written by someone else. Choose dependencies with care: check maintenance activity, license, and known issues before adding them. Keep the list short. Subscribe to advisories for the ones you use. Update regularly in small steps instead of rare large jumps, because small upgrades are easier to test and review.
Retiring software safely
The outcome ends with disposal for a reason. Old services accumulate credentials, data, and open ports. When you decommission one, remove its access keys, delete or archive its data under your retention rules, shut down the infrastructure, and update the inventory. Record the date and the person who confirmed it.
Evidence to collect
- Secure development policy or standard.
- Branch protection and CI settings.
- Sample pull requests showing automated scan results and review.
- SBOMs for recent releases.
- A metrics report across several months.
- Exception records with owner and expiry.
- Decommissioning records for retired services.
Common gaps
Scanning that runs but nobody reads. No metrics, so improvement is a guess. Build secrets with long lived access. Gates that are advisory only. Old services left running because no one owns shutdown.
Quick check
We are a small team. Do we need a full secure development program?
You need the basics applied consistently: reviewed code, protected branches, automated scanning, and a few tracked numbers. Scale the effort to the risk.
What counts as monitoring performance?
Any recurring measurement tied to the practice, such as time to fix critical findings, scan coverage across repositories, or the share of releases that pass gates.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), PR.PS-06 and its implementation examples.
