As organizations open up the software bill of materials (SBOM) to their security teams, there is a future of the SBOM as source data for threat intelligence is becoming abundantly clear. Applying intelligence to SBOM data is a natural step in a world where DevOps and DevSecOps teams use a range of tools and technologies such as AIOps and analytics to gain actionable intelligence from their backend data.
Here’s a look at how the SBOM and threat intelligence spells the future of software supply chain security:
We’re reaching a critical point with the role of the SBOM in today’s enterprise. After the SolarWinds hack, it’s incumbent for government agencies and businesses to open up the SBOM to their security teams. Options to make this work include:
- Offer training to your internal teams about SBOM basics with an accompanying briefing about what your organization expects to get
- Give your security team the tools and support to make the SBOM the first “gate” before third-party software code and components enter your software supply chain.
- Put in the tools and processes to generate SBOMs as part of your DevSecOps toolchain and processes
Threat Intelligence Today
Threat intelligence, also known as cyber threat intelligence (CTI), is organized, analyzed, and refined information about current or potential attacks according to Whatis.com. An entire industry has arisen around threat intelligence that includes platforms, open source, and fee-based data feeds.
Choosing a threat intelligence platform means knowing your goals and requirements for data collection, and how the platform presents its threat analysis and reports to your security team. If you already have a threat intelligence platform in place that your security team manages, it’s time to work with your team and, if necessary, the vendor, to explore potential integration options for pulling in SBOM data into your threat intelligence reporting. There’s not a single hard and fast answer here (at least not yet) but the platform application programming interface (API) is the logical starting point.
The SBOM and Threat Intelligence in the Future
The SBOM is an under-realized threat intelligence option. For example, let’s say that you want to integrate an open source software (OSS) project into an enterprise software project you have underway for an important customer. The project is highly functional and shows excellent potential to serve as a key feature in your solution. Then the OSS project suffers a security incident. There are also vulnerabilities appearing in the same OSS project weekly.
A commercial or open source vulnerability scanner can only tell you whether some piece of that OSS project is vulnerable. It doesn’t give you any sort of status or analysis that alerts to the project’s history in the “vulnerability of the week club.”
While that OSS project with the vulnerability a week remains appealing, that there’s an OSS project with vulnerabilities is lost on the vulnerability scanner. You have a commercial option that fills most of the requirements but has only suffered two vulnerabilities over its entire lifetime. That’s probably the safer bet. We need to reach a point where we couple SBOMs with intelligence to help raise the role and importance of SBOM as a key security data source.
Even if you have the staffing budget to hire 100 people and their whole role in life is to determine the threat status of your open source dependencies, they still need a technology solution that enables them to narrow down what they examine as third-party software enters your pipelines.
As businesses and governments continue to tackle the rise of software supply chain attacks, they and the vendors that serve them need to look at coupling SBOMs with some form of intelligence. Threat intelligence is a logical bet. It’s time for threat intelligence platform vendors and their customers to work collaboratively on solutions to add SBOMs to their feeds by default.
Do you want to generate SBOMs on the OSS in your development projects? Download Syft, our open source CLI tool for generating a Software Bill of Materials (SBOM) from container images and filesystems.