It’s possible that the SBOM you produce today won’t be the same as the one you produce tomorrow. The total number of dependencies could change. Some might change versions, add or remove things, or simply vanish.
Nowadays, you can’t turn without running into someone talking about software BOM (SBOMs). It’s great that everyone is paying attention to software supply chain security, especially given that SBOMs are the foundation of everything.
An SBOM is described by the government Cybersecurity & Infrastructure Security Agency as “a layered inventory, a catalog of ingredients that make up software components” (CISA).
Security experts and engineers are using SBOMs to acquire unheard-of insight into our software. Security starts with knowing what is contained in our program.
Another aspect of SBOMs, though, is not being talked about. The phenomenon is known as drift.
The idea behind drift is simple: over time and during the development process, the dependencies that make up an application will change. Existing dependencies could be eliminated or improved, while new ones could be added.
An SBOM that is created today might not be the same SBOM that is created tomorrow. Some dependencies may change versions, add or remove components, or even completely vanish. The number of dependents might vary greatly depending on what is happening.
It’s much simpler to demonstrate than it is to explain, as is the case with many new concepts.
The fundamentals are the same, but life-cycle drift will be considerably simpler to illustrate in this case than time-based drift. As your application is being constructed, the SBOM will constantly change.
The Tiresome Task
We’ll use the Syft project from Anchore, which is open source, for this illustration. Using your project, application, container, and other sources, Syft is a tool for constructing an SBOM. It supports a broad variety of languages and ecosystems and is easy to use.
Let’s start by creating a straightforward Node.js application that utilizes the Express package. Npx express-generator, which handles all of the setup and includes a few external dependencies to make sure everything works, was used to produce this example.
We can see that our demo application has six dependencies by looking at the package.json (the file where npm saves dependency details).
91 packages are visible after npm install when we use Syft to scan the project. What just transpired? This is an illustration of SBOM drift in action.
Our project originally had six dependencies, but once they were installed, the number increased to 91.
There is nothing wrong with this; to carry out the heavy work, modern apps need a lot of libraries. When we are ignorant of what is happening, a problem develops.
When I examine the package.json file, there are just six dependencies present. It’s possible that I thought I was only using six additional dependencies. However, it is obvious that the operating program needs much more.
Pay attention to the Drift
Making a container in which to deploy and use in production is the following step in the development of our application.
You’ve probably anticipated that adding a container to our program adds more dependencies. For this example, we’ll use the node:15 container image.
772! That exceeds 91 by a wide margin
During the course of our progress, we went from having six dependencies to 91 and now 772. The idea is called SBOM drift.
As we build our software, adjustments will be made. There are both major and little adjustments from time to time. Keeping track of those changes can help us learn more about the state of our surroundings.
If we are not creating and maintaining SBOMs, we might still think we have six dependencies.
If we only scanned at build time, we would have 91 dependencies. This illustration aims to highlight the significance of developing SBOMs at each stage of the procedure.
Making an SBOM only for the first build will leave out important information, and scanning an SBOM at the end won’t reveal where or why a dependency was added.
The Strike Zone
There is one more essential component to this whole thing, and it has to do with selecting our dependence. Everything we include in our applications and containers could increase the “attack surface,” as security experts refer to it.
The underlying idea is that your attack surface grows in size as you add more dependencies. It is well acknowledged that a small attack surface is preferable to a large one.
It lists 341 packages, which, while still a significant number of dependencies, is much less than the first container we produced, which had more than 700.
Our dependence attack surface has been almost cut in half, to put it one way. I now have to track and manage 341 dependents instead of tracking and managing 772.
Measure once, cut once
The significance of sbom drift as a statistic during software development and deployment is only partially illustrated by this example.
If we don’t monitor the performance of our software across a range of metrics, we risk being unaware of what’s happening in our environment.
Measure twice, cut once is a wise maxim that applies to both the software and physical worlds. Although SBOM management is still in its early stages, concepts like SBOM drift and their potential benefits are easily understood.
We can make better choices while developing software if we have visibility into our environments. As a result, there is a stronger security posture that can endure security breaches over time in the software supply chain.
