PR.PS-02 says software is maintained, replaced, and removed commensurate with risk. In plain terms: patch on a schedule tied to risk, swap out anything the vendor no longer supports, and uninstall what you do not need. Risk decides the order, so you do not have to fix everything at once.
CSF is voluntary guidance. There is no CSF certification.
What good looks like
You have written patch timeframes by severity, and routine and emergency patching meet them. Container images are rebuilt and redeployed instead of patched in place. End of life operating systems, runtimes, and libraries have a replacement date. Unauthorized or unnecessary software is gone.
Your own application dependencies count too. An outdated library in a production service is software that needs maintaining.
How to implement it
- Keep a software inventory that covers operating systems, services, and application dependencies. Without it you cannot tell what needs patching.
- Write a short patch policy: critical and actively exploited within days, high within weeks, the rest on a regular cycle. NIST's examples tie patching to the timeframes in your vulnerability management plan.
- Automate routine updates for operating systems and base images. Replace container instances with fresh builds.
- Track end of life dates for every runtime and major product. Put the replacement on the roadmap a year ahead.
- Prioritize dependency fixes by whether the vulnerable code is actually reachable in your application. Reachability analysis helps cut the noise so the urgent fixes get done first.
- Remove software nobody uses. Fewer packages means fewer patches.
- Report on patch age monthly and review exceptions.
Try it yourself
You can check a project's dependencies for known issues in your browser at https://gold.safeguard.sh/scan. It is free and takes a manifest or a package name.
Click through it at your own pace, or open it full screen.
A worked example
A security review turns up three problems in one week. A production service runs a language runtime that reached end of support last spring. A web application depends on a library with a newly published vulnerability. An old reporting server nobody uses is still joined to the network and has not been patched in two years.
With the PR.PS-02 habits in place, each has a path. The runtime upgrade has a scheduled date and an owner because the end of life tracker flagged it a year ago. The library issue is checked for reachability: if the vulnerable function is never called, the fix is scheduled with normal priority, and if it is called by an exposed endpoint, it is fixed within the emergency window. The reporting server is removed, which is the best patch of all.
Setting patch timeframes people can meet
A policy that nobody can meet is worse than none. Start with targets you can hit and tighten over time. Many small teams begin with seven days for critical and actively exploited issues, thirty days for high, and ninety for the rest. Measure the percentage of patches landing inside target each month. When the number is low, look for the cause, which is usually missing inventory, fragile deployment, or no owner.
Replace, do not repair
NIST's examples suggest rebuilding container images and deploying new instances rather than patching running ones. The same thinking applies to servers. If you can rebuild from a template in minutes, you avoid patch drift and you know exactly what is running. Treat long lived hand patched machines as a risk to retire.
Removal counts
Every unused package, plugin, and service is something to patch for no benefit. Schedule a yearly cleanup. Remove unauthorized software, unneeded browser extensions, forgotten test services, and dependencies your code no longer imports. Keep a record of what was removed and when.
Metrics that tell the truth
Four numbers show whether this outcome is working. The percentage of systems within patch target. The median age of open critical and high vulnerabilities. The number of end of life components still in production. And the share of dependencies in your applications with a known fix available but not applied. Review them monthly and write one sentence about each trend.
Working with vendors
Not everything can be patched by you. For SaaS and managed services, your job is to know which ones carry your data, watch their security advisories, and confirm they follow their own maintenance commitments. Keep a short list of your critical suppliers and a contact for security notices.
When a patch is not possible
Sometimes a fix would break an important system, or none exists. Record a risk acceptance with a compensating control, such as network isolation, extra monitoring, or a virtual patch at a firewall. Give it an owner and a review date. NIST's wording, commensurate with risk, allows that choice as long as it is deliberate and documented.
Evidence to collect
- The patch policy with timeframes.
- A report of current patch age by system and the share within target.
- End of life tracker with replacement dates.
- Records of emergency patches, including time to deploy.
- Exceptions with owner, reason, and expiry.
- Dependency scan results over time.
Common gaps
No inventory, so unknown systems never get patched. Patch policy with no measurement. End of life software kept alive because migration was never scheduled. Treating application libraries as someone else's problem. Exceptions that never expire.
Quick check
Do we have to patch everything immediately?
No. The outcome says commensurate with risk. Prioritize by severity, exploitability, exposure, and business impact, and document what you defer and why.
Does this include open source libraries we depend on?
Yes. Software in production includes the dependencies your code ships with.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), PR.PS-02 and its implementation examples.
