To help firms achieve compliance with the requirements laid out in the executive order, the Software Supply Chain Working Panel of the Enduring Security Framework (ESF), a cross-sector working group that address threats and risks to the security and stability of U.S. national security systems, released guidance called Securing the Software Supply Chain. This guidance is helpful to companies that supply, develop, or acquire software for the federal government and addresses emerging requirements for critical infrastructure vendors and buyers. It illustrates approaches that assist developers with acquiring dependencies, integrating and building secure software, and distributing software while maintaining and asserting its integrity.
The ESF guidance offers developers, suppliers, and customers practical measures that can map directly to higher-level NIST SSDF principles. The following examples illustrate how ESF guidance can complement SSDF alignment efforts and address heightened software security expectations.
Maintaining secure software components
When integrating binaries, developers should run tools that can analyze the software composition of the binaries to find vulnerabilities without the need for supplied source code. When source code is available, such as from open source projects, a static application security testing (SAST) tool could be leveraged as well.
SSDF PW.4.1: Acquire well-secured components (e.g., software libraries, modules, middleware, frameworks) from third parties for use by the organization’s software.
Securing the build environment
Before trusted components are brought into the build environment, developers should ensure that the environment is secured from internal and external threats. The ESF guidance provides information on how to deal with a variety of build time threats, ranging from malicious insider threats, untrained engineers, misconfigured access rights, and build chain exploits. In general, firms should ensure that their build environment is protected from external network activity, configured to log all access, monitors for data leakage, and protects any secrets associated with the build pipeline. In addition to pipeline security, the guidance recommends minimizing software risk by performing all needed activities to prevent, test for, mitigate, and remediate software vulnerabilities while building and integrating developed source code into software packages.
SSDF PS.1.1: Store all forms of code—including source code, executable code, and configuration-as-code—based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.
Detecting and preventing exploits in software packages
Once the software is built in a way that minimizes risk, it must be distributed in a way that detects or prevents malicious tampering. This includes detecting and preventing malicious exploits that could be compiled into the software packages by a compromised build pipeline, or allowing compromised distribution channels to insert malware or backdoors into the software. When securing delivery channels, any software that is uploaded should undergo binary software composition analysis (SCA) to ensure that the package is free from vulnerable components. The binary analysis results should also be compared to the SBOM generated by the developers, and any discrepancies should be investigated.
SSDF PW.6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations.
The ESF guidance concludes with an appendix that allows firms to cross-check its provided scenarios against the SSDF framework to assist with asserting SSDF compliance.