The recent executive order will expand what companies must disclose to the government in the event of a data breach. Like the California Consumer Privacy Act (CCPA), these new rules will protect software developers from legal liability associated with a disclosure of infringement.
However, this will require due diligence on the part of software companies, which includes collecting and sharing evidence with federal law enforcement. An important part of the disclosure is a software bill of materials or SBOM, which lists all the 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.
All the quality and safety problems of these reused components persist in the new products and therefore present a risk that remains hidden from the end customer. In fact, software developers can themselves ignore vulnerabilities and dependencies buried in the code they reuse.
The SBOM is more than just a list of software components. It is a continuously updated catalog of software, version information and known vulnerabilities in detected components, including their dependencies which can be multi-layered. Since source code is often not available from third-party component vendors, a new class of software supply chain products is needed to continuously track these vulnerabilities throughout the software lifecycle, including maintenance of an SBOM.
Vulnerabilities in reused components provide a high-risk and easily exploitable attack surface. Often present in older versions of open source software, they are common knowledge and exploits are readily available to attack risky systems. This includes both new products and old products that have been on the market for years. New security risks arise daily and can impact any current or previous version of repurposed software. Therefore, software considered “clean” one day may become a new high-priority problem the next.
Consider the recent URGENT/11 and Amnesia 33 collection of vulnerabilities in embedded networking stacks. These vulnerabilities relate to embedded real-time operating systems (RTOS) and, more specifically, to third-party TCP/IP networking stacks included, refurbished, and sold together. Any products developed that use these operating systems are also at risk. The supply chain from the TCP/IP stack to the RTOS via the embedded software applications is vulnerable.
Meanwhile, the trend in software development is leaning towards more reuse and less custom coding. This makes sense because reusing software is a good way to reduce development costs. Since 2015, the development of enterprise/computing and embedded software is gradually shifting towards more open source and third-party commercial software, as shown below.
Source: VDC – Finding Sources of Security in Tomorrow’s Complex Software Supply Chains
The majority of enterprise, computer and embedded software is reused code. This trend implies the need to secure the software supply chain.
Modern and advanced software composition analysis, especially at the binary level, is an essential tool for securing the software supply chain. It can create a detailed SBOM and vulnerability report on the entire software stack, including all software dependencies. Through in-depth 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 of the top 25 CWEs (Common Weakness Enumeration).
These detailed vulnerability reports and SBOMs provide the necessary 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 wake-up call for software development organizations, as is the increasing frequency and severity of software supply chain attacks. Implementing software composition analysis as part of the development process to generate and maintain an updated SBOM for new and release products will soon become a best practice and possibly a mandatory requirement. .
*** This is a syndicated blog from the Security Bloggers Blog Network written by Vince Arneja. Read the original post at: https://blogs.grammatech.com/coming-to-security-mandate-near-you-sboms