By Ajay Singh, Author of CyberStrong! A Primer on Cyber Risk Management for Business Managers
Contemporary software development involves not only the generation of original code to meet required functionality but also using third-party and open-source components wherever possible to aid faster development and implementation cycles. In effect, any software often represents an assembly of software components- some original and some sourced as it goes into deployment. High-profile cyber-attacks involving software supply chain partners like SolarWinds which left thousands of their customers exposed to undesirable consequences have brought to the forefront the risk posed via the software supply chain. So much so that the US Federal Government Executive Order on Improving the Nation’s Cybersecurity of May 12, 2021, directed the National Institute of Standards and Technology (NIST) to issue guidance within 90 days and define standards, procedures, or criteria to enhance the security of the software supply chain. A key aspect of this order was that of providing a purchaser a Software Bill of Materials (SBOM) for each product.
The concern shown by the U.S. federal government regarding software supply chain attacks is understandable and timely considering that software supply chains are an integral part of critical IT infrastructure like Defense, Financial Services, Healthcare, etc., and can pose a threat to national security. While we may be tempted to believe that it was a succession of software supply chain attacks such as the SolarWinds attack in late 2020, followed by the supply chain attack on Colonial Pipeline in May 2021 and the attack on Kaseya customers in July 2021 that set the alarm bells ringing, experts were well aware of the risks that emanated from the software supply chain and that it was a problem waiting to receive due attention and prioritization.
As far back as April 2014, the US Federal government introduced The Cyber Supply Chain Management and Transparency Act of 2014 which required the Office of Management and Budget (OMB) to issue guidelines for agencies that contract to acquire software, firmware, or products containing a third party or open-source binary component. The purpose of the Act was to ensure the integrity of any software, firmware, or product developed for or purchased by the United States Government by enforcing the following requirements:
- The supplier/vendor must supply a bill of materials, of each binary component that is used in the software, firmware, or product.
- The supplier/vendor should verify that products do not contain known security vulnerabilities and to notify the purchasing agency of any known vulnerabilities or defects.
- The supplier/vendor must obtain a waiver from the purchasing agency for components known to be vulnerable.
- The agency granting a vulnerability waiver must accept all risk associated with component use.
- Product designs must allow fixes with patches, updates, or replacements; and
- The supplier/vendor must provide timely repairs for discovered vulnerabilities.
While the Act was not passed, it was an acknowledgment by the US Federal Government that there were inherent security challenges in the management of the software supply chain that could pose a serious threat and expose critical IT systems and infrastructure to a host of known (but unaddressed) and unknown vulnerabilities and that SBOMs were essential in assessing exposure and tracking remediation efforts.
Ultimately, cybersecurity is about risk mitigation, identifying the threats and gaps, and fortifying defenses to enhance security. While the risk always existed, the spurt in software supply chain attacks and the scale of damage that they can cause has only exacerbated the need to bring greater transparency and accountability to software applications that are connected to enterprise networks and other IT infrastructure. It is now being widely acknowledged that generating and maintaining an SBOM across the entire software supply chain is something that is long overdue and can play a key role in preventing supply chain cyber-attacks.
The National Telecommunication and Information Administration which is a part of the US Department of Commerce, describes a Software Bill of Materials (SBOM) as an ‘effectively a nested inventory, a list of ingredients that make up software components. Simply put, it is a list of sub-assemblies(components), sub-components, both open-source software and commercially sourced components that form a part of an application’s code along with associated services, environment, and dependencies.
Whether by mandate or through proactive efforts it should be incumbent on software suppliers to provide a customer with an SBOM for each product directly or by publishing it on a public website. Customers should also insist that an SBOM is made available to them at the time of purchase and must reserve the right to verify /audit the same during the life cycle of the application. An SBOM can not only bring cybersecurity into focus but provide benefits to multiple stakeholders such as developers, security, risk assessment teams as well as compliance and audit personnel. Without having SBOMs organizations can never fully understand how secure and safe their applications are from cyber threats and attacks.
There are people who argue (and perhaps rightly so) that publishing SBOMs could effectively provide a handle and a roadmap to attackers, but on the balance, the advantages provided by transparency and accountability outweigh the concerns. Anyway, hackers have their own tools and methods to identify and exploit vulnerabilities.
Organizations can start with generating their own SBOMs using commercially available tools or open-source tools like OWASP Cyclone Dx which offers different language level tools to generate SBOMs from existing package manifests or other inputs. Important aspects of metadata that can be captured are supplier/product name, version when the sub-component was introduced into the software, current version supported by the supplier, license information, etc. The next challenge is to make this a living document that reflects the present status at any given point in time. Ideally, a security dashboard that could reflect the associated risks along with the listing of the software component would go a long way in monitoring and managing software supply chain risks. Suppliers/vendors in vulnerability assessment, vendor risk management, and software composition analysis are already incorporating SBOM services to support organizations in implementing these plans. SBOMs are undoubtedly becoming essential for organizations wanting to adopt the best cybersecurity practices and manage associated risks. Keyways in which SBOMS can help improve Supply Chain Cybersecurity are:
- Provide comprehensive visibility into operational software, components, and system relationships
- Enable better vulnerability management
- Ensure timely rollouts and rollback of critical patches and remediation steps
- Support compliance and supply chain integrity through close coordination between vendors and customers
SBOMs today has become a key building block in software security and software supply chain risk management. Recognizing this and developing a deeper understanding of the supply chain of software, acquiring/creating an SBOM, and using it to analyze known vulnerabilities are crucial to managing risk in a supercharged cyber threat environment.
