More than a year after President Biden signed Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity, standards and compliance expectations are coming into sharper focus.
The National Institute of Standards and Technology (NIST), the Office of Budget and Management (OMB), and other U.S. government bodies have released a series of best practice guidance and directives that will accelerate software supply chain visibility and security. While the standards are directed at federal departments and contractors, it is expected that they will also have broader implications on critical infrastructure sectors.
In addition, persistent threat activity and events serve as a reminder for software security vigilance.
- Lapsus$, a Latin American–based hacker group, breached leading technology vendors Samsung and NVIDIA, exposing source code, product schematics, as well as code-signing certificates. Threat actors can use this information to plan future attacks.
- Widespread exploitation of the Apache Log4J vulnerability enabled remote code execution. The software library is broadly used in consumer and enterprise services, and the vulnerability reinforced the risk of open source code use without adequate software supply chain visibility.
- While not a security incident, Peter Zaitko’s Twitter whistleblower complaint underscores the security risks of inadequate software development life cycle (SDLC) security and access permission sprawl. The complaint detailed uneven implementation of secure coding practices and an absence of privileged access management in the Twitter production environment.
EO 14028: Raising the software security bar for federal vendors and beyond
The executive order addresses a range of cybersecurity expectations including breach notification, zero trust, and enhanced network visibility, but software supply chain security emerges as an overwhelming priority. Key directives include developing new software security standards and best practices, maturing the software Bill of Materials (SBOM), formalizing software code testing expectations, and developing standards for Internet of Things (IoT) cybersecurity. Several agencies have generated guidance and directives to satisfy EO expectations.
- NIST’s Definition of Critical Software establishes criteria and attributes for software deemed critical and security measures for “EO-critical software” use
- NIST Guidelines on Minimum Standards for Developer Verification of Software establishes key testing and validation measures
- The Department of Commerce’s Minimum Elements for an SBOM
Most recently, and relevant to the implementation of the EO’s principles, OMB issued two memos that will drive adoption of NIST’s Secure Software Development Framework (SSDF). In March, OMB directed U.S. government agencies to adopt the NIST SSDF for any vendors supplying software products, thus formalizing the framework as the authoritative reference for best practices and compliance. Last month, the agency released a memo on enhancing the security of the software supply chain through secure software development practices. In the memo, OMB articulates the steps required for U.S. government vendors to implement EO guidelines including attestation of secure software development practices and tasks. While the memo leans into self-attestation leveraging a yet-to-be defined standardized form, it also indicates that self-attestation is the minimum level required. Based on software criticality, agencies may make risk-based determinations that would necessitate a third-party assessment. Given this ambiguity, U.S. government vendors should consider steps for both self-attestation and potential third-party support.
The four core principles of the SSDF
The NIST SSDF (SP 800-218) serves as the focal point for capturing and operationalizing U.S. government software security expectations. In February, SP 800-218 replaced the original 2020 NIST cybersecurity white paper, formalizing the SSDF as the government’s seminal software security organizing construct. The document describes a set of foundational practices for secure software development and is organized into four core principles.
- Prepare the organization: People, process, and technology should be adequately prepared to perform and sustain secure software development.
- Protect the software: Organizations should protect all components of their software from tampering and unauthorized access.
- Produce well-secured software: Organizations should produce well-secured software with minimal vulnerabilities.
- Respond to vulnerabilities: Organizations should identify vulnerabilities and respond appropriately.
Within each principle are a set of corresponding practices, tasks, and implementation examples. In addition, the SSDF aligns to previously published best practice frameworks (e.g., BSIMM, OWASP, etc.) in a references section, thus acknowledging the good work that’s already been achieved in this area.
The SSDF also provides a common language and a set of high-level practices, similar to the approach taken by the NIST Cybersecurity Framework. But the flexibility and opportunity for user customization in the SSDF could lead to interpretation challenges and ambiguity. For example, the SSDF illustrates a set of “notional implementation examples” that can satisfy each defined task, but this list is not exhaustive and can be open to interpretation. As an organizing framework, that flexibility is welcome but as a compliance regime, it could create interpretation and attestation challenges.
New guidance helps practitioners align to SSDF
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.
Securing the supply chain begins with secure software development
Although the government will not be finalizing SSDF requirements for several months, organizations should begin positioning themselves for SSDF program alignment given the threat environment and eminent compliance pressures. Particularly for providers that might fall into the “critical software” category, an initial SSDF assessment can be instructive for prioritizing security initiatives in advance of reporting deadlines. Even companies that don’t sell to the U.S. government should consider aligning to the SSDF due to heightened software security expectations for commercial buyers that might include SSDF guidelines in their procurement rules. Practitioners should also familiarize themselves with ESF guidance as it can provide practical implementation guidance interoperable with the SSDF.
Continue Reading
A new identity for the Synopsys Software Integrity Group
Aug 12, 2024 / 2 min read
CyRC Vulnerability Advisory: CVE-2024-5184s prompt injection in EmailGPT service
Jun 04, 2024 / 1 min read