FWIW, I use this tool for our builds. It has one unfortunate requirement: period downloads of every CVE ever filed. Ever. And it doesn't bother retaining the CVE databases from previous years which are very unlikely to change. So, roughly weekly, the entire database is wiped-out and re-downloaded. It makes that first weekly build take something like 20 minutes instead of the usual 30 seconds.

It would be easy to add this to the build, but it would require:

0. Approval of the license (it's CC-SA-3, so I think no problem)
1. An additional download (not really a problem)
2. An invocation of the scanner at some point during the build

I think #2 should be optional, and default to FALSE.

Comments?

I'm not convinced of the value of this for the Tomcat builds.

Which dependencies are we expecting it to catch problems in?

Vulnerabilities in compile only dependencies are not a concern.

Vulnerabilities in test only dependencies (e.g. JUnit) are not a concern.

Vulnerabilities in other Apache libraries we'll know about as soon as they are reported and way before this tool does (including those we pull in via svn/git that this tool won't be able to catch).

Vulnerabilities in ECJ - not a concern as a malicious JSP would be required to exploit it and if an attacker can insert a malicious JSP there are much simpler attacks.

Vulnerabilities in NSIS - not distributed as a JAR so does not appear to covered by this tool.

I'll note that the SRC:CLR trial the ASF ran showed that only in about 10% of cases (on average across a wide range of Java based projects at the ASF including Tomcat) did a vulnerability in a dependency result in a vulnerability in the dependent project.

Mark Thomas : I have seen several yr old, known vulnerabilities in many open source projects.  Many of those could be detected by OWASP D.C. and culled.
I have seen new exploitation mechanisms be used that finds newly discovered vulnerabilities in old-legacy jars.

Christopher Schultz :  On frequency of running the report. It depends on the rate of change of the project(how many new libaries are added per week/month), and the rate of new vulnerability discovery in the set of existing libraries per week/month to deternine how often the report should be run, and read.  In new systems, when 5-10 libs are being added daily, the report should be run nightly. In Tomcat ???  start with weekly ?  If after a while there are more than four weeks that go by without a true positive, perhaps monthly is OK.

IMO, its a falicy to complain about a small performance hit once per week compared to the number of instances of sites that get broken into, PII stolen, money stolen, other nefaurious that bad actors could do.  Its a far away issue until it happens to you or someone close to you.  Also it is common for these open source systems to be used in critical infrastructure, banking, gov, military. A once weekly performance penalty is a small price.

I have the same experience as Chris - the Maven plugin slowed down the build of our application so much that we had to find out how to tell Teamcity not to time it out.

As Mark explained there is not much to check anyway because Tomcat doesn't have dependencies.

The Tomcat dependencies fall into one of the following categories:
- Test only dependencies where vulnerabilities are not considered a threat
- Compile only dependencies where vulnerabilities are not considered a threat
- Dependencies on other ASF projects were Tomcat receives notice of any vulnerabilities before they are public and hence before the OWASP tool can report them
- External dependencies that are not covered by the OWASP tool (e.g. NSIS)
- External dependencies where the ability to exploit means an attacker already has a simpler route to exploit (e.g. ECJ) 

There are no Tomcat dependencies where the use of the OWASP tool would provide additional / earlier notice of a genuine threat. Hence there is no benefit to the Tomcat project of deploying this tool.

(In reply to ABakerIII from comment #3)
> Mark Thomas : I have seen several yr old, known vulnerabilities in many open
> source projects.  Many of those could be detected by OWASP D.C. and culled.
> I have seen new exploitation mechanisms be used that finds newly discovered
> vulnerabilities in old-legacy jars.

Feel free to run this against Tomcat and report any results you find.

> Christopher Schultz :  On frequency of running the report. It depends on the
> rate of change of the project(how many new libaries are added per
> week/month), and the rate of new vulnerability discovery in the set of
> existing libraries per week/month to deternine how often the report should
> be run, and read.  In new systems, when 5-10 libs are being added daily, the
> report should be run nightly. In Tomcat ???  start with weekly ?  If after a
> while there are more than four weeks that go by without a true positive,
> perhaps monthly is OK.

The library turnover in Tomcat is ... exceedingly low.

> IMO, its a falicy to complain about a small performance hit once per week
> compared to the number of instances of sites that get broken into, PII
> stolen, money stolen, other nefaurious that bad actors could do.  Its a far
> away issue until it happens to you or someone close to you.  Also it is
> common for these open source systems to be used in critical infrastructure,
> banking, gov, military. A once weekly performance penalty is a small price.

Okay, let's see.

For those interested, here is the dependency-check target I knocked-up in a few minutes. you can throw it onto the end of your build.xml in Tomcat and run it. You are responsible for downloading the "ant" distribution of OWASP DC and providing a suppression file.

  <target name="dependency-check">
    <property name="dependency-check.home" value="${user.home}/packages/dependency-check-ant" />
    <property name="doc.dir" value="output" />
    <path id="dependency-check.path">
      <pathelement location="${dependency-check.home}/dependency-check-ant.jar"/>
      <fileset dir="${dependency-check.home}/lib">
        <include name="*.jar"/>
      </fileset>
    </path>
    <taskdef resource="dependency-check-taskdefs.properties">
      <classpath refid="dependency-check.path" />
    </taskdef>

    <property name="dependency-check.output-dir" value="${doc.dir}" />
    <mkdir dir="${dependency-check.output-dir}" />
    <dependency-check projectname="${ant.project.name}" reportoutputdirectory="${dependency-check.output-dir}">
      <suppressionfile path="res/dependency-check-suppressions.xml" />
      <fileset dir="output/build">
        <include name="lib/*.jar"/>
        <include name="bin/*.jar"/>
      </fileset>
    </dependency-check>
  </target>

I ran this and it found ALL KINDS OF THINGS!!

Of course, they are all problems with distribution-specific file permissions and all kinds of weird things like that that have nothing at all to do with Tomcat itself.

So, you can chase-down all of these false positives, suppress them, and then call yourself secure if you'd like.

The one item this tool does flag (which is real) is for a different version of Tomcat (I scanned 9.0.x/trunk, and the vulnerability is for 7.0.x and 8.0.x.

(In reply to mgrigorov from comment #4)
> As Mark explained there is not much to check anyway because Tomcat doesn't
> have dependencies.

Well... that's not entirely true. Tomcat does rely on:

1. commons-dbcp[2]
2. commons-fileupload
3. ecj
4. commons-daemon
5. tcnative (technically)

But my guess is that 1, 2 above wouldn't be detected because they have been modified from their original and re-packaged with "Tomcat" as the product name (instead of e.g. commons-dbcp).

OWASP isn't very good at detecting binary dependencies, so it wouldn't detect 5.

I'm not saying this is a great idea, but I'm not saying it's totally worthless, either.

I think having an ant target that is runnable by anyone who chooses to run it would be a good thing.