Over the past 16 months the federal government has issued a number of directives to enhance the security of its computer systems and the data that resides on those systems. The Executive Order (EO)14028 issued on May 12, 2021 required a number of initiatives to enhance the government’s cybersecurity posture including enhancing the security of the software supply chain. That Executive Order has been reinforced with the issuance of M-22-18 by the Office of Management and Budget on September 14, 2022.
OMB Memorandum M-22-18 focuses on the need for software suppliers to utilize secure software development practices and “requires each Federal agency to comply with the NIST Guidance when using third-party software on the agency’s information systems or otherwise affecting the agency’s
information”. In support of that objective, it also identifies a Software Bill of Materials (SBOM) as an artifact that demonstrates “conformance to secure development practices”. It should be noted that firmware is included within the definition of software and therefore any XIoT device(s) procured by an
agency may need an SBOM as part of the procurement process.
On July 12, 2021 the Department of Commerce issued the minimum elements for an SBOM in order to enhance software security and minimize risks within the supply chain by providing visibility and transparency. This directive highlights the minimum data fields within an SBOM along with the three
common formats for SBOMs. A key part of the process is the identification and naming of the many components and sub-components that make up each software package. Availability of an SBOM allows both the producers and consumers of software to better understand the risks inherent in the product
and more rapidly respond to newly identified vulnerabilities.
This July 12 document recognizes that the SBOM generation process is new and therefore specific SBOM generation processes may not produce a complete SBOM. It also highlights the fact that vulnerability data is evolving and an SBOM produced six months, a month, or even a week ago may not include all of the vulnerabilities that actually exist within the software or firmware. This is especially true as new vulnerabilities are discovered. Another issue identified is the lack of a consistent naming process for software versions. It is not uncommon for the software version number that is included in the file name of the software to be different from how it is described within the software package itself. And of course, there are many formats of versions across the industry.
The memorandum also recognizes that information regarding the software components will be different depending upon when in the software lifecycle, and how the SBOM is produced. With all of these likely differences in the component and vulnerability information provided within an SBOM it seems logical that the various agencies will want to have several sources for this critical data. Also, having a library of SBOMs will allow for the rapid searching for newly announced important vulnerabilities.
The use of the NetRise fully-automated binary analysis platform can assist XIoT device manufacturers and the individual agencies with conformance to this memorandum M-22-18. Focusing on the intent of the entire suite of directives, improving the nation’s cybersecurity, there are significant advantages to the NetRise Platform.
NetRise produces an SBOM from firmware (and other) binaries and will include the components provided by up-stream manufacturers/open-source providers that are bundled within the final product delivered by the ultimate software producer. This approach allows for the comparison between SBOMs produced from the source code and will identify items that are introduced or changed during the build process.
Having more complete vulnerability data will allow both software producers and consumers to better assess the risks of the software and respond accordingly. The NetRise blog post, xIoT Device Risk: Turning the Industry Inside-Out, highlighted that vulnerability data in the National Vulnerability
Database may be incomplete for many devices. This lack of completeness stems from a lack of visibility into all of the components and sub-components of the firmware running on these devices. The NetRise Platform provides this visibility into all of the various elements within device firmware, allowing for the identification of the vulnerabilities that exist in each sub-component.
The clear intent of these various directives is to produce more secure software products and to be able to operationalize these products in a more secure configuration. This objective goes well beyond the enumeration of the many software components and their vulnerabilities. While SBOM is a critical
element of producing and using secure software, the NetRise Platform also identifies many other risks that cannot be tied to a particular software component or CVE. Many of these, like weak or plaintext passwords, or simple misconfigurations, are often low-hanging fruit and can be addressed quite trivially by the manufacturer as well as the asset owner.
On a more holistic level NetRise provides for easy and rapid searching within and across software. This allows for the identification of common issues that may increase risk. Software producers and consumers can use these search capabilities to rapidly identify which software components utilize a particular snippet of code or utility that is vulnerable to attack. Additionally, this search functionality allows our customers to instantly scope and analyze their entire environment for net-new CVEs (or other risks) that are published, minimizing the time to detect pesky, hidden vulnerabilities such as Log4Shell.
Stay tuned for upcoming NetRise blog posts where we take a deep dive into the unique approach we are taking to generate the most comprehensive and accurate SBOMs in the industry.
Have specific questions or would like to learn more? Reach out to us and we'd love to talk!
SHARE