Why Using SCA to Build Your SBOMs is a Risky Proposition

Organizations that generate software bills of materials (SBOM) by feeding software manifests into software composition analysis (SCA) tools only capture 49.91% of the components that make up final, published software packages, a research study from ReversingLabs revealed.

That leaves developers and security teams with a serious gap in visibility, revealing just over half of a software package’s components, said Andy Lewis, technical marketing manager at RL.

You’re supposed to end up with a complete inventory of everything in your environment, but if a software manifest is your only input you’ll be missing a lot — and taking on a lot of risk.

Andy Lewis

Relying on SCA scans of software manifests “creates significant security risks that impact organizations' ability to protect their software supply chains effectively,” the research report, “Manifest File Misconceptions: The Gaps in SCA-Based SBOMs," states. Security teams can’t identify and remediate vulnerabilities or malware in unidentified components when they don't know that those components exist.

Get the Report: Manifest File MisconceptionsSave Your Seat: June 26 Webinar

What Gets Missed — And Why

SBOMs should provide a complete inventory of all software components and dependencies in a given software package. Assuming the SBOM is complete, security teams can use CVE matching to identify risky components, monitor open-source licensing, map dependencies across the software supply chain, and ensure that the software meets regulatory requirements.

Software manifest files (such as package.json, pom.xml, etc.), contain all critical metadata for a given software package. They are designed to organize and guide the software development process, but they’re not intended to provide a complete inventory of the contents of the final software package.

SCA tools scan software manifests as input in order to generate an SBOM as output. The tools can also examine the source code, compare it against a database of known malicious code, and identify components that present security risks.

Unfortunately, most SCA tools were designed to examine only open source components, not the commercial or proprietary code that’s typically in the mix with today’s complex software packages. They can’t track the web of dependencies between those components, and they miss any components that have been deployed with the software package but aren’t in the package itself. “Add in AI, ML, SaaS and cryptographic components and you’re left with a very incomplete picture,” Petrillo says.

To make matters worse, the software manifests on which SCA tools rely tend to be created early in the software development lifecycle, so they don’t capture components and dependencies introduced later in the process. That’s a problem because developers often override manifests by adding or removing items as the development process proceeds.

Incomplete manifests can also slow responses to critical security incidents. For example, When the log4j vulnerability was first revealed, organizations that lacked complete software visibility spent days or weeks checking to see if their systems were vulnerable before they could perform any remediation. By contrast, those with complete visibility could immediately determine whether or not they were affected and begin to deploy any needed patches immediately.

Complex Binary Analysis Fills the Gap

A better approach is to use complex binary analysis of the components in the final shipping package to create an SBOM and identify risks including the presence of malware, tampering, exposed secrets, and vulnerabilities. It goes beyond open source to include proprietary and commercial software components.

ReversingLabs’ Spectra Assure, the technology leader in this space, performs an analysis of the final software package’s binary code to identify all of the components and dependencies, providing a complete list of ingredients. It deconstructs the software into its component parts, compares those against RL’s largest threat repository of of malware, and issues a SAFE (Software Assurance Foundational Evaluation) report that includes details of potential risks and threats, including “known good” and “known bad” code, as well as any indications of software tampering.

Because Spectra Assure analyzes binary files, it quickly identifies all components — including those missed by an SCA scan of the software manifest. It also builds a more comprehensive, extended SBOM, or xBOM, that includes a BOM for SaaS, AI/machine learning and other components and compares that against what was declared in the software manifest.

Spectra Assure isn’t just for software publishers. Because it analyzes binary files without the need to access the source code, software publishers can use it to ensure that the SBOM is complete and that the final shipping code doesn’t include hidden risks — an enterprise software buyers can do the same.

Spectra Assure Provides Unparalleled Visibility

Relying on SCA tools alone to build an SBOM is insufficient, especially as the complexity of software supply chains continues to increase. The best way to create a complete SBOM and lower software supply chain risk is through comprehensive software component identification of a software package’s final binary files. But Spectra Assure doesn’t just identify all package components — it detects malicious code and evidence of software tampering in the final code, before the developer ships or deploys the software.

By using Spectra Assure to perform complex binary analysis you can move the visibility needle in your SBOM from 49.91% to complete transparency.

For a detailed explanation of Spectra Assure complex binary analysis and a deep dive into three real-world scenarios where complex binary analysis could have made the difference, read the ReversingLabs report “Manifest File Misconceptions: The Gaps in SCA-Based SBOMs.”