Scanning Ant-Based Java Projects For Know Vulnerabilities with MergeBase

Introduction

Ant was Java’s original build system. Ant was developed internally at Sun Microsystems around 2000 to help build the original Tomcat JSP server. I vaguely recall learning many years ago that James Duncan Davidson and Jason Hunter (now of JDOM fame) were the main culprits behind Ant. Of course, we’re now in 2022, and Ant has long since been replaced with Maven. But from 2000 to 2010, Ant was very popular.

Even today, many projects, especially internal corporate Java projects, still use Ant. Why fix something when it’s not broken, right? Unfortunately, important application security tools for SBOM generation and known-vulnerability scanning currently don’t work with Ant.

But MergeBase does!

In this article:

Scanning Ant-Based Java Projects With MergeBase

Unlike Maven, Ant does not include any built-in dependency resolving and downloading.  With Ant-based java projects, developers are their own when it comes to specifying and retrieving important re-usable libraries required to build and deploy their software systems. Because it’s up to developers, there’s a huge mishmash of approaches and traditions across the Ant universe – it’s a total free-for-all! (Maven was designed from the ground-up mainly to solve this pain and chaos). 

Nonetheless, there is one constant we can count on:  when Ant is finished building a software system, the end-result will be a deployable runnable Java software artifact, including all of its required libraries.  MergeBase leverages this fact to achieve a reliable “post-build” known-vulnerability SCA scanning solution for Ant projects.

MergeBase uses a powerful signature-based matching algorithm to accurately identify Java dependencies. Unlike binary fingerprints (like SHA-2 or MD5), our matching algorithm is stable in the face of typical library permutations (e.g., cryptographically signed vs. unsigned libraries, compiler variations, and even different timestamps in zip-file metadata).

Our matching algorithm is also able to find versions “between” versions – for example if your developer decided to grab a pre-release version of Apache Commons HttpClient 3.0 directly from “trunk” and threw that into your Ant lib directory, MergeBase’s library-identification logic can handle that.

Competing Scanners vs. Ant

Most competing scanners are not able to scan Ant-based Java projects. They exit with error messages like these:

• “Could not detect supported target files”
• “Detected supported file(s) in ‘.’, but there was a problem generating a dep-graph.”
• “No dependencies were identified”

This is because existing commercial scanners probe projects build scripts for dependency coordinates. Of course, MergeBase is happy to operate in this mode as well when it’s available, but we also offer a pure “files-on-disk” mode of scanning. Philosophically, we believe a “files-on-disk” scan mode is critical because that gives you the ground-truth: the actual libraries included in your application’s deployment!

Of course, your Maven pom.xml scripts and NPM project.json files and yarn.lock files say useful, interesting things about your system’s dependency graphs, but there’s nothing stopping post-build processes from further adjusting the deployment context by deleting, transforming, copying, or even downloading additional dependencies outside of normal build processes.

Turns out our “files-on-disk” philosophy is also perfect for Ant-based Java projects. When an Ant-based application is finished building, all of its dependencies will be packaged up for deployment. A powerful signature-based scanner like MergeBase can then figure out exactly which Maven-coordinates correspond to each of these files.

Of course, Ant projects don’t use Maven-coordinates, but the industry has now standardised around these (e.g., see: PURLs). Known-vulnerability reports and SBOM exports are expected to refer to Maven-Central dependency coordinates. Fortunately, MergeBase is able to accurately map the random Jar files sitting across various “lib/” directories in an Ant-based Java project back to Maven-coordinates.

Thanks to these Maven-coordinates, MergeBase can then determine the known-vulnerabilities in your libraries that you need to be aware of, as well as giving you any SBOM reports (in CycloneDX or SPDX formats) you might also need to comply with current software engineering standards.

Using MergeBase To Scan Ant Projects

In this section, we’ll show you explicitly how you can use MergeBase to scan Ant-based Java projects.

First, make sure your Ant project successfully builds! Once your Ant build completes, you can now run MergeBase. When scanning Ant projects, we recommend using MergeBase’s “–binary” and “–all” flags. This way, even zips inside zips and jars inside wars will be examined.

MergeBase Scan Example:

$ java -jar mergebase.jar –name=myProject –group=myGroup –binary –all

Running recursive binary scan. This could take some time especially if *.dll/*.exe files are detected.
Scanning - completed
Saving application profile (1 kb) to MergeBase Demo

Vulnerable Files Overview  
\=========================  
  
VIOLATION (2)  
\-----  
CVE-2016-1000343, CVE-2016-1000342, 2 more... libs.zip!/bcprov-ext-jdk15on-151.jar (org.bouncycastle/bcprov-ext-jdk15on@1.51)  
CVE-2022-23307, CVE-2022-23305, 4 more... lib.zip!/log4j-1.2.13.jar (log4j/log4j@1.2.13)  
  
WARNING (4)  
\-----  
CVE-2020-26939, CVE-2020-15522, 7 more... libs.zip!/bcprov-ext-jdk15on-151.jar (org.bouncycastle/bcprov-ext-jdk15on@1.51)  
CVE-2020-13956, CVE-2012-6153, CVE-2012-5783 libs.zip!/commons-httpclient-3.0.jar (commons-httpclient/commons-httpclient@3.0)  
CVE-2020-15250 libs.zip!/junit4-4.11.jar (junit/junit@4.11)  
CVE-2020-9488 libs.zip!/log4j-1.2.13.jar (log4j/log4j@1.2.13)

Creating an SBOM Report

Simply add the “–sbom” flag to the “java -jar mergebase.jar” command above. Alternatively, you can also download the SBOM report directly from your MergeBase dashboard. All MergeBase scans are also stored in your MergeBase dashboard to help keep you up-to-date in case any new vulnerabilities are discovered in between scans.

A Quick Scanner Bake-Off

We have put together a small buildable Ant-based Java project for anyone who would like to play with competing scanners. You can download this project here. It’s an old Apache-2.0 licensed Java open-source project I created in 2006!

To build it, run the following steps:

1. Download it and unzip it.
2. cd ./not-yet-commons-ssl-0.3.17
3. ant clean
4. ant all

Scanning It With MergeBase:

Take a free MergeBase trial, and then download the “mergebase.jar” CLT. Run the following command in the “./not-yet-commons-ssl-0.3.17/” directory (after building it first!):

$ java -jar mergebase.jar –binary –all .

The resulting output is the same as above (24 vulnerabilities found circa September 2022). Of course, that will change as more vulnerabilities are discovered with each passing year!

Snyk?  “There was a problem”

Snyk does not appear able to scan this project:

$ snyk test --scan-all-unmanaged .  
  
Failed to get maven dependency for './not-yet-commons-ssl-0.3.17.jar'. 
No package found querying [https://search.maven.org/solrsearch/select] for sha1 hash '4858e51d5290a3640f706ed0c7db8eda5c646899'.  
Detected supported file(s) in '.', but there was a problem generating a dep-graph.
 No Maven artifacts found when searching [https://search.maven.org/solrsearch/selec].

Mend (a.k.a. WhiteSource)?  “No dependencies were identified”

Mend also does not seem to be able to scan this:

$ ws scan –extended .  
  
Initializing:  
File system scan is not allowed, only package manager dependencies resolution is performed  
Scanning: /opt/automated-benchmark/ssl/not-yet-commons-ssl-0.3.17 \[...../\]  
Retrieving: Security vulnerabilities and compliance information \[...../\]  
No dependencies were identified

Conclusion

Many important Java systems are still built using Ant, but unfortunately, most application security tools are not able to understand and scan such systems.  MergeBase, however, uses a powerful signature-matching algorithm that works wonderfully well with Ant-based Java projects!

p.s.  We published our matching algorithm in a peer-reviewed software engineering journal in 2013 if you would like to implement it yourself (it is not patent protected). Look for “Software Bertillonage, Determining the provenance of software development artifacts” by Davies et al. in Springer’s Journal of Empirical Software Engineering, 2013.  As an author, I’m allowed to send free full-text copies of this journal article to anyone who would like to see it.

p.p.s. Speaking of provenance, I bet you didn’t know Davies was my maiden name!  😉