SSDF PW.4.2 applies when you build a shared component in-house because no third-party option meets a common internal need. Then you must treat it like any other product: follow your secure development process, host it in a repository, define secure configurations and update it. Build when buying clearly fails.
What PW.4.2 says
PW.4.2 reads: create and maintain well-secured software components in-house following SDLC processes to meet common internal software development needs that cannot be better met by third-party software components. The examples include following your own secure development practices, publishing secure configurations as configuration-as-code, maintaining one or more repositories for these components and keeping older versions until all teams have moved.
Decision guide
Ask these questions in order.
| Question | If yes | If no |
|---|---|---|
| Does a maintained third-party component meet the need? | Use it under PW.4.1 | Continue |
| Is the need shared by several teams? | Candidate for an in-house shared component | Keep it inside one project |
| Is it security sensitive, such as auth or logging? | PW.1.3 favors standardized services over proprietary ones | Normal review applies |
| Can you staff ongoing maintenance? | Proceed | Reconsider |
PW.1.3 is relevant here. It says to build in support for standardized security features and services, such as existing log management and identity systems, instead of creating proprietary implementations. Writing your own login or logging component is the classic case where that guidance points the other way.
What maintenance means
A shared component has users, and those users need patches. Plan for:
- A named owner and a backup
- A release process with the same checks as your products
- An SBOM for the component, since it has its own dependencies
- A vulnerability intake path for the teams using it
- A deprecation notice period
Evidence
- The decision record explaining why a third-party option did not fit
- The repository and its access settings
- The secure configuration published for consumers
- Release and scan records
- A list of consuming teams and their versions
Common mistakes
Internal components often escape the scrutiny applied to products. They get no SBOM, no vulnerability monitoring and no owner after the author changes teams. A quarterly check of "who owns each internal component" prevents most of this.
A worked example
Imagine three teams each writing their own retry and logging wrapper. Nothing third-party fits your internal conventions, so you decide to build one shared module. Under PW.4.2 you give it an owner, a repository, a release process with the usual scans and a published configuration. You also tell the three teams its version policy and how to report a defect. Six months later, a vulnerability in one of its dependencies is fixed once, in one place, and each team picks up the update.
Quick check
Does PW.4.2 apply to every internal library?
It applies to components meant for common internal needs. A one-off helper inside a single service is covered by your normal code practices.
Should in-house components be in the SBOM?
Yes, if they ship in your software. They are components like any other and may carry their own dependencies.
Safeguard's SBOM and dependency scanning can include internal packages in your inventory. Try the free scan at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
