Getty Images/iStockphoto
How to successfully scale software bills of materials usage
Companies must plan properly when implementing software bills of materials at scale. Accomplish these three goals to keep SBOMs updated, accurate and actionable, despite complexity.
Software bills of materials can provide value to security teams. Consider the recent Apache Log4j vulnerability, for example. How much time did companies spend asking individual vendors whether they used the library versus addressing the vulnerability? If security admins could know immediately and with a high degree of accuracy which components in their software ecosystems relied on Log4j and which did not, they could have swiftly mitigated the issue.
In this example, security teams should know fairly quickly where first order Log4j usage occurs -- they could have looked directly at their libraries and confirmed use by talking to developers. Second order dependencies, such as using a product or software library that depends on Log4j, were probably also fairly easy to track down. From there, it only gets harder to determine where Log4j was used from third, fourth and fifth order dependencies. Would security teams know if a library in use calls an API running on a framework that uses a shared object that's linked with a static library that's vulnerable? Probably not without taking the time to do some major digging.
There's also the pace of development and rapidity of change to consider. DevOps processes and continuous integration/continuous delivery (CI/CD) have affected how quickly software is developed and the time to market for software updates. Each new version or update of software can change the dependencies used. Therefore, each new release can bring about changes to what a given component or product uses and what is packaged with it. Likewise, the "release early, release often" mantra of open source products can mean many new versions in rapid succession, each of which could deprecate existing dependencies or bring in new ones.
Software bills of materials (SBOMs) aren't a fire-and-forget activity. Certain elements need to be thought through and planned, especially when it comes to SBOM use at scale. This is true for software providers creating SBOMs for their customers and regulators, as well as organizations using SBOMs to keep track of the software supply chain they rely on.
Keep the following three goals in mind when scaling up SBOM processes.
1. Use automation to keep SBOMs updated and organized
When it comes to creating SBOMs, automation is a given. Individual software packages can be quite complicated. As mentioned, dependencies almost certainly have their own dependencies and so on. Even a simple piece of software can contain hundreds or thousands of dependencies. Keeping them all straight and organized manually is a tall order.
SBOM standards, such as CycloneDX, Software Package Data Exchange and software identification tags, imply automation. The formats are machine-readable and enable nesting to help address exactly this issue. In situations where automated processes exist -- for example, as part of a DevOps toolchain or CI/CD pipeline -- consider introducing an automated step, such as execution of a software composition analysis (SCA) tool post-build to help automate. Thus, each build of the software automatically results in a new breakdown of dependencies.
2. Undergo manual reviews to increase accuracy
Key to the utility of an SBOM is its accuracy. Unfortunately, the data coming out of an SCA or other analysis tool might be limited in its awareness. Software that is needed for a component to run -- but that isn't part of the codebase -- might not be found via these automated tools. This undermines accuracy.
Consider Python code built for a framework such as Django, for example. An SCA or static application security testing tool might capture the specific libraries and modules that Python code uses, but depending on the tool, it might not flag Django itself as a dependency. Have a plan for situations like this -- for example, include a human-readable information overlay that includes this information as context, similar to the first identification section in a material safety data sheet or other substance hazard communication. This way, teams have the modules that are automatically detected by the tools in use, as well as the implicit dependencies and usage assumptions to accompany the machine-readable document. This can be helpful both to the reader but also to security admins down the road when and if assumptions or usage changes.
3. Make SBOMs actionable and accessible
SBOM consumers need the information to be actionable and accessible. SBOMs have come under justified criticism lately: They aren't actionable, they rely on vendors -- some of whom aren't willing to share the information -- and so on. All of these speak directly to accessibility.
As the requester of SBOM data, have a plan for how to use the data before requesting it. Imagine for a moment suddenly being sent an SBOM for every piece of software in use. Moreover, say vendors started sending updates for every release -- even dot releases. Security teams probably wouldn't be able to productively use that information.
To properly use the information, it must be able to be parsed first. Since there are multiple standards -- not to mention vendors producing human-readable reports or spreadsheets -- this can take some doing. If teams want the data in human-readable format, research tools that enable them to view it. In most scenarios, teams will want some level of integration with systems and processes already in place, such as inventory systems, asset tracking and software registries. Teams can then search across the software to find what's using a particular vulnerable dependency. The value is increased further if teams can integrate that with ticketing or work-tracking measures to automatically schedule upgrade or patching work in the event that a vulnerability is discovered.
