The National Institute of Standards and Technology (NIST) published long-awaited secure software development practices guidance on Friday, formalizing guidance that mandates SBOM implementation and threat testing for built software binaries for businesses selling software to the government.
In order to fulfill a May 2021 deadline outlined in President Biden’s Cyber Executive Order, NIST late last week presented a flurry of new recommendations, some of which included the new standards.
The records were made public, but many questions remain unresolved, including who is authorized to guarantee the security of software purchased by government organizations and the whereabouts of government-written code.
New standards for software development
One of the five documents created last week to meet the requirements of the Executive Order was the new guideline.
In addition to the 800-218 document, these also include recommendations for the cybersecurity labeling of consumer software and Internet of Things products.
There is also a FAQ that outlines the NIST security recommendations for the software supply chain in accordance with EO 14028.
When fully implemented, the new NIST recommendations will make software companies that sell to federal agencies more secure in their software supply chains. This is because SP 800-218 contains a number of specifications intended to find threats during the software development process.
Manufacturers of commercial off-the-shelf (COTS) and government off-the-shelf (GOTS) software are required to, among other things, comply with SP 800-218.
- Gather, manage, and share provenance information for all software release dependencies and components (e.g., in a Software Bill of Materials [SBOM]).
- To more accurately estimate the risk that a component may introduce, obtain and analyse provenance data for every software component (e.g., SBOM, source composition analysis, binary software composition analysis).
- Look for backdoors and other harmful code in the source code.
Software developers must certify that they adhere to safe software development practices and that any open source software they use is secure, according to additional standards established in the Executive Order and integrated into the document.
The goal of the new framework, according to Tomislav Periin, Chief Software Architect at ReversingLabs, is to both halt the flow of vulnerabilities in software used by the federal government and to safeguard against attacks similar to those in the SolarWinds software supply chain.
The SSDF recommendation makes a distinction between examining built binaries and source code and urges software engineers to do both.
The SBOM guidelines are currently being developed
The recently released guidelines make reference to previously released and draft software supply chain security guidance, including NIST Special Book 800-161 Rev 1 (Draft), an update to a NIST publication that was most recently revised in November 2021.
The “minimum elements” for SBOMs as outlined by NTIA must be present in software bills of material created in conformity with NIST guidelines.
Data fields that offer background details on each component to be tracked are among them. There are several of them, including Supplier, Component Name, Component Version, Other Unique Identifiers, Dependency Relationship, Author of sbom nist Data, and Timestamp.
Additionally, SBOMs must facilitate automation, including automated SBOM production and the use of machine-readable data formats that permit widespread adoption of SBOMs throughout the software ecosystem.
Support for pre-existing SBOM data formats like SPDX, CycloneDX, and SWID tags is strongly recommended.
Businesses must also create rules to enable SBOM deployment, including those governing how frequently SBOMs are created, how deep they should be, how to deal with “known unknowns,” how to distribute products, how to manage access, and how tolerable errors should be.
Additional definition is added in the draft language of SP 800-161, which mandates that Federal Agencies and Departments “ensure 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.”
Further testing for compiled code
Some of the more curious language in the new SSDF document refers to demands to examine generated executables as well as development methodologies and human-readable code for vulnerabilities.
“Test executable code to discover vulnerabilities and ensure compliance with security requirements,” the guidance specifically directs software developers to do.
In order to fix any vulnerabilities in executables such binaries, directly run bytecode, and source code “before the application is deployed to prevent exploitation,” producers are urged to “help in their identification.”
Both software developers and security companies can profit greatly from this. In our analysis of the SolarWinds Sunburst assault, we noted that attackers who can infiltrate build and development environments and intertwine harmful code with genuine code had a good chance of avoiding detection.
By identifying behavioral differences (or “static behavioral indicators”) between two compiled software versions of SolarWinds Orion software, one of which was malicious, ReversingLabs was able to identify the Sunburst attack on SolarWinds.
Software developers are tasked with evaluating software binaries for vulnerabilities before to deploying them to government systems, according to the new NIST SSDF standards, which appear to demand for something akin to that capacity.
The attestation debate
It naturally begs the question of who (or what) gets to certify that security given the high standard established by the EO and NIST guidelines for software security.
NIST supports so-called “first-party attestation” of SSDF compliance and EO 14028 compliance, which is a matter of controversy.
In other words, when software providers assert that they have complied with the SSDF and other requirements, government buyers of software are recommended to “take their word for it.”
To say that “first-party attestation” is always a good idea is not to make the claim that it is.
The National Institute of Standards and Technology (NIST) permits higher levels of assurance for mission-critical software by stating 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.”
Options include third-party assessments, site inspections, and certifications.
First-party attestation may be acceptable at first, according to Periin, when software developers struggle to implement the secure software development framework, software bills of materials (SBOMs), and other standards.
ReversingLabs thinks that compliance must be evaluated by an assessment broker, despite the complexity of supply chain issues shown by SolarStorm and log4j. This is especially true as supply chain analysis and SBOMs get increasingly complex.
These could be an organization, a free software project, or an open source initiative that enables both the software developer and the software user to obtain an exact and identical software bill of materials (SBOM) for the software under discussion.
The only way the federal government can maintain trust and openness with the software vendors who supply it is through such a framework.
Do as I say, not as I do in terms of scope
The “scope” of the advice is the third point to be made in relation to the NIST recommendations. Which entities are protected by the guideline, that is.
You may be excused for thinking that software developed by federal agencies would be covered by the Secure Software Development Framework for Government Agencies released by NIST (of which there is a lot). But in this case, you’d be mistaken.
