PW.4.1—Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, open-source, and other third-party developers for use by the organization’s software.
PW.4
>Control Description
Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, open-source, and other third-party developers for use by the organization’s software.
>Practice: PW.4
Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality
Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.
>Notional Implementation Examples
- 1.Review and evaluate third-party software components in the context of their expected use. If a component is to be used in a substantially different way in the future, perform the review and evaluation again with that new context in mind.
- 2.Determine secure configurations for software components, and make these available (e.g., as configuration-as-code) so developers can readily use the configurations.
- 3.Obtain provenance information (e.g., SBOM, source composition analysis, binary software composition analysis) for each software component, and analyze that information to better assess the risk that the component may introduce.
- 4.Establish one or more software repositories to host sanctioned and vetted open-source components.
- 5.Maintain a list of organization-approved commercial software components and component versions along with their provenance data.
- 6.Designate which components must be included in software to be developed.
- 7.Implement processes to update deployed software components to newer versions, and retain older versions of software components until all transitions from those versions have been completed successfully.
- 8.If the integrity or provenance of acquired binaries cannot be confirmed, build binaries from source code after verifying the source code’s integrity and provenance.
>Cross-Framework References
Mappings to related frameworks and standards from NIST SP 800-218
BSA FSS
SM.2
BSIMM
SFD2.1
SFD3.2
SR2.4
SR3.1
SE3.6
CNCF SSCP
Securing Materials—Verification
EO 14028
4e(iii)
4e(vi)
4e(ix)
4e(x)
IDA SOAR
19
IEC 62443
SM-9
SM-10
Microsoft SDL
6
NIST CSF
OWASP ASVS
1.1.6
OWASP SAMM
SA1-A
OWASP SCVS
4
SAFECode SIC
Vendor Sourcing Integrity Controls
SAFECode TPC
MAINTAIN
SP 800-161
SA-4
SA-5
SA-8(3)
SA-10(6)
SR-3
SR-4
SP 800-181 (NICE)
K0039
Ask AI
Configure your API key to use AI features.