Dependency analysis for Java applications
jbom, an open source project hosted by the Eclipse Foundation, generates SBOMs from any Java project. Why is this useful?
Supply chain security is all the rage right now. We examined the consequences of the Linux Foundation’s response to supply chain attacks, as well as ways to mitigate them:
In order to create useful software, we do not reinvent the wheel, but build on the work already done, which comes in the form of libraries. The problem is that even a medium open source project can have a lot of these dependencies, which themselves depend on others and form a long chain. It’s not a problem by itself, unless malicious code or a security hole finds its way anywhere in this chain.
As such, Software Bills of Materials (SBOMs) are a hot topic as they are now widely recognized as a tool to defend against supply chain attacks, especially in the United States since President Biden’s May 2021 Executive Order to Improve the Nation’s Cybersecurity.
An order requiring vendors to provide a Software Bill of Materials (SBOM) as part of the government procurement process. The SBOM covers the software components used in federal agency software applications in amazing detail. The reasoning is that this would enable them to immediately find out if there are vulnerabilities, should they occur, in one of the components used by their software.
In practice, an SBOM:
- Lists all software components that comprise an application, service, API, or runtime.
- Contains detailed information about individual software components.
- An official machine-readable record of all proprietary and third-party integrations within the software.
We detailed an example of how SBOM enhances security and facilitates instant alerts in “Tracking 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
“exact data on where the vulnerability was introduced and where it was patched”.
OSV augments CVEs by adding accurate vulnerability metadata to facilitate querying (using package versions or commits). It also describes bugs according to a cleaner vulnerability schema.
Google Security details how SBOMs were used against the OSV database to detect vulnerabilities in open source software:
Creating SBOM is only one half of the story. If an SBOM is available for a given piece of software, it must be mapped to a list of known vulnerabilities to find out which components may pose a threat.
By connecting these two sources of information, consumers will not only know what’s in their software, but also the risks and whether they need to fix any issues.
To connect the SBOM to the OSV database, the spdx-to-osv tool was used, which takes the SBOM document in SPDX format to query the database for known vulnerabilities of the used modules. One more step in protecting your software supply chain.
There are many tools that can perform software composition analysis, and one such tool is Eclipse’s Foundation Jbom, which generates runtime and static SBOMs for local and remote Java applications.
Simply put, there are a few options for creating SBOMs:
- GOOD — Static SBOM ( source ) – This works well, but you will miss runtime libraries from application servers and runtime platforms. It also picks up libraries that don’t matter, like test frameworks. You will have no idea which libraries are active in the running application.
- BETTER — Static SBOM (binary) – Parts will still be missing because the code is in multiple places. It probably also includes directories that don’t matter but happen to be on the file system.
- BEST – Runtime SBOM – This is what “jbom” is all about. Runtime SBOM is the most accurate approach because it captures the exact libraries used by the application, even if they are on the platform, application server, plugins, or anywhere else. This approach can also include details of invoked services and active libraries.
Jbom works with Instrumentation software, which is a big advantage over other solutions. Instrumentation allows security analysis to be performed within the running application – by observing the execution of the code. Others scanning filesystems, repositories, or repositories can easily fail to detect directories accurately because:
- a library could be buried in a fat jar, a war or an ear
- We can shade the library in another jar
- library can be in the application server, not in the code repository
- library can be part of dynamically loaded code or plug-in
- a library can have many different versions with different class loaders in a single application
- directory can be masked using slf4j or other layers
- library can be renamed, recompiled or otherwise modified
If you run the scan, none of these problems will occur.
jbom can be used in the following ways:
Create an SBOM for each locally running Java process
java -jar jbom-1. Jar 2
Create an SBOM for each Java process on a remote host
java -jar jbom-1. Jar 2 -h 192. 168. 1. 42
Create SBOM for a local archive file (. jar , . war , . ear , . zip )
java -jar jbom-1. 2. jar -f mywebapp. jar
Create an SBOM for all archive files in the directory
java -jar jbom-1. 2. jar -f mywebapp
Create 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
Finally, even if SBOMs are not mandated by regulation, creating one for projects can be useful for faster identification of vulnerabilities and for debugging, managing dependencies, or resolving conflicts.
Run jbom against production and see the dependency analysis at runtime; there is nowhere to hide. . .
You can track open source vulnerabilities with Google’s OSV database
Protect your software supply chain with Gitsign
Wolfi Linux (Un)Distribution ensures the software supply chain
To stay informed about new articles from I Programmer, subscribe to our weekly newsletter, subscribe to our RSS feed, and follow us Twitter, Facebook or Linkedin.
or send your comment to [email protected]