5 Federal Software Supply Chain Requirements You Should Be Aware Of
If you’ve been watching the software supply chain security space evolve, you likely know that a lot of the momentum and effort is coming out of the U.S. Federal government. This may seem surprising at first, but it shouldn’t be, when you account for the fact that the Federal government is one of the single largest procurers of technology and software in the world.
Couple that with the fact that multiple Federal agencies have been impacted by software supply chain attacks in the last several years, either impacting proprietary software vendors or widely popular OSS components and it is clear why they should care.
Lastly, they of course have a responsibility to be a force for good within the increasingly digital society that we all live in. The software supply chain publications and requirements in the Federal space have been evolving rather quickly, and even if you don’t work in the public sector (or even the U.S.), it’s worth being aware of some key requirements and what they entail. In this article we cover four recent requirements:
- Cybersecurity Executive Order (EO)
- OMB 22-18
- OMB 23-16
- Secure Software Development Framework (SSDF)
- FDA “Ensuring Cybersecurity of Medical Devices” Section 524B
Cybersecurity Executive Order (EO)
While far from the only Federal publication related to software supply chain security, inarguably one of the most notable and well recognized in the Executive Order (EO) 14028 “Improving the Nation’s Cybersecurity”, often referred to as the “Cybersecurity EO”.
The Cybersecurity EO had a broad scope, covering areas such as cyber incidents and threat sharing, zero trust, the establishment of the Cybersecurity Safety Review Board (CSRB) and, you guessed it, an entire section, Section 4, dedicated to software supply chain security.
Section 4 “Enhancing Software Supply Chain Security” discussed the critical role software plays in enabling the Federal government to perform its critical functions and tasked various Federal agencies/entities with producing subsequent guidance, requirements and publications, some of which we will discuss below.
This included producing guidance on activities such as secure software development, enhancing software supply chain security and also defining and requiring Federal agencies to identify “critical” software. It also set the tone for forthcoming requirements we will discuss below, such as software suppliers selling to the Federal government to comply with and attest to specific security requirements.
OMB 22-18
The Office of Management and Budget (OMB) was among those tasked with helping implement aspects of the cybersecurity EO, including section 4. In September 2022, OMB released M-22-18, or in non-governmental memo speak, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices”.
This memo helps begin the push for Federal agencies to ensure software suppliers they use and work with comply with NIST guidance (such as the SSDF) when being used on agency’s information systems or impacting agency data. It was applicable to software developers after the date of the memorandum, as well as existing software that was modified by major version changes after the date of the memorandum’s publication. It however didn’t apply to agency-developed software.
At a high-level, the memo is seeking to ensure software suppliers that Federal agencies use are following a risk-based approach for secure software development and that the suppliers are willing to attest, in written form, to following the Government-specified practices.
The attestations are primarily required to be self-attestations but does allow for the agencies to make use of a 3rd party assessment organization if desired or deemed necessary. If the software producer isn’t able to comply with the defined practices, they will have to identify any deficiencies and draft what is known as a “Plans of Actions and Milestones (POAM)’s” on how risk is mitigated and when deficiencies will be addressed.
In addition to the secure software development self-attestation requirements, the memo also stated that agencies may be able to require artifacts such as a Software Bill of Materials (SBOM) as needed. Additionally, the agency may require additional artifacts such as those that can demonstrate integrity of the source code and that the supplier participates in a Vulnerability Disclosure Program (VDP).
OMB 23-16
Building on the momentum of OMB 22-18, OMB released another memo 23-16 in June of 2023. It served as an update to the previously discussed 22-18 above. The memo reaffirms the government's emphasis on the need for their suppliers to use secure software development practices and it also extended the timeline for agencies to begin collecting the attestations we discussed above. It pushed the timeline for the collection of the self-attestation letters to three months after the final release of the “common form” aka self-attestation form which was released by the Cybersecurity and Infrastructure Security Agency (CISA) and approved by OMB. A draft of the form can be reviewed here.
Secure Software Development Framework (SSDF)
The two previously discussed memos have a big emphasis on self-attestations of suppliers selling to the Federal government as well as Federal agencies requirements software vendors to align with secure software development best practices. One is likely wondering where these secure software development best practices are derived from, and that’s where NIST’s Secure Software Development Framework (SSDF) comes into play.
NIST’s revision of SSDF was directly tied to the Cyber EO we discussed earlier in this article and it calls out the reality that few SDLC models specifically focus on software security. To produce the latest SSDF, NIST held a workshop in June 2021 and also received over 150 position papers with recommendations, as well as worked closely with leading software organizations.
Everyone in cybersecurity is familiar with the pain of yet another framework (YAF), luckily in this case, NIST drew from existing industry guidance and resources such as the Building Security In Maturity Model (BSIMM) and OWASP’s Software Assurance Maturity Model (SAMM) among many others.
SSDF takes those various recognized and proven software security practices and organizes them into four groups, such as: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). This recognizes the cyclical nature of secure software development and the various phases where it makes the most sense to integrate the various practices.
Practices include activities such as identifying and documenting security requirements, creating applicable roles/responsibilities, specifying the tools and types of tools that must be used in the toolchain, tracking vulnerabilities throughout the SDLC and securely storing source code, among many others.
FDA Ensuring Cybersecurity of Medical Devices/Section 524B
Another key emerging requirement that has gotten significant attention is the recently added Section 524B of the Federal Food, Drug and Cosmetic Act (FD&C Act), which was included as part of a consolidated appropriations act in 2023 and focuses on ensuring cybersecurity of medical devices.
Most notably, the new requirements specifically deal with premarket submissions and the quality system considerations for cybersecurity in medical devices, which can include anything from insulin pumps to smart watches. As part of documenting the security risk management activities for a medical device system, the guidance calls out the need for a Software Bill of Materials (SBOM), in addition to other activities such as vulnerability assessments and threat modeling. The guidance emphasizes the value of a robust SBOM that includes first party and third-party components, such as OSS. It is recommended by the FDA that premarket submissions include SBOM documentation and is required for what they refer to as “cybersecurity devices”.
More broadly the guidance also recognizes that OSS components are often incorporated into medical devices and should be considered as part of the overall medical device system risk management process and documentation. This means medical device manufacturers should have governance over the OSS components they include in their devices and also through processes for ensuring they’re using secure OSS components from the onset of the device development and distribution.
Conclusion
While on the surface it can seem intimidating to follow the emerging Federal software supply chain requirements, when broken down, they represent a coherent and maturing approach to how the Federal government procures software. It also represents the Federal government's commitment to ensuring they are using secure software to power use cases such as critical citizen services, defense missions and everything in between.
Lastly, it represents the Federal government's attempts to use their massive purchasing power to drive systemic changes in an increasingly complex and brittle software ecosystem and society that is being relentlessly targeted by malicious actors, preying on the complexity and interdependencies.
At first, it may seem like you shouldn’t be concerned with these emerging requirements but that would be shortsighted. The Federal government represents a massive buyer in the software ecosystem, spending tens of billions a year on IT and software and there is a tendency for their requirements to have a ripple effect into the broader security and compliance ecosystem. Furthermore, even if the Federal government isn’t your direct consumer/customer, it is highly likely that you have customers who are working with the Federal government and it is very likely that these emerging requirements will in some shape or form have a downstream impact across the software supply chain, which is exactly what the Government is hoping for, to drive a more secure and resilient software landscape.