SBOM: the 1st Step Towards Defending Against SW Supply Chain Attacks

What is an SBOM?

A Software Bill of Materials, commonly referred to as SBOM, is a list of all components—including proprietary, open source, and 3^rd party— in a piece of software. Think of it as the list of ingredients on food packaging. An SBOM is useful both to the builder (manufacturer) and the buyer (customer) of a software product. Builders often leverage available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Although many companies use Microsoft Excel[6] for general BOM management, there are additional risks and issues using a spreadsheet for an SBOM. SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems.
Recent Cyber-attacks and the Need for SBOMs ASAP

Recent cyber-attacks involving SolarWinds, the Colonial Pipeline, and JBS have put a spotlight on software supply chain vulnerabilities and highlight the immediate threat software supply chain attacks pose for organizations big and small. It seems intuitive, but why is keeping track of your proprietary, 3^rd party, and open source software components so hard? I mean, don’t all organizations want to understand what’s in the software they build, purchase, and use? The problem is trying to keep up with the speed of digital transformation. The pressure to release faster with greater functionality means skipping some steps to stay on schedule, and often keeping track of these items falls by the wayside. And sadly, if the data exists at all, it’s usually entered and maintained manually in a spreadsheet. Once the owner leaves, it dies on the vine.

If the fear of an attack isn’t sufficient, then the financial consequences should be. In an interview with the Wall Street Journal, Joseph Blount, CEO of Colonial Pipeline Co., said he “authorized the ransom payment of $4.4 million because executives were unsure how badly the cyberattack had breached its systems, and consequently, how long it would take to bring the pipeline back.” Uncertainty cost Colonial Pipeline $4.4M.  Would the tools to prevent this uncertainty cost that much? Certainly not (pun intended).

Biden’s Executive Order and SBOM

On May 12, 2021, President Biden gave an Executive Order on Improving the Nation’s Cybersecurity and specifically calls out the requirements for sharing the software bill of materials (SBOM) information to defend against software supply chain attacks.

The term “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software.  Software developers and vendors often create products by assembling existing open source and commercial software components.  The SBOM enumerates these components in a product.  It is analogous to a list of ingredients on food packaging.  An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software.  Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities.

The clock is ticking. The order goes on to say, “Within 60 days of the date of this order, the Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration, shall publish minimum elements for an SBOM.”

Being forced by the government to implement an SBOM is one reason to use it, but there are immediate benefits for multiple audiences. You don’t have to look at this as one of those “because I told you so” tasks. An SBOM benefits the app developers and the people that purchase the product. It allows the developers to proactively manage and remediate license risks and security vulnerabilities, and it allows the buyers to verify such risks throughout the product’s life cycle.

Limitations of Existing SBOM Tools

There are tools out there that take your jar/npm files and give you the list of 3^rd parties and packages in it along with license details. While this addresses part of the problem, it is limiting for several reasons.

1. Most tools provide SBOM as a simple static list of dependencies in your application or container image. We need to supplement this list with actual runtime usage to answer questions like what dependencies are simply added but not used? What percentage of the dependency are we using? Is my application calling any vulnerable methods in the dependency?
2. While a list of dependencies is traditionally considered an SBOM, there is a need for organizations to track ‘Runtime BOM’ which consists of a list of outbound connections, a list of files touched, ports my application is listening on, etc. These metrics are quite important for Security teams to know and track because they increase the attack surface area.
3. For Kubernetes applications, where you may have several microservices, it’s cumbersome to try and do this for each container image. What if you could just drop something into your Kubernetes setup and magically get the SBOM for all the containers and micro-services running in your Kubernetes environment?

Continuous AppSec Observability: the Most State-of-the-art Approach for SBOM

Modern observability techniques enable the automatic gathering of the composition of your jar files, your container images, and runtime metrics such as ports, processes, outbound/inbound network connections, file touched, etc. And with the right observability tool, one could integrate this visibility seamlessly into the CI pipeline to automatically get SBOM visibility into every release and compare how the SBOM is changing with each release.

Announcing Deepfactor’s SBOM Module

Here at Deepfactor, we’ve launched an SBOM module in our latest product release of our Continuous AppSec Observability platform. Now, with one simple command, Engineering and AppSec teams will have a catalog of all software dependencies—including open source and 3^rd party—and OS packages used by the app, along with licensing information and runtime metrics such as processes, ports, files, and network connections. You can run Deepfactor on your traditional apps or simply drop in Deepfactor’s webhook admission controller into your Kubernetes cluster. And you can integrate Deepfactor into your CI pipeline to get continuous visibility into your SBOM for each release of your product, automatically. Deepfactor thinks like an auditor so you don’t have to, which makes SOC2/other compliance processes a breeze. But don’t just take our word for it. Request a demo HERE and see for yourself.

Learn more about Deepfactor’s latest product enhancements here.

About Deepfactor

Deepfactor is a cloud native applapplication security platform that enables developers to quickly discover and resolve security vulnerabilities, supply chain risks, and compliance issues during development. The unified AppSec platform provides integrated artifact scanning (SCA, container scans, SBOM) and runtime visibility (IAST, DAST). Requiring no code changes, the Deepfactor runtime observability technology seamlessly plugs into cloud native architectures to observe telemetry and detect anomalies, providing developers with a prioritized and actionable list of contextual security risks. Deepfactor simplifies operations, reporting, remediation, and integrates AppSec into the CI/CD pipeline to drive the adoption of DevSecOps for modern enterprises. Request your demo today!