Supply chain attacks are one of the most dangerous security threats in 2022, and, these days, also one of the most-often discussed. What folks in the security space don’t talk about enough is one of the best tools for handling future attacks.
GETTY
Two years ago, I would have been shocked that anyone would be talking about software supply chain attacks to this degree because it’s the kind of esoteric, neckbeard subject I like to think about. But then we had SolarWinds in late 2020 and Log4Shell, Kaseya and others last year.
And organizations are devoting a lot of attention and resources to supply chain risks. New research in Splunk’s The State of Security 2022 report finds that an overwhelming 97% have taken action in response. Security teams have increased focus on third-party risk assessment (90%) and CISOs are delivering regular briefings on the subject to the C-suite and the board (61%).
Great steps. But they’re not what helps when a software product your company relies on has been hacked. To deal with threats quickly and effectively when they arise, we will see organizations start to require an SBOM, or software bill of materials, when they buy software. An SBOM lists the elements within a software package, and lets you know whether your organization is vulnerable in the event of a supply chain attack. Much in the same way that a processed food item has an ingredients list, an SBOM lists the components of some software package. (Do I always want to know what’s in my junk food before eating it? Probably not, but you’d better know what’s in a software package before it’s installed.)
Every organization is either a consumer or supplier of software — or both, which is the case for most major organizations. When Log4Shell happened, we had Splunk customers concerned about whether Splunk’s software was compromised by the vulnerability. (Fortunately, we weren’t.) But Splunk is also a software consumer, so we also had to figure out which of our software vendors had been affected.
All of this goes faster with an SBOM
Software products are often composed of many open source projects, so if some attack or vulnerability were to surface, an organization would have many customers coming to it and trying to find out what components can install software. The organization would have to trace every component that resides within the product, and then contact that one person in Norway who happens to be the only maintainer in the world of a particular open source project. But if you can’t reach that one person for whatever reason, you’re out of luck. It could take days, if not more, to identify the components and determine whether each was compromised by the vulnerability — while the clock keeps ticking and your customers are kept waiting.
So having an SBOM really helps your own organization, and it also helps your customers. I’m describing it now as a very-nice-to-have, but pretty soon, I expect SBOMs to become standard practice, because every customer will be demanding them.
Source: Forbes
More news
