Sussing out rusty security links in your software supply chain

Let’s talk about rusty supply chains. But first, let’s talk about chocolate. 

Say you live four blocks away from a candy factory. Your mornings smell amazing. 

What do you focus on when you go on a tour? Probably not the ChocoVision C116USREV2WHI Revolation 2 Chocolate Tempering Machine. No, you focus on the end product: the KitKats, the Lindt truffles, the Toblerones.  

It’s the same with supply-chain security, commented Contrast Security CISO Dave Lindner in a recent chat with Jerry Gamblin — director of security research at Kenna Security — about supply-chain security. 

Just like Godiva has a supply chain — trucks to deliver ingredients, machinery to cook it and trucks to offload candy bars — so too is software made in a virtual factory with a lot of moving parts, each of them vital to the production. How strong is each link in that chain? How can you, as a consumer, even gauge the strength?

That opacity — what exactly am I eating? Ninety percent cocoa, 5% insect parts, 5% vulnerable Log4j libraries? — has been  underscored by massive supply-chain attacks such as the Sunburst attack on SolarWinds's Orion software and Log4Shell. The feds’ response to such supply-chain attacks: requirements for self-attestation of secure coding practices and the need for Software Bills of Materials (SBOMs) that can give us some clarity into what goes into the software mix. 

Unfortunately, the software industry is treating SBOMs like a silver bullet, Gamblin and Lindner agreed. That’s just missing the forest for the truffles. SBOMs are “a teeny, tiny piece of the broader software factory,” Lindner says. If you focus on SBOMs, you’re missing the fact that adversaries are exploiting  “pieces and parts of that entire software factory.” 

Chocolate industry, we salute you

When it comes to our software factories, as an industry, we’re not even on par with that chocolate factory, Gamblin said. “They could tell you down to probably the hundredth of a cent how much they make on every ounce of biscuit,” he said. 

The software and computer industries, not so much. “We can't even tell you what is going into the packages, right?” Gamblin said. “We're still trying to figure out how we build that ingredient list on the back of our packaging, and we can't even decide that as a group,” let alone as an industry, he said, referring to the current mishmash of standards for SBOMs. 

As it is, third-party code — including open-source libraries, for example — makes up something like 80% to 90% of all the code that’s written (or, for the most part, all the code that’s cobbled together), Gamblin and Lindner estimated. 

What are we missing when we overfocus on SBOMs? We miss who does what, and when, and where, as well as which issues we need to fix, and whether the so-called vulnerabilities that crop up turn out to be false or legitimate alerts, Lindner said. An example from Gamblin: “When we get to the point where we're pumping out SBOMs, that's all people are going to see.” 

A typical scenario: Log4j library spotted. Yikes. There’s a Common Vulnerability and Exposure (CVE) number for that one. But is it a vulnerable instance? Do you need to waste precious time remediating it if you’re not even using that part of the library? Will an SBOM tell you that?

Nope. Conclusion: Don’t put all your faith in SBOMs. They won’t help you secure your code. One of the problems: The tools we have now need to be better: They’re bleating out “Patch this right now!” without giving true understanding of the real need. 

“[The tools tell you to] ‘just go run the patch and update this vulnerability, Just do it,'” Gamblin explained. “But I think this year it's up to about 1% of CVEs that ever get an active exploit coming for them.”

Have a listen to the podcast for more of Gamblin’s and Lindner’s thoughts on tools that squeak and squawk and waste your time while you’re trying to wrap your arms around how rusty your supply-chain security actually is.