NIST, the National Institute of Standards and Technology, released long-awaited guidance on secure software development practices on Friday, formalizing guidance that asks firms selling software to the government to implement a software bill of materials (SBOM) and test for threats in compiled software binaries.
The new guidelines were part of a trove of new guidelines that NIST published late last week, meeting a deadline first laid out in President Biden’s Cyber Executive Order in May 2021. But the published documents still leave questions unanswered, including about who gets to attest to the security of software purchased by government agencies, and the status of code developed by the government, itself.
[ Read White Paper: Going Beyond the SBOM: Bring Control to Third-Party Software Risk with SAFE ]
What happened?
On Friday, NIST published Version 1.1, of Secure Software Development Framework (SSDF): Recommendations for Mitigating the Risk of Software Vulnerabilities (SP 800-218). The document meets one of the requirements of President Biden’s May Cyber Executive Order (EO 14028). It is the official release of guidance that was first published, in draft form, in April, 2020.
That Executive Order declared that the security of software used by the Federal Government is “vital to the Federal Government’s ability to perform its critical functions.” The EO further cited a “pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended.”
It contained 10 subsections that laid out actions or outcomes for software producers. The newly released document matches up those requirements with the content of the existing SSDF document, making clear how requirements articulated in the EO map to existing guidance from NIST.
New guidelines for software producers
The new guidance was one of a quintet of publications released last week to meet deadlines imposed by the Executive Order. In addition to the 800-218 document, those include guidance on cybersecurity labeling of Internet of Things products and consumer software. Also included: a FAQ summarizing NIST’s software supply chain security guidance in accordance with EO 14028.
When implemented, the new NIST guidance will boost software supply chain security requirements at firms that sell software used by government agencies. That’s because SP 800-218 includes a number of requirements focused on spotting threats in the software development process.
Among other things, SP 800-218 asks makers of commercial off-the-shelf (COTS) and government off-the-shelf (GOTS) software to:
Collect, maintain, and share provenance data for all components and other dependencies of each software release (e.g., in a Software Bill of Materials [SBOM]).
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.
Check code for backdoors and other malicious content
Other requirements articulated in the Executive Order and incorporated into the document require software producers to attest their conformity with secure software development practices and also to attest to the security of any open source software they use.
The goal of the new framework is both to stem the flow of vulnerabilities in software used by the federal government, but also to guard against SolarWinds-style software supply chain compromises, according to Tomislav Peričin, the Chief Software Architect at ReversingLabs. That’s why the SSDF document delineates between analyzing source code and compiled binaries - and calls on software producers to do both.
SBOM guidance still a work in progress
As for the language about Software Bill of Materials (SBOM), the newly published guidelines cite previously published and draft guidance on software supply chain security, including NIST Special Publication 800-161 Rev 1 (Draft), an update to a NIST document that was last updated in November, 2021.
Software bills of material created in compliance with the NIST guidelines must feature “minimum elements” for SBOMs described by NTIA. Those include using data fields that document baseline information about each component that should be tracked. These include Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp.
The SBOMs must also support automation, including automated generation of SBOMs and use of machine-readable data formats that allow SBOM generation and implementation to scale across the software ecosystem. Support for existing SBOM data formats like SPDX, CycloneDX, and SWID tags is encouraged.
Finally, organizations are expected to formulate policies to support deployment of SBOMs, including the frequency of SBOM creation; SBOM depth; addressing “known unknowns;” distribution and delivery; access control; and accommodating mistakes.
Draft language in SP 800-161 provides further definition, requiring Federal Agencies and Departments to “ensure that comprehensive and current SBOMs are available for all classes of software including purchased software, open source software, and in-house software, by requiring sub-tier software suppliers to produce, maintain, and provide SBOMs.”
More scrutiny for compiled code
Some of the more interesting language in the new SSDF document concerns calls to assess not only development practices and human readable code for vulnerabilities, but also compiled executables.
Specifically, the guidance calls on software producers to “test executable code to identify vulnerabilities and verify compliance with security requirements.” Producers are asked to “help identify vulnerabilities” in executables such as binaries, directly executed bytecode and source code. “so that they can be corrected before the software is released in order to prevent exploitation.”
This is fertile territory for software producers and security firms alike. As we noted in our analysis of the SolarWinds Sunburst attack, adversaries who can compromise development and build environments and weave malicious code directly into legitimate code stand a good chance of avoiding detection. With the Sunburst attack on SolarWinds, for example, ReversingLabs was able to detect the compromise by pinpointing behavioral differences (or “static behavioral indicators”) between compiled software versions of SolarWinds Orion software - one legitimate, the other malicious.
The new NIST SSDF guidelines would seem to call for something akin to that ability, with software producers charged with analyzing software binaries for threats before deploying that software to government environments.
Attestation at issue
Of course, the high bar that the EO and the NIST guidelines set for software security raises the thorny question of who (or what) gets to verify that security. And that is an area of some debate, with NIST backing so-called “first-party attestation” of conformity with SSDF and for meeting the EO 14028 requirements. In other words, government buyers of software are urged to “take their word for it” when software producers say they’ve met the requirements of the SSDF and other guidance.
That’s not to say that ‘first-party attestation” is recommended in every case. NIST allows that “the type and rigor of the required methods should be commensurate to the criticality of the service or product being acquired and the corresponding assurance requirements,” creating an opening for higher levels of assurance for mission critical software. Certifications, site visits or third party assessment are all viable means of obtaining this.
First party attestation may be acceptable to start, as software producers are coming to terms with implementing the secure software development framework, software bills of materials (SBOMs) and so on, Peričin said. However, given the complexity of supply chain threats evidenced by SolarStorm and log4j, ReversingLabs believes that an assessment broker is absolutely needed to assess compliance. That’s especially true as the complexity of SBOMs and supply chain assessments increases.
Those could be a company or a free, or open source project through which both the software producer and the software consumer can obtain an accurate and identical software bill of materials (SBOM) for the software in question. Such a mechanism is the only way the federal government can maintain trust and transparency with the software producers who sell to it.
On scope: do as I say, not as I do
The final observation about the NIST guidelines concerns the so-called “scope” of the guidance. That is: which entities the guidance applies to.
You could be forgiven for thinking that a Secure Software Development Framework for federal agencies published by NIST would apply to software developed within federal agencies (of which there is a lot). But in this case, you would be wrong.
As NIST indicates in its newly released FAQ, federal development shops are distinctly “out of scope” for the SSDF. Rather, the scope of the guidance is limited to “federal agency procurement of software.” So too “open-source software freely and directly obtained by federal agencies.” Open-source software that is bundled, integrated, or otherwise used by an outside software producer and then sold for use by a federal agency is, of course, in scope.
Let’s point out the obvious: this is a striking example of the Federal Government saying to software producers that they should “do as I say, but not as I do.” It also sets a risky path forward for federal agencies. Namely: applications developed by federal agencies will be held to a much lower standard than software purchased from outsiders.
Given the massive scale of federal IT environments and the tight integration between internally developed and third party applications, it's hard to see how the arbitrary line drawn here will do much to improve the overall security posture of federal IT environments.
However, that respite may not last forever. “I think this is more about the lack of time between the Executive Order and having to commit to (secure software development),” said Peričin.“I foresee that, in the long term, it will be applied…even if the software is being produced by the government itself. It’s just a matter of time.”
