During my career as a newspaper journalist, I was continually irritated by the sheer amount of detective work required to write a decent story. Gathering facts was never easy; it always involved digging around, asking lots of questions and relying on scanty facts to craft a narrative that I hoped was reasonably accurate.
Today, I write mostly about software supply chain security processes. A key step in these kinds of security processes is knowing what’s in the software you’re using.
Yet there’s the rub: Analyzing the components in a software or firmware product should be a relatively straightforward process. Instead, it’s often shrouded in mystery. You need the skills of a detective to figure out what’s in the software, especially when it’s written in older code such as C or C++.
“You essentially have to take a forensics approach in order to break down the binaries,” says Michael Scott, CTO and co-founder of NetRise, a company specializing in firmware component analysis. “And you have to do it recursively until you end up with no new artifacts.”
In plain English, that means getting down to the nuts and bolts of the code. And in case you’re wondering what “a binary” is, it’s typically a compiled or executable file with no text. “Artifacts,” on the other hand, can include source code files, configuration files, test results, release notes and documentation.
Yes, software is complicated. Analyzing it can be a Herculean task that requires compiling an inventory of components, identifying dependencies between the components, determining which versions of the components are in the software, making a list of vulnerabilities and then deciding which vulnerabilities pose genuine risks.
And that’s only a fraction of the work involved. “You have to look at a binary, break it down and reverse engineer it, using an automated process,” Scott explains. “And you have to do that over and over again … then can you start to identify components within that binary that might cause problems.”
No wonder most people have no idea what’s actually in the software they use. At the risk of being flippant, it’s easier for me to get a list of ingredients in a hot dog than it is to get a list of software components in a medical device. I enjoy reading Raymond Chandler novels and watching old episodes of “Columbo,” but I shouldn’t have to act like a detective when I’m trying to analyze a firmware product.
Let’s step back for a moment and remember how we got into this situation. Here’s the short version of the story: Companies that develop software and developers who write software code typically look for ways to save time and money. This is natural, but there are consequences. In his excellent new book, Introduction to SBOM and VEX, software supply chain security expert Tom Alrich provides an excellent overview of modern software development processes:
“Nowadays, it is common for up to 90% of the code in a software product to be written by third parties, usually in the form of pre-written components that are available as open source or commercially. It is no exaggeration to say that the cost of developing an average software product today would be many times larger, and in many cases the cost would be prohibitive, if components were not available … Along with cost savings and increased functionality, components have brought a much higher level of cybersecurity risk to software users, due to vulnerabilities and other flaws found in those components.”
Alrich adroitly points out that while it may be easier and less expensive for companies to use pre-written components when developing new software, it’s not a “free lunch” scenario – the costs of security breaches are borne by users and, ultimately, by society at large.
In a previous article, I mentioned the concept of “technical debt,” which represents the burden placed on our economy by sub-par technologies and poorly written software. From my perspective, it makes more sense to fix software problems before they become headline news and certainly before they become deadweights on our economy.
Just because you can build a product cheaply and inexpensively doesn’t mean you have to build it that way. Software has become such a fundamental part of our lives that it seems foolish to afflict ourselves with software that isn’t inherently safe and secure. Surely, we can hold ourselves to a higher standard.
Until that happens, we’ll need to rely on a style of software analysis that combines good old-fashioned detective work with the power of modern computing.
In "The Sign of Four," Sherlock Holmes observes that, “When you have eliminated the impossible, whatever remains, however improbable, must be the truth." Doubtlessly, the great detective would have been impressed by our technical achievements. But he would also wonder why, given our state of advanced technology, we haven’t already solved an elementary mystery of software supply chain security.