In this blog post I discuss how I migrated an old Netbeans project (Specifically ReportCompiler) to retrofit Maven and to integrate OWASP’s dependency check into the build process.

You can get ReportCompiler:

• Binary – for users
• Source Code – for contributors or the curious

What is the target?

I made ReportCompiler a long time ago (long enough that Java was a sane choice). It is in no way complete and has adorable missing or half implemented thoughts throughout it.

It will import “.nessus” XML files and various other vulnerability scanners too. I use it mostly as a Nessus viewer since my gripes with the UI experience in browser are legion. I have a love affair with it in particular though because it has saved me an unbelievable amount of time over the years even accounting for the initial intense development time.

I do not use it every day like I used to and so the project is only lightly supported by me.

Getting up and running

• Open up netbeans (I originally designed the GUI in this so it kind of needs to be netbeans unless another GUI editor works just as well?).
• Create a new “maven” project.
• Copy the source code from your previous project into the source folder.
• Deal with any package renaming because of this movement. They will be highlighted in red at the top of every class file.
• Check import statements for warnings. Each underline here points to a dependency we will need to include using maven now.
• For each import error copy the package name for example “org.python.util.PythonInterpreter” and google it with the word “maven”. This will find the package that you need to import. For example:

• Clicking on the top result will show you the information about the relevant maven package:

• Notice that in this example the latest version was newer as highlighted. Click on the newer version. Then copy and paste the “<dependency>” tag into your projects “pom.xml”.

• After adding each dependency build the app again and watch that import statement fix itself. Repeat until all the red underlines have vacated your project.

Given the age of ReportCompiler there were a few deprecation warnings around the use of Vectors etc. I did not massively feel the need to redo the code for that since it has Vectors in pretty much every single area of the application. Now I feel the developer pain. Some day the rug will be pulled but for now we are golden. Vectors survive for now.

By the end of this my application compiled and executed. The only thing that did not seem to work was the resources folder including the risk icons. I wrapped the code loading these icons in a “try catch” statement to see a more verbose error message and to ensure the app loaded despite the wonky icons.

Bundling the app and dependencies into a single Jar

To fix the wonky icons I needed to ensure the resources were included inside the Jar file or otherwise copied during the build.  The simplest route I found was to use the “maven-assembly-plugin”. Adding this to the “pom.xml” file resulted in a self-contained single jar file with all resources:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-assembly-plugin</artifactId>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>single</goal>
      </goals>
      <configuration>
        <archive>
          <manifest>
            <mainClass>
            com.cornerpirate.reportcompiler.GUI.MainWindow                                
            </mainClass>
          </manifest>
        </archive>
        <descriptorRefs>
          <descriptorRef>jar-with-dependencies</descriptorRef>
        </descriptorRefs>
        <finalName>ReportCompiler</finalName>
        <appendAssemblyId>false</appendAssemblyId>
      </configuration>
    </execution>
  </executions>
</plugin>

In my new project the image icons were located under the “src/main/resources” folder. Maven tutorials all say this is where to put them:

To access these resources I modified my code to use “getClass().getResource()” as shown:

try {
    this.critical_risk_icon = new ImageIcon(getClass().getResource("/critical-icon.png"));
    this.high_risk_icon = new ImageIcon(getClass().getResource("/high-icon.png"));
    this.medium_risk_icon = new ImageIcon(getClass().getResource("/medium-icon.png"));
    this.low_risk_icon = new ImageIcon(getClass().getResource("/low-icon.png"));
    this.info_risk_icon = new ImageIcon(getClass().getResource("/info-icon.png"));
    this.no_risk_icon = new ImageIcon(getClass().getResource("/none-icon.png"));
    this.computer_icon = new ImageIcon(getClass().getResource("/computer-icon.png"));
    this.show_highlights = showHighlights;
} catch (Exception ex) {
    ex.printStackTrace();
}

Terrific. Now the risk icons were loading beautifully.

Integrating OWASP’s Dependency Check

The reason I was moving to maven was to add sanity into the dependency management. The version of ReportCompiler to date was stuck with whatever jar files I downloaded back when I wrote the project. I consoled myself with the fact that none of the code is remotely accessible which reduced the threat profile.

But here was a Pentester clearly not practising what they preach. Yelling “patch all the things” by day while my barn was on fire. This gave me an opportunity to experience life from the other side of the fence for a bit. Which we should all practice regularly.

OWASP’s Dependency Check does an excellent job of listing known vulnerabilities in dependencies. I have tried it out in a few different contexts over the years and wholeheartedly recommend it to customers. It will not solve security problems on its own. But it will highlight easily fixable weaknesses from third party libraries.

I added this to my “pom.xml” to add it into my build process:

<plugin>
  <groupId>org.owasp</groupId>
  <artifactId>dependency-check-maven</artifactId>
  <version>5.3.2</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

The goal was set to “check”. In this configuration dependency-check runs when the application is built and an HTML report will be created in the target folder next to my jar file. You can set the build to halt if risks over a certain CVSS score appear which I would recommend for an actively maintained project which is mission critical.

Below is an example report kicked out during a build with some CVE’s to show:

I went through all my maven dependencies and ensured the most recent releases were included (or so I thought). By running “clean and build” again the vulnerabilities related to Apache POI disappeared. Partial success!

My “pom.xml” did not point specifically to any of the remaining vulnerable libraries meaning that they were most likely “dependencies of my dependencies”. I shook my fist at the sky and cried out about how the supply chain will always get you.

I found that netbeans will draw a handy dependency graph. In “Project” view expand the “Project Files” folder and click on “pom.xml” and then on the tab labelled “Graph” along the top to see this:

I could now throw shade at “docx4j” 6.1.2 which was build with Apache Commons Compress version 1.12 when version 1.20 is available. On looking into this 6.1.2 was nowhere near the latest version of “docx4j”! There were newer ones with slightly different names available. Hot swapping that out solved the “apache-commons-compress” related CVEs.

The most recent maven release of “docx4j” (version notes for 11.1.8) was compiled with several outdated dependencies. Unfortunately “jackson-databind-2.9.9” was included and vulnerable to 26 known CVEs. There was no danger of fixing this soon and it would most likely require opening a ticket on the docx4j project.

Drilling into the others I found that “jexcelapi” had a vulnerable version of “log4j” as shown in the graph below:

Looking into it the project for “jexcelapi” was no longer supported since it was last released in 2009. A prime candidate for being entirely replaced. A quick google found that Apache POI is the new hotness. I cutout the old library and went for something that was supported.

At the end of this process I had tried my best but ended up with vulnerabilities via docx4j’s jackson-databind dependency. C’est la vie.

Fixing vulnerable Dependencies is Hard

After thinking about it I can see four ways to proceed with fixing all known CVEs in my dependency chain:

• Do I really have the most recent release of my dependency? Look up the actual project’s page and see if there is a later release.
• Can I contact the maintainer and get them to update their public build with the newer dependency baked in? This would fix the issue and eventually filter back into the maven ecosystem. Probably need to do that for docx4j.
• Do I need that dependency? If it is a minor feature and you are all up to date maybe you can remove the feature or implement it another way. As per jexcelapi.
• Can I build my own version which is secure (recompiling with the latest libraries)? However, this instantly breaks the mavenness of the dependencies

Now I imagine what it is like when a Pentest report lands heartlessly saying “update your dependencies”. It is clear that this is still a tricky problem in 2020.

This is the end

That was the end of the process. The application compiled and had the same bugs it had before but now had more up-to-date dependency management. Folks may now be more inclined to contribute to the project, and I am more inclined to support it.

Hopefully you found something of value in the tale.