Software Bill of Materials (SBOMs): A Rick the Toolman episode.
Rick Howard: This weekend, my daughter called seeking advice about the red warning light flashing in her Subaru Crosstrek. You may be surprised to learn that I'm not much of a car guy. Well, maybe you're not that surprised. I mean, any old white guy like me who spends a lot of time obsessing about superheroes probably doesn't spend a lot of time in overalls underneath cars, worrying about brake lines, carburetor timing, or compression loss. I mean, if you put a gun to my head, I could probably manage changing the oil and fixing a flat tire, but it wouldn't be pretty.
(SOUNDBITE OF TV SHOW, "HOME IMPROVEMENT")
Tim Allen: (As Tim Allen) Oh, no.
Rick Howard: And if I'm lifting the car hood - toolbox by my side - with the intent to fix some mechanical thing, my best advice to any standers-by is to run in the opposite direction as fast as possible for fear of becoming some kind of collateral damage when the engine explodes. I'm just saying. But since I had the toolbox right here, it sounds to me that we're getting ready for another Rick the Toolman episode.
(SOUNDBITE OF SONG, "HOME IMPROVEMENT THEME SONG")
Rick Howard: My name is Rick Howard. I'm broadcasting from the CyberWire's Secret Sanctum Sanctorum Studios, located underwater somewhere along the Patapsco River near Baltimore Harbor. And you're listening to "CSO Perspectives," my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis.
Rick Howard: So when I tell you that my advice to the daughter consisted of recommending a call to the local auto repair guy, I guess you won't be shocked. But that got me thinking about repair parts she might need, which got me wondering about, where exactly did car manufacturers get their parts to build the cars in the first place? Which led me to think about the automobile assembly line process, which made me remember the Cybersecurity Canon Hall of Fame book "The Phoenix Project," where the authors explained that how we build software today should be similar to how Toyota reimagined the car manufacturing process after World War II into the famous Toyota Production System, or TPS. OK, OK. I'm sorry you had to hear all of that. That was just a small glimpse into how my mirror maze of a mind works. Trust me. You don't want to go in there without a guide. Just take your children by the hand and walk - don't run - to the exits. You'll be fine.
(SOUNDBITE OF TV SHOW, "HOME IMPROVEMENT")
Richard Karn: (As Al Borland) I don't think so, Tim.
Rick Howard: And hey, I know you might not have heard about the famous Toyota Production System, but seriously, business school graduate students have been writing papers about it for decades. Going through that thought process, though, made me realize something. Comparing software development to an automobile production line is all true at a macro level, but it breaks down at the micro level. What I mean is that the Toyota Production System applied to software development is the DevOps movement. And as regular listeners know, I'm a big believer in adopting its philosophy. It gets you away from the old waterfall software development method of producing one new working piece of code every couple of years - if ever - to 10 new deploys in a single day. That's the macro level, and that works. At the micro level, though - the day-to-day operational level - the Toyota Production System metaphor breaks down. Each part - and I'm talking about hardware parts here, not parts that have a software component - either comes from the same trusted contractor you've always used, or you build it yourself. Once built, the part doesn't change that much. Now, there are exceptions to this, of course, but that's the norm. The point is these hardware parts come from the same place every time you make an order. You know, for the most part, who those people are. That's not true in software development.
Rick Howard: According to a report by Synopsys in 2022, 97% of commercial code has an open-source component, and that's not all. Within that 97%, the bulk of that code base consists of open-source software - over 78%.
(SOUNDBITE OF TV SHOW, "HOME IMPROVEMENT")
Tim Allen: Huh?
Rick Howard: Let me restate that. Almost all commercial software is over three-quarters open source. That means, unlike the hardware parts that feed the Toyota Production System, we as a community have no idea where our software parts are coming from, who built them and whether or not the people who did build them are maintaining them. The problem is even more insidious than you might think. If most software developers are using open-source software, there is a good chance that whoever built a specific open-source component also used a different open-source module to create it. The whole idea spirals exponentially in a fractal kind of way. You all remember fractals? I do. I loved those things when I was younger. According to Grant Sanderson from 3Blue1Brown, a YouTube channel about discovery and creativity in math, fractals are mind-bogglingly intricate shapes that have infinite detail no matter how far you zoom in. You need to go to YouTube and look them up. They are beautiful.
Rick Howard: And I hear what you're saying. Nested open-source software components are a long ways away from being beautiful. I get that. But it's the infinite nature that I find fascinating in both fractals and supply chain software components. Open-source software components may not be infinitely nested, but there is a good chance that if you pry one open, you'll find a handful of other software components that you didn't know about. And to throw fuel on the fire, hardware parts manufacturers don't have to contend with armies of researchers that routinely find ways to exploit those software parts for criminal, espionage and continuous low-level cyber conflict purposes. The use of open-source software provides these adversary groups a wide-open attack pathway that we all call the software supply chain. Compared to car manufacturers, DevOps people have to operate at an entirely different level. We've seen a handful of these so-called software supply chain attacks in the past 20 years, but recently, it feels like the bad guys have rediscovered this attack strategy and doubled down on it.
(SOUNDBITE OF TV SHOW, "HOME IMPROVEMENT")
Tim Allen: (As Tim Taylor) Oh, no.
Rick Howard: Just in the last five years, we've observed highly impactful attacks against third parties like M.E.Doc, the NotPetya attacks against Ukraine and other victims in Europe - SolarWinds, ASUS, CCleaner, Kaseya and Accellion - just to name a few. These kinds of attacks are even more Machiavellian than a straight-up frontal assault against our own cyberdefenses that we designed, deployed and spent considerable resources on. With a supply chain attack, it doesn't matter how mature those programs are. The hacker's initial compromise in their attack sequence comes right in through a wide-open front door to our data island defenses, propped open with a chair to make entry even easier.
Rick Howard: As an aside, to break the chain of this attack sequence, even if the initial breach was successful, robust deployments of our first-principle strategies will work. Even if the adversary group is successful in establishing a beachhead somewhere in our environment, those strategies have a high probability of preventing any kind of material impact. But if we are pursuing zero trust as one of our first-principle strategies, it's ludicrous to think that we as a community don't have a handle on supply chain defenses yet. We have been busily running around trying to identify all of our employees, contractors and devices and then prescriptively authorizing the workloads they have access to. But in parallel, we have mostly turned a blind eye to new software coming in through the front door to update our production systems. The cybersecurity leaders who do monitor and manage the situation rely on manual, homegrown and incomplete tooling to get this done. The solution that the security community has chosen to solve the problem is a concept called a software bill of materials, or SBOMs.
Rick Howard: We don't really have a standard SBOM platform yet. What we do have is a bunch of developing standards and requirements for tools that will help us reduce the risk of software supply chain exposure. Although vendors are starting to sell SBOM platforms, the idea of an SBOM is at this point still more of a concept than a reality. In its simplest form, an SBOM is a formal record containing the details and supply chain relationships of various components used in building software. They are lists of nested software components designed to enable supply chain transparency. So if my business runs a software application called Fortnite - 'cause, you know, I've been trying to convince my boss that playing "Fortnite" builds team camaraderie...
(SOUNDBITE OF TV SHOW, "HOME IMPROVEMENT")
Tim Allen: (As Tim Taylor) Oh, yeah (laughter).
Rick Howard: So far, he's not buying it, but I'm still trying. An SBOM will list all of the component pieces of the software, all of the original code written by the developers at Epic - "Fortnite's" owner - plus all the open-source components they use to make it run, plus all the fractal subcomponents built by other open-source developers. They would do that by using a tool that follows a formal specification of the standard. Spearheaded by the Linux Foundation back in 2010, the software package data exchange, or SPDX, also known as ISO/IEC 5962, became the international open standard for security, license compliance and other software supply chain artifacts last year - September 2021. In other words, they became the official SBOM standards body. Despite only being internationally recognized for a short while, companies like Intel, Microsoft, Sony and VMware are already using the SPDX standards to communicate SBOM information.
Rick Howard: But SPDX was not an overnight sensation. It was the result of 10 years of collaboration from vendors across the software composition analysis space, or SCA for short. These folks make tools that assess open-source software, code libraries and containers to provide a unified view of risk and remediations and offer strategies to keep this kind of software up to date. In 2015, the International Organization for Standardization, ISO for short, released ISO/IEC 19770-2, or Software Identification Tags or - get this - SWIDS, spelled S-W-I-D-S. How great is that name - SWIDS? This format creates a template in XML format to identify and describe software components and relevant patches. Then in 2017, the Open Web Application Security Project Foundation, OWASPF, designed Cyclone DX, a lightweight standard with features of both SPDX and SWID. As I said, the SBOM today is a collection of emerging standards that are not quite there yet, but the community is very close to having something usable.
Rick Howard: The SBOM concept got a big push in 2021 when President Joe Biden signed an executive order on cybersecurity, EO-14028, that mandates that all federal civilian executive branch agencies, or FCEBs for short, and key players meet or exceed specific cybersecurity requirements, including the development of an SBOM program. FCEBs are our U.S. government institutions like the Cybersecurity and Infrastructure Security Agency, CISA, and the Office of Management and Budget, OMB. There are many others.
Georgianna Shea: My name is Georgianna Shea.
Rick Howard: I was talking to Dr. Georgianna Shea this week about SBOMs in general and specifically about President Biden's directive.
Georgianna Shea: I work for the Foundation for Defense of Democracies. I'm the chief technologist for the Transformative Cyber Innovation Lab, also known as the TCIL. And my job there is to demonstrate good technologies or processes that move the needle on cybersecurity.
Rick Howard: She's an old friend of mine, a regular at the CyberWire Hash Table and one of the world's experts on the SBOM concept. She's been tracking the progress of all the FCEBs in relation to the presidential directive and says that for the most part, the government is meeting its deadlines. But she caveats that a bit by saying, quote, "their requirements weren't to be operationally executable, so the actual requirements were easy to meet. There were two specific SBOM requirements in the EO - one, identify the minimum elements, and two, provide guidance addressing an SBOM," end quote. According to Dr. Shea, the government met both of those. So all the FCEBs are on track policy-wise, but there is still a lot of work to do operationally.
Rick Howard: It turns out that an SBOM is not the only tool that we need. Once we have a handle on all of our software components inside the SBOM, it would be nice if there was a place that was the authoritative source for automatically discovering vulnerabilities and exploits in common software. This would be an upgrade to the common vulnerability scoring system, or CVSS. Instead of me reading reports on software vulnerabilities and trying to determine if they apply to the data in my SBOM, the upgraded CVSS would be machine readable and allow another system - an asset management system - to review my SBOM information and compare it to this upgraded CVSS.
Rick Howard: We don't really have that, either. But what we do have is a standard way to articulate vulnerability information in component software. It's called a VEX document - vulnerability exploitability exchange - and is an Oasis Draft standard in the Common Security Advisory Framework. VEX is a format that we can use to store vulnerability and exploit information about software components. What it isn't is a system to store that information in any automated way. The bottom line is that if we are going to reduce the risk of software supply chains, we need an SBOM, No. 1, an asset management system, No. 2, that is the go-between to the upgraded CVSS, No. 3, and that stores information in the VEX format.
Rick Howard: In fairness, the concept of an SBOM has been around for many years, but there wasn't a lot of incentive out there for a massive push to build something useful. So quietly, in the background, volunteers from the Linux Foundation, commercial vendors, OWASPF and others began work to establish some standards. When supply chain attacks started to rise these past few years, coupled with several hugely impactful ones like SolarWinds, MeDoc and Salient, somebody convinced President Biden to include SBOMs as part of a presidential cybersecurity directive.
Rick Howard: That's the good news. Progress on SBOM development is happening. It helps that the U.S. government, at some point, will mandate that all software suppliers provide SBOM information as part of their contract. I believe that will tip the dominoes and the rest of the industry will follow that lead. But I'm guessing that we are still five years away from the SBOM transitioning from a concept to a real thing.
Rick Howard: One last thing - if you're looking for more detail, Dr. Shea has written several papers on the subject, and she knows who all the players are in the government and in the commercial space. I've linked to her papers below. I highly recommend them.
Rick Howard: The CyberWire's "CSO Perspectives" is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions, remixed by the insanely talented Elliott Peltzman, who also does the show's mixing, sound design and original score. And I'm Rick Howard. Thanks for listening.
