The Biden Administration’s Executive Order 14028 (EO) for Improving the Nation’s Cybersecurity, released in May of 2021, laid out new guidelines for securing software used by federal agencies. Among other things, it set new guidelines for software supply chain security, and empowered the Office of Management and Budget (OMB) to require agencies to comply with those guidelines.
More recently, on September 14, 2022, that guidance took form with the publication of the OMB’s memorandum M-22-18 requiring federal agencies to comply with NIST guidance on software supply chain security, including compliance with NIST Special Publication 800-218 on developing a secure software development framework and subsequent NIST guidance on software supply chain security.
Here's a look at the key elements of the EO and related software supply chain security guidance from the federal government.
[ Special Report: The State of Software Supply Chain Security 2022-23 ]
Timeline: The clock is ticking on federal compliance
The memo also set out a timeline for federal agencies to communicate new software security requirements to their vendors, and for software publishers that sell to federal agencies to self-attest to the security of their wares. That deadline is 270 days from the release of the OMB memorandum for vendors who sell “critical” software and services to federal agencies. Vendors selling non-critical software have one year to comply.
SBOMs: Your software package is in the hot seat
The mandate opened the door to federal agencies requiring the creation of Software Bills of Materials (SBOMs) that they can use to identify, track and monitor individual components within larger applications and services. The new White House memo does not require software publishers to use — or federal agencies to require — the creation of an SBOM to validate their attestation. However, the language in the memo makes clear that an SBOM “may be required” by an agency as part of solicitation requirements, especially for software deemed as “critical.”
So-called "known unknowns" should also be included for completeness. The Biden memo echoes that guidance as well, instructing agencies to direct publishers to identify practices to which they cannot attest, along with practices they have in place to mitigate those risks.
SBOMs aside, other forms of attestation may also be required, including output from source code analysis and vulnerability scanning tools, in addition to or in lieu of an SBOM, as needed. Publishers may also need to show that they participate in a vulnerability disclosure program.
Enduring Security Framework: Guidelines for securing software development environments
The NSA, CISA and ODNI released The Enduring Security Framework (ESF), a new set of practice guidelines, in September, 2022. The ESF provides a roadmap for software vendors that do business with the federal government on how to implement a secure software development framework (SSDF) as envisioned by the EO.
The ESF practice guidelines heavily reference other secure development frameworks, including NIST’s Secure Software Development Framework (SSDF), the OWASP Software Component Verification Standard (SCVS) and Supply Chain Levels for Software Artifacts (SLSA). They make clear that federal contractors and agencies need to develop proficiency in areas that they have not prioritized until now.
For example, the guidelines recommend that development organizations use binary scanning and software composition analysis (SCA) tools that can detect unknown files and open source components, and their associated security weaknesses, hiding within compiled binary packages.
Binary scanning can reveal possible threats such as backdoors, out of scope or suspicious functionality that a third-party module may bring with it. Organizations can then use that information when deciding whether to release software to production or if they want to use the module at all.
Likewise, the ESF includes practice guidelines devoted to developing secure code, including recommendations for development organizations to address developer-centric threats. Those include commonplace “ease of development” features like temporary back doors that find their way into production code as well as the risks posed by malicious insiders, rogue developers and compromised development systems.
For example, the guidelines call out the risk posed by integrated development environment (IDE) plugins and scripts — a huge attack surface that goes unchecked in most development organizations.
To address these risks, the ESF recommends that development organizations perform automated static and dynamic testing of newly checked in code to look for vulnerabilities. It also urges them to map newly created code back to clearly identified features, and to implement authentication for code check-ins to guard against compromised development systems.
Critical code — such as that requiring elevated privileges, accessing sensitive resources or using or implementing cryptographic functions — should be subject to mandatory reviews and given a high priority, the guidelines state.
ESF recommendations for securing executable code
Section 2.3.5 pf the Enduring Security Framework provides recommendations development organizations can follow to secure executable code against exploits. These include:
- Develop a set of comprehensive security requirements that includes compliance regulations.
- Create threat models for all critical software components and elements of your build pipeline, including source code repositories, build systems, and so on.
- Develop test plans to assess each requirement providing good “code coverage.”
- Provide adequate staffing and testing resources to execute test plans
- Perform security testing of each software component in line with NIST SSDF guidelines, including:
- Static and dynamic application security testing of all source code
- Fuzzing of all software components to verify expected behaviors
- Periodic penetration testing on a regular basis
- Documentation of the results of all security tests
