jbom, an open source project hosted by the Eclipse Foundation generates SBOMs from any Java project. Why is that useful?

Supply chain security is all the rage right now. We've taken a look at the implications as well as the ways of mitigation according the Linux Foundation's answer to supply chain attacks:

To build useful software we don't reinvent the wheel but we base on work already done coming bundled in the form of libraries. The problem is that even a mediocre open source project can have loads of such dependencies which themselves depend on others , forming a lengthy chain. Not a problem per se unless malicious code or security vulnerability finds its way anywhere in this chain.

As such, SBOMs (Software Bills of Materials) is a trending topic because it is now widely recognized as means for defending against supply chain attacks , especially in the US since President Biden's Executive Order on Improving the Nation’s Cybersecurity as of May of 2021.

The order required by vendors to provide a software bill of materials (SBOM) as part of the government’s procurement process.  The SBOM contains in excoriating detail the software components which are utilized in the federal agencies software applications. The reasoning is that it would render them capable of immediately finding out if there's vulnerabilities ,in case one occurs , in one of the components their software uses.

In practical terms an SBOM :

• Lists all the software components that comprise an application, service,  API, or runtime environment.
• Contains detailed information about each software component.
• Is a machine-readable official record of all proprietary and third-party integrations within the software.

An example of how a SBOM enhances security and facilitates immediate alerts we detailed in "Track Open Source Vulnerabilities With Google's OSV Database".

The Open-Source Vulnerabilities , OSV , database is a new , open source , project from Google that goes beyond the current state of CVE tracking , which provides

"precise data on where a vulnerability was introduced and where it got fixed".

OSV complements CVEs by extending them with precise vulnerability metadata , making it easier to query (using either package versions or commits). Furthermore it describes bugs according to a cleaner vulnerability schema.

Google Security details how they used SBOMs against the OSV database to find vulnerabilities in open source software:

Generating an SBOM is only one half of the story. Once an SBOM is available for a given piece of software , it needs to be mapped onto a list of known vulnerabilities to know which components could pose a threat.

By connecting these two sources of information , consumers will know not just what’s in their software , but also its risks and whether they need to remediate any issues.

To connect the SBOM to the OSV database , they used the spdx-to-osv tool which takes SBOM document in SPDX format to query the database for known vulnerabilities in any of the modules used. One step more in protecting the software supply chain.

There are many tool that can do software composition analysis and one such tool is Eclipse's Foundation Jbom which generates Runtime and Static SBOMs for local and remote Java apps.

In simple terms you've got a few options for generating SBOMs:

• GOOD -- Static SBOM (source) - This works fine , but you'll miss runtime libraries from appservers and runtime platforms. You'll also include libraries that don't matter like test frameworks. You'll also have no idea which libraries are actually active in the running application.
• BETTER -- Static SBOM (binary) - You'll still miss parts , because code can be located in a variety of different places. And you'll also probably include libraries that don't matter but happen to be on the filesystem.
• BEST -- Runtime SBOM - This is what 'jbom' is all about. Runtime SBOM is the most accurate approach as it captures the exact libraries used by the application , even if they are in the platform , appserver , plugins , or anywhere else. This approach can also include details of services invoked and which libraries are active.

Jbom works with Instrumentation which gives it its big advantage over the other solutions. Instrumentation allows you to do security analysis from within the running application - by watching the code run. Others who scanning file systems , code repos , or containers could easily fail to detect libraries accurately since a:

• library could be buried in a fat jar, war, or ear
• library could be shaded in another jar
• library could be included in the appserver , not the code repo
• library could be part of dynamically loaded code or plugin
• library could be many different versions with differentclassloaders in a single app
• library could be masked by use of slf4j or other layers
• library could be renamed, recompiled, or otherwise changed

By doing the scanning at runtime you have none of those issues.

jbom can be used in the following ways:

Generate an SBOM for all Java processes running locally

java -jar jbom-1. 2. jar

Generate an SBOM for all Java processes on a remote host

java -jar jbom-1. 2. jar -h 192. 168. 1. 42

Generate an SBOM for a local archive file (. jar , . war , . ear , . zip)

java -jar jbom-1. 2. jar -f mywebapp. jar

Generate an SBOM for all archive files in a directory

java -jar jbom-1. 2. jar -f mywebapp

Generate an SBOM for all archive files in a remote directory

java -jar jbom-1. 2. jar -h 192. 168. 1. 42 -d /var/tomcat/webapps

In the end, even if you're not required by regulation to submit SBOMs , generating one for your projects can be valuable in identifying vulnerabilities faster as well for debugging purposes and dependency management or conflict resolution.

Run jbom against your production and watch the dependency analysis happening at runtime; there's nowhere to hide. . .

More Information

jbom

Related Articles

Track Open Source Vulnerabilities With Google's OSV Database

Protect The Software Supply Chain With Gitsign

Wolfi Linux (Un)Distribution Secures The Software Supply Chain

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info