Software supply chain attacks have grown exponentially over the last three years: malicious packages, package manager corruption, continuous delivery pipeline attacks, dependency confusion, zero days in open-source software and more. This is driving many organizations to look for better visibility across their software supply chain.

Let’s dive in a bit to see why the problem is growing and some potential solutions.

Application complexity is increasing

The reality is that modern applications are complex and dynamic, and therefore hard to secure. They use programming languages that run entirely in the browser, they talk directly to their dependencies on the internet and they use technologies like containers, serverless and public cloud. All of these bring their own challenges, so we need visibility into all these other application components and dependencies as well. What third-party APIs and public cloud components is it using? Is it using an identity provider like Auth0 or Cognito? What infrastructure is required to make the app run? All of these things need to be understood to really be able to better represent what is in an application and how to secure it.

SBOMs can help address software supply chain risks

One way to address the risks inherent to the complex applications we are building is to use “Software Bill of Materials” also known simply as “SBOM”. At its simplest, a SBOM is a list of all the different component parts of an application. This typically includes several types of information about each component: Its name, who supplied the component, what license it uses, the version number, any known vulnerabilities, and a list of all the component’s dependencies.

Most SBOM tools that exist right now, focus on showing customers some of the open-source libraries that they are using in their applications. Moreover, most SBOMs are stand-alone JSON documents and by themselves don’t provide much value. Even worse, many SBOMs are created once and then never updated so they quickly become out of sync with the actual application they are supposed to describe.

What’s in the SBOM lifecycle?

Most SBOM advocates believe that SBOMs should be automatically created during deployment, and should be as descriptive of the actual application as possible. To do this, organizations need to have a process that identifies applications, creates SBOMs and then makes them available for the business to gain value from. We believe the best way to do that is to create a SBOM lifecycle policy.

There are five stages in the SBOM lifecycle: Asset discovery, application data analysis, SBOM creation, SBOM storage and SBOM searchability.

Let’s go through each of these stages one at a time.

Asset discovery

You can’t onboard what you don’t know about. This stage is all about helping the customer find the applications they need to ultimately provide an SBOM for, which hopefully, is all of them. Most companies only know about 50% of their public-facing application names. The other 50%? Well, that’s the problem. Finding assets with domain names like app.niftybank.org and api.niftybank.org seem obvious but how do you find the less obvious apps?

Existing asset discovery or attack surface mapping tools can help find assets but what do you do with the list that these tools have generated? Most of those tools don’t have any SBOM functionality, so how do you get the list of assets into your SBOM creation pipeline? It’s better if your solution can find your assets, show them to you and allow them to create a SBOM from that same workflow.

Application data analysis

In this stage, the data that is needed to create an SBOM is collected about the target application. Historically, SBOMs got this info from package manifest files, but now, that’s typically not enough. Modern SBOMs are able to incorporate data from cloud providers, third-party services and SaaS solutions in addition to source code.

SBOM creation

In this stage, the actual SBOM file is created and will include all the relevant application data. Typically, you will want this to happen every time your engineering teams deploy a new version of the application. After all, if you aren’t building a SBOM every time you deploy a new version, is your SBOM going to match the state of your production app? The only thing worse than no SBOM, is a *wrong* SBOM.

SBOM storage

SBOMs need to be stored somewhere centrally and protected with a rich authorization layer. This centralized storage can be an S3 bucket or other secure managed file server, but make sure that they’re stored in an encrypted manner! Otherwise, you might run afoul of compliance requirements!

SBOM searchability

Finally, customers need to be able to search across some or all of their SBOMs. Ultimately, all the steps before this one led to enabling this functionality. This searchability is the most important aspect of the SBOM process because this is the central source of truth. This is how you look up vulnerable software in your environment and find which applications to tackle.

Imagine if you had this functionality back in December 2021 when the Log4j zero-day dropped! Wouldn’t it have been nice to go to a central place you could go and say “hey, tell me all the places that Log4j is being used and what versions they are!”

Tying it all together

Building a complete SBOM lifecycle can be a challenge, but in the end, the value that it provides to organizations is enormous. Simply having the ability to quickly find all the software and application components in your estate of apps is huge. But even better, being able to query that data for vulnerable components could save organizations millions of dollars in lost productivity.

Native SBOM lifecycle

You can build your own SBOM lifecycle or alternatively, SecureStack automates the whole process from end to end. Our platform delivers all stages of the SBOM lifecycle in a fully integrated solution that is incredibly easy to onboard. Our platform provides an end-to-end SBOM solution that helps organizations address software supply chain risks holistically. We find all your application assets, automate the creation of your SBOMs, store them for you in a secure central repository, and make them searchable.

Our role-based access control means you can give your security and engineering teams access to those pieces of the SBOM lifecycle that they need.