Any software that is purchased today will include a lot of code created by third parties, whether they are open-source communities — like the Apache Foundation — or for-profit companies — like Microsoft. Today’s industrial software vendors focus their development resources on their area of specialization and buy common components like license managers, installers or cryptographic libraries. Our analysis of industrial software shows that the average package includes more than 1,000 components from 30 to 40 different third-party suppliers, with some containing more than that.
A lot can go wrong when software is constructed from third-party components. This strategy involves a vendor’s security posture with the security postures of all the suppliers and open-source projects they use, creating a complex software supply chain. It also includes the security of every purchaser of that software with hundreds of other parties, most of which are unknown to the end user.
Hackers are taking advantage of the complexity and lack of transparency in the software supply chain. For example, the Russian security agency, SVR, injected malicious components into software produced by the company SolarWinds, and SolarWinds distributed the malware to 18,000 of their customers.
Supply chain attackers don’t have to use malicious code. Just as often, they take advantage of bad coding and security practices. The supply chain risk posed by the vulnerabilities discovered in December 2021 in the Apache Foundation’s Log4j module were simply due to the software’s widespread use and exploitability.
Because of the malicious or poor code, supply chain attacks are on the rise. According to the 2020 State of the Software Supply Chain report, supply chain attacks surged in 2020: up 430% in just 12 months.
The government to the rescue?
U.S. government regulations to aid in protecting the software supply chain have been surprisingly swift and useful. Executive Order (EO) 14028 lays out valuable, actionable guidelines for limiting supply chain risk. The most notable part of the EO is the requirement for software companies to provide a software bill of materials (SBOM) for every critical software product delivered to any U.S. government entity.
SBOMs are the critical first step to understanding what’s in a software package. They tell the receiver what all the subcomponents are and who made them.
If SBOMs are good for the government, then they are likely good for everyone else, as well. Commercial demand for SBOMs is rapidly growing — we’re aware of Middle Eastern sovereign oil companies who want to duplicate U.S. software supply chain requirements for their OT/ICS purchases in 2022.
Using software bill of materials to understand risk
Most development environments provide some SBOM creation capability for software that is in development. In the case of critical infrastructures where companies are often dealing with technology with a long service life, there is a good chance they will discover legacy software with unavailable source code. In these cases, SBOMs created through binary analysis are the only solution.
The information exposed by SBOMs has the potential to overwhelm users, exposing a massive number of components that need to be analyzed for vulnerabilities against the National Vulnerability Database (NVD) and other sources. Once vulnerabilities are found, organizations must then determine if they are exploitable. It is crucial to prioritize the vulnerabilities uncovered by using SBOMs and focus efforts where it matters.
Enriching software bill of materials to enhance visibility
Finding deeply embedded vulnerabilities in third-party components — and accurately assessing their risk — can be a complex and time-consuming task. Even for a seasoned security analyst, matching up vulnerabilities against installed products is difficult and expensive. Fortunately, there are resources that use artificial intelligence and natural language processing to make the associations between vulnerabilities, components, products and vendors for the user. These next-generation techniques scrape the internet, searching vendor websites, public databases and other services to expose hidden vulnerabilities swiftly and comprehensively.
While SBOMs are a great starting point, companies in the industrial space will need additional sophisticated technology to use them to efficiently reduce supply chain risk. This need is especially pressing when attempting to detect and prioritize vulnerabilities.
Enriched SBOMs can provide full software supply chain visibility for operators, regulators and legislators. Having immediate executive level visibility into supply chains will be a minimum requirement for management at all agencies and companies so they can confidently and quickly respond to the next security crisis.
— Adolus is a content partner of CFE Media.
Do you have experience and expertise with the topics mentioned in this article? You should consider contributing content to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.
