eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The recent executive order will expand what companies must disclose to the government when a data breach occurs. Like the California Consumer Privacy Act (CCPA), these new rules will shield software developers from legal liabilities associated with a breach disclosure.
However, it will require due diligence on the part of software companies, which includes collecting and sharing evidence with federal law enforcement. A significant part of the disclosure is a software bill of materials or SBOM, that lists all components contained in a software product. Due to the increasing use of third-party and open-source code most software released today is a composite of internally and externally developed components.
Any quality and security issues in these reused components live on in new products and as such pose a risk that remains hidden to the end customer. In fact, software developers may themselves be unaware of the vulnerabilities and dependencies buried in the code they reuse.
The SBOM is more than just a list of software components. It’s a continuously updated catalog of software, version information and known vulnerabilities in the detected components including their dependencies which can be many layers deep. Since source code is often not available from third party component providers, a new class of software supply chain product is required to continuously track these vulnerabilities throughout the software lifecycle, including maintaining a SBOM.
Vulnerabilities in reused components is a high risk and easily exploitable attack surface. Often present in older versions of open-source software, they are public knowledge and exploits are readily available to attack at-risk systems. This includes both new and legacy products present in the marketplace for years. New security risks arise daily that can impact any current or previous version of reused software. As a result, software considered “clean” one day can become a new high priority issue the next.
Consider the recent URGENT/11 and Amnesia 33 collection of vulnerabilities in embedded network stacks. These vulnerabilities are linked to embedded real time operating systems (RTOS) and, specifically, third-party TCP/IP network stacks included and repackaged and sold together. Any developed products that use these operating systems are also at risk. The supply chain from the TCP/IP stack to RTOS to embedded software applications is vulnerable.
Meanwhile, the trend in software development is leaning towards more reuse and less custom coding. This makes sense as software reuse is a good way to reduce development costs. Since 2015 both enterprise/IT and embedded software development are moving steadily towards more open-source and third-party commercial software, as shown below.
The majority of both enterprise, IT and embedded software is reused code. This trend implies the need to secure the software supply chain.
Modern, advanced software composition analysis, particularly at the binary level, is a critical tool for securing the software supply chain. It can create a detailed SBOM and vulnerability report on the entire software stack, including all the dependencies in software. Using deep analysis, these products can create a detailed view of reused components, versions and known vulnerabilities from multiple data sources. Some can even detect zero-day vulnerabilities in the binary code from the top 25 CWEs (Common Weakness Enumeration).
These detailed vulnerability reports and SBOM provide the needed due diligence in the software supply chain. Discovered vulnerabilities are exposed so that risk management can be implemented. Frankly, without it, the risks are simply unknown and here, ignorance is not bliss.
The new executive order is a wakeup call for software development organizations, as are the increasing frequency and severity of software supply chain attacks. Implementing software composition analysis as a part of the development process to generate and maintain an updated SBOM for new and editing products will soon become a best practice and possibly a mandated requirement.
ABOUT THE AUTHOR:
Vince Arneja is Chief Product Officer at GrammaTech. He has more than 20 years of management experience in product strategy spanning application, cloud, mobile, endpoint and network security. Vince also serves as an advisor to various cyber security companies in the DC Metro Area and the Bay Area.