If you create software that runs medical devices, airplanes, or critical infrastructure, government regulations or industry rules will require you to submit a software bill of materials (BOM) that catalogues the components of your code. This process is necessary because the customer, as well as the regulator, want to be sure that your software does not contain vulnerabilities that create risk exposure.
For example, if your software includes an open-source code component that has a known Common Vulnerabilities and Exposures (CVE), an analysis of the BOM will reveal the presence of the CVE—triggering a remediation process. The CVE program is managed by Mitre Corporation. This makes sense, because who wants a pacemaker or a passenger jet that’s powered by malware?
This makes sense, because who wants a pacemaker or a passenger jet that’s powered by malware?
The process sounds simple, and in theory, it is. In practice, securing the software supply chain is a challenging, largely deficient process. For many, it can be an exercise in box checking. Submitted the BOM? Check. Flagged any CVEs? Check. Done, right? Maybe not…
According to JC Herz, Co-Founder and CEO of Ion Channel, the maker of a software supply chain risk management platform, the software supply chain risk assessment process needs to go a lot deeper than just identifying CVEs. Ion Channel was acquired by Exiger, a supply chain risk management company, last May. Now, Ion Channel covers the software side of Exiger’s broader supply chain risk management business, which covers factors like manufacturing defects, third-party risks, and so forth.
“The truth is,” Herz explained, “CVEs are a lagging indicator of risk.”
“The truth is,” Herz explained, “CVEs are a lagging indicator of risk. In our experience, a CVE is generally a good eight to twelve months too late in identifying vulnerabilities.” She elaborated, sharing that creating CVEs is a human process, which causes several serious problems. One is that people are slow. And, people work for incentives, even if they don’t realize they are doing so.
For instance, people may choose to focus on a vulnerability because it will garner them stars on Github, which in turn drives interest in the CVE from their peers. This is an understandable reality, but it’s not good for software supply chain risk management. It misses many serious vulnerabilities.
A better approach, Herz advised, is to stop approaching the process as a matter of box checking and start thinking more outside the box: Ask, “Where are the most serious vulnerabilities and attack surfaces, even if, or especially if you can’t see them.”
Indeed, some of the worst risks are not logged as CVEs. In some cases, it’s simply a matter of running outdated software. “We often see code components that are five updates behind. We know they are insecure, but they’re still in production with a ‘green’ dot next to them on a software composition analysis report. That’s a high-risk situation, even if there’s no CVE.”
Other times, risks arise from low quality code. “This is a lot more common than people think, even in highly critical software, like the code for medical devices.” The issue might be code that’s maintained by a single person, rather than using the “two-man rule” that provides a measure of objectivity and redundancy in securing software.
Then, there are zero-day vulnerabilities. These are seemingly secure and functioning bits of code that contain hidden exploits. Ion Channel’s solution is to undertake a massive data analytics process to identify previously invisible points of risk exposure. “Our platform analyzes a trillion data points in a software ecosystem. A lot of times, we spot problems that no one can has noticed.”
From there, it’s a matter of remediation. As anyone who has managed a developer team knows, this is not a happy subject. Culturally, developers tend to dislike remediating security problems. It’s not what they enjoy, and more importantly, it’s not where their incentives are driving them. “The incentive is to create new features,” Herz said. “Not fix old problems.”
In her view, the difficulties companies face in remediating insecure code are reflective of misaligned strategies for quality and commercial success. “The push is almost always for new features faster and faster, regardless of the supply chain issues. The problem is that the quality and security defects will eventually catch up with you, and the remediation will be a lot more expensive, including fixing damage to your reputation.”
Software supply chain security is an evolving field. As Herz is finding, companies are starting to get more serious about moving beyond box checking, but it’s a low evolution. Much work remains to be done.