Software developers and security professionals can all vividly remember the catastrophic Log4j vulnerability in December 2021. This event and the attacks that cascaded throughout organizations as a result – not to mention the sleepless nights trying to patch the vulnerabilities – sobered the industry to the risk open-source components bring and the way that software supply chains were often left dangerously exposed.
This feeling of vulnerability led to real action by many organizations, namely the development teams partnering more closely with security to harden their software supply chains with Software Bills of Materials (SBOMs). In fact, last year, there was a thirty percent increase in the building and maintenance of SBOMs by organizations. This was done in an effort to help organizations protect against risks introduced by open-source software by providing a list of components that make up the software product. Like a list of ingredients for a cake, SBOMs provide visibility into all the open-source and commercial “ingredients” that make up a software product.
There is still a long way to go, however, and many organizations simply don’t have the maturity and/or resources to implement the widescale use of SBOMS. That said, it is an essential step to ensuring your organization is secure. With that in mind, here are three key tips for any organization wanting to begin or improve its current implementation of SBOMs:
Tip #1: Make sure your SBOM has real-time remediation capabilities
Today’s modern economy is powered by open-source software, but the average application development project contains nearly fifty vulnerabilities spread across eighty direct dependencies. To make matters worse, indirect dependencies are much more difficult to track – each third-party library used in a project is bringing in deeper layers of code that software development teams must now track. It can take your team weeks or even months to remediate these issues by hand.
To address this persistent problem, a well-built SBOM solution should not only identify vulnerabilities but also remediate them in real time. SBOMs are there to allow developers to understand the building blocks of the shared libraries that comprise an organization’s applications and operating systems but to be truly effective the solution must go a step further by remediating what is found. With millions of open-source libraries in use, remediation capabilities are not just important but a necessity.
Tip #2: Leverage endpoint data
Let’s say your IT and security teams become aware of an open-source vulnerability in your software supply chain. The first step is to find out where this zero-day is located across all of your endpoints. Recent research found that sixty-eight percent of organizations experienced one or more endpoint attacks that successfully compromised data or their IT infrastructure.
Your endpoints are the assets that have an immediate impact on end users, so when creating an SBOM, you should be able to scan specific files on these endpoints. This functionality of your SBOM is what will set it apart to go the extra mile. Focus on finding the damage on all individual assets and go beyond a surface-level scan to examine the contents of individual files in your IT environment. How many endpoints have that specific vulnerability? Are you aware of all the devices in your network? What’s the status of the cleanup and discovery? Your SBOM should be able to help you answer these questions so that you can best manage your endpoint risk.
The two high-severity vulnerabilities discovered in the open-source library OpenSSL last November are perfect examples of the widespread impact a single vulnerability can have on the millions of endpoints that use the platform. By leveraging endpoint data to break down the composition of software, you’ll be able to root out weaknesses for this and similar software supply chain vulnerabilities.
Tip #3: Ensure the highest level of visibility
Granular, real-time visibility is a key requirement of an effective SBOM because you cannot protect what you don’t know you have. An SBOM shines light into the dark caves of your software. It should contain a built-out list of all packages and shared libraries used in each application, along with their version number. In this way, if a vulnerability is released for a specific package, you can either update that package, remove it, or contact the vendor to see if a new patch is available. When you have this bastion of knowledge at your disposal at a moment’s notice, you remain a step ahead of those looking to exploit the vulnerability. Take, for instance, the infamous Log4j vulnerability mentioned earlier. When it was discovered, many security researchers were blindly trying to exploit the vulnerability in their home labs, and they quickly discovered that many vendors hadn’t even reported that they’ve been affected. With an SBOM, this shotgun approach would have been eliminated because they would have visibility into exactly where they should conduct a more detailed proof of concept exploitation.
I expect shared library and software supply chain exploits to become more and more common as corporations continue to rely on open-source components to build code quickly. Although SBOMs are a core component of a software supply chain security strategy, the creation and maintenance of one fall mostly on the development team, so as a software developer, you should be learning how best to utilize one. SBOMs provide visibility and clarity that can be the difference between a minor operational hiccup and a complete disruption with long-term consequences. The spotlight will continue to shine on software supply chain risk in the years to come. As someone working along this supply chain, it’s imperative that you leverage the Software Composition Analysis (SCA) tools at your disposal, in particular the SBOM, so that your organization can catch the next OpenSSL or Log4j vulnerability before it spreads.
