BOMs away!
As cyberattacks have increased over the last several years, governments have begun responding in a variety of ways. One way has to been to start setting standards for cybersecurity practices that organizations should implement. The US government rolled out Executive Order 14028 which, among other things, includes a requirement for US federal contractors to provide a sofware bill of materials. What is a software bill of materials (SBOM) and why should you care even if your are not providing services to the federal government?
The term “Bill of Materials” (BOM) has been around for a long time in manufacturing. It is essentially the list of all the raw materials, parts, and pieces needed to manufacture a product. An software bill of materials is the list of all the tools, libraries, services, and components needed to build and run a software system.
Why does an SBOM matter and why does it come up in the context of cybersecurity? Any piece of software beyond the most incredibly simplistic will be imperfect. Attackers will try to find those imperfections so they can exploit them and crack open systems. Most complex web applications will be composed of dozens to hundreds of third-party components and we can be sure some of those will have some weird corner case that can be exploited. When that corner case is found by someone without criminal intent, that person can provide a report to the creator. The creator or discoverer should also report it to a vulnerability database. We can search those databases (e.g., NIST’s National Vulnerability Database) to see what vulnerabilities exist in the software we are using. Hopefully, the software creators are also patching their software and reporting when they have fixed the issue so we know when to go get updates as well. Having an accurate SBOM is critical to performing those look ups and knowing what we need to update.
The SBOM is a simple concept, but getting a complete, up-to-date SBOM can be an arduous process. The components we get from someone else likely are built on other components which are in turn built on yet more components. These transitive dependencies can run many layers deep. Our SBOM needs to list both the direct dependencies we add ourselves and those transitive dependencies. In November 2021, the Log4Shell vulnerability was discovered in the extremely popular open source logging framework Log4J. This was one of the most severe vulnerabilties ever found in terms of impact because it was simple to exploit and Log4J’s popularity meant a very high percentage of organizations (as many as 93% of enterprises) were using it if only because a software package they’d gotten from someone else used it.
Even before Log4Shell, I am confident in saying this:
If you have complex web based software that has not been updated in the last year, there are multiple critical vulnerabilities in that software.
So your knee jerk reaction might be “we will stop using third party components in our custom apps unless we’ve thoroughly vetted it.” I’m sorry to say it, but your developers are no bettter than any other developers, trust me. You also don’t have the time to do the level of vetting needed. Hunting for security flaws is a completely different skill set than creating software and there are probably only a handful of people on the planet that can do both well. Instead of swearing off third party components, I suggest relying on the community of security researchers, maybe donate some funds to those security researchers, and focus on building out SBOMs across your entire organization and for each custom app you are building (those app specific SBOMs feeds into the organization wide SBOM). Then use those SBOMs to help you understand what needs to be updated.
We can get most of an SBOM for the components we include in our custom apps almost out of the box with modern package managers because those package managers need the list of components you are using in order to do their job. JavaScript’s NPM, Python’s PIP, dotnet’s Nuget, Rust’s Cargo, Ruby’s Gems, are all examples of package managers that can easily tell you what software they’ve installed. NPM (npm audit) and Nuget (via the dotnet cli’s list packages command) have tools essentially built-in to list packages you are using that have vulnerabilities. Python’s PIP, and Rust’s Cargo have various add-ons that can do it for you. I’m sure at this stage that these exist for any other well managed package manager. Those are just the ones I’m familiar with.
The package managers have a limitation of course: they can only tell you about the things they manage. Components that are installed without using the package manager will present a blind spot for them. The most critical such component will usually be the development framework (e.g. dotnet) that you are using. For many development environments, we add the core framework, then the package manager, so that package manager doesn’t get the chance to report on that outermost framework. It also isn’t going to know about things like the version of the database software you are using and so on. We’ll need those vendors to provide their own SBOMs or trust their updates include updating their own transitive dependencies.
Tools for building and managing your enteriprise SBOM are still evolving, but we can hold out hope. Linux admins have relied on package managers to install software at the machine level for years, Windows and Mac are catching up. Avoiding manual installation and restricting yourself to installing software via package managers or simialar tools that keep track of what you’re installing automatically turns SBOM management from an execercise in futility into a reporting and consolidation activity. That’s not trivial, but it is possible. Rounding up all the little tiny systems (don’t forget the thermostat in the fish tank) will still be a hassle, so simplifying where you can is always going to be the smart idea.
Even with SBOMs in hand, we will still need to catalog our data, map our networks, and more to understand the total technology footprint that we need to protect. It may seem overwhelming, but good information will always be the key to good security. I’ll be staying on the security topic next month as well, but still debating which of two directions to go in. Stay tuned!