If you have an ear turned toward cybersecurity trends, you’ve probably heard a lot of chatter about disruption in the software supply chain. Critical vulnerabilities within prevalent open-source packages like Log4j and Log4Shell continue to emerge. Furthermore, typosquatting and malicious code commits around open-source repositories are becoming all-too-common.
The risks inherent in widely used open-source packages have woken the industry up to just how little oversight there is over much of the software the world depends on. This problem has even influenced the White House to issue an Executive Order to increase transparency by mandating the use of the Software Bill of Materials (SBOM).
I recently synced with Brian Fox, CTO of Sonatype and OpenSSF Governing Board Member, to discover how greater use of SBOMs could help avoid further disruption in the software supply chain. According to Fox, SBOMs will be integral to increasing transparency throughout the software industry. However, it will likely take years for most companies and package managers to enforce their use. Thus, organizations must take preemptive measures to audit their surface area in the short term.
What Are SBOMs?
A Software Bill of Materials (SBOM) is an attempt by the software industry to provide more transparency into the dependencies and components behind software applications. Similar to an ingredient list on a good label, an SBOM is a manifest of the ingredients in a software package.
Today, fewer and fewer applications are built from scratch, says Fox. Instead, applications are assembled using varying underlying components. Rather than reinventing the wheel, it’s more common to reuse a UI framework, database, or compute runtime, for example. The integrations and unique code written on top only represent the tip of the iceberg — Fox estimates that upwards of 90% of the code in a modern app is borrowed from open-source software.
Why SBOMs, and Why SBOMs Now?
Improving transparency around these underlying components is becoming increasingly essential to comprehend risk. A lack of knowledge is a surefire way to keep known vulnerabilities from being patched. This is evidenced by findings that the Log4Shell remote control execution vulnerability remains unpatched months after its disclosure in most implementations.
“Most people don’t recognize they have all these open-source components or have a way to inventory them,” says Fox. This explains why, three months after disclosure, 41% of downloads from Maven Central Java package repository still had unpatched Log4j vulnerabilities. Comparatively, companies that have the tooling to see their surface area can remediate in the first few days after an incident, said Fox.
The Biden administration’s Executive Order started piquing the world’s attention around SBOMs, sending ripples throughout the private sector. Although this movement is a net positive for security awareness, it could take years to standardize SBOM creation. Those who wait and expect the problem to be solved are at risk, said Fox.
Preemptive Measures to Take Before SBOM Ubiquity
So, what preemptive measures should organizations be taking before SBOMs become more widespread? According to Fox, many methods exist to audit your software stack. One approach is conducting binary fingerprinting to reconstruct the bill of materials for a software ecosystem.
For example, one free scanning tool for digital forensics is OSS INDEX. Developers can use a range of plugins to scan compiled artifacts, such as a `.jar` file, to audit a project’s dependencies and discover known vulnerabilities. Of course, one caveat is that this process relies on a build manifest, adds Fox, but it’s still better than inaction.
SBOM Solutions Must Mature
Also, before organizations can leverage SBOMs, they will need a solution to store and access them. Unfortunately, little discussion is being given to how organizations will collate and store the potentially thousands of SBOMs that they will receive from external partners. Some crossroads have been made to create public repositories for SBOMs, like RKVST SBOM Hub. However, according to Fox, companies will inevitably require detached internal repositories for security reasons.
Furthermore, package managers like Maven Central, RubyGems, and NPM should have a responsibility to require SBOMs, says Fox. He expects repository providers will eventually require them, ecosystem by ecosystem. We’ve seen positive movement in the right direction recently with NPM utilizing Sigstore for supply chain security — “that’s the right approach to managing the next generation of signing and authenticity,” he said.
SBOMs: Just One Element of Software Supply Chain Protection
SBOMs are all that, but maybe without the bag of chips. SBOMs will be one crucial component of a defense-in-depth posture, but they have their limits. For example, in terms of serverless cloud functions, you can’t easily see what’s behind web-based API endpoints. It’s a black box, says Fox, and cloud providers might be hesitant to disclose the details behind proprietary services.
Furthermore, we’ve noticed a shift in attack patterns toward black hats attempting to steal open-source publisher credentials. With publisher credentials, one could more easily insert malicious code into popular libraries in the guise of a routine code contribution. SBOMs aren’t going to directly remedy typosquatting and backdoors created by these attack types, describes Fox.
Want more cybersecurity insights? Visit the Cybersecurity channel:
