Add outdated dependency detection

[stevespringett]

Add the ability to detect if newer versions of a given dependency are available. For Java libraries, this may be possible using technology included in the Versions Maven Plugin.

Add an optional evidence-based analysis step to collect and analyze copyright, build, file stamp and other dates to determine when the library was published. Add a configurable threshold that would flag the library as 'old' if published prior to this date.

Add an optional and separate report that would output all dependencies that have newer versions and if possible, state what the current version is as well as the closest minor version not containing known vulnerabilities. Include another section containing possible out-of-date libraries.

[jeremylong]

With the new Nexus Analyzer - we could probably tweak things a bit and determine if there is a newer version. But this would only apply to dependencies that reside in a nexus repo. Another interesting thing is we could tell if the version approved for use (i.e. the one in your internal companies repo) is being used.

Thoughts?

[stevespringett]

One of my primary reasons for this feature is to flag old libraries that may be unsupported or end-of-life. Struts 1.3 comes to mind. There are many webapps that still use it, yet most of the vulnerabilities being discovered are in 2.x. Is this because 2.x is worse than 1.3, or is it that security researchers aren't looking for vulns in 1.3 anymore. I don't know the answer, but flagging old libraries with a warning would be a good addition.

I like the notion of seeing if the dependency is in the internal Nexus repo. I don't think we can assume it's not approved if it's no there, but again, flagging it as a warning would be a good addition.

[colezlaw]

It occurred to me that Struts 1.3 is an interesting case. What if you're using Struts 1.3.10? Should that generate a warning? Beside the build timestamp, how would one determine that's "old"? If you look on the repository, that's the latest, greatest version (see org.apache.struts:struts-core)

[colezlaw]

As I started implementing this check in the Nexus Analyzer, I decided that it's riddled with questions that need to be answered - some are easier than others to answer.

• Do we look up latest version information for anything for which we identify GAV? (For example, the JAR analyzer will get GAV information - although it doesn't record that as an identifier (yet))
• Do we know you're using the right repository to find the latest version? With Nexus, it tells you the latest version (ahem!) that exists on that repo, not on Central. So for folks using an internal repository, they would see the latest version that somebody has published on the internal repository, not necessarily the latest version. This yields additional questions:
  ** Do we try to always look up stuff on Central regardless of where they configured the Nexus analyzer for?
  ** But what if the internal repository is "allowed versions" and the newer Central versions have not been certified yet?
  ** We don't want to look up things on Central that didn't originate from there when looking at an internal repository - e.g., commercial sources, JBoss, Scala, etc.
• What about transitive dependencies? The latest version of X does not always depend on the latest version of Y. Discovering Y is out of date while X is not could yield results that would cause somebody to implement a breaking change.
• What about dependencies where not only the version is out of date, but the GAV is out of date. Some examples:
  • commons-lang . If I'm starting a brand new project, it's probably a good idea to use commons-lang3. So how do we demonstrate that if they selected commons-lang:commons-lang rather than org.apache.commons:commons-lang3?
  • servlet-api. Up to 2.5, it was at javax.servlet:servlet-api. Then it switched to javax.servlet:javax.servlet-api (and to be 100% honest, I don't know that those are necessarily the right ones)
• How do we handle snapshots? Do we search for the latest snapshot if they're using a snapshot version already, and otherwise look only for releases? (This may be a broader question for the NexusAnalyzer to begin with as we may identify by SHA-1 they're using a snapshot version and right now it blindly records that version information which may cause some false negatives in the CVE analysis)
• Nexus already provides a "latest version" - and this comes back in the service request for a GAV search (although you need to leave off V if you want the latest version). But this has its own problems:
  • Do a search for g:javax.servlet a:servlet-api. The latest version there is 3.0-alpha1. The two problems with this are: 1) Do we really want to tell somebody the latest release of something is alpha? (There are tons of other examples like this with beta, etc.)
  • How about g:commons-lang a:commons-lang. The "latest version" there is 20030203.000129 - which isn't the latest version at all. The Nexus latest version is determined by selecting the highest version rather than by the submission date. But to get the submission date we actually have to do a separate call for each and every version to get its upload date.

[stevespringett]

CVE's do not typically include alpha, beta or snapshot releases. There are a few exceptions to this, but in general, CVE's are not published for unreleased software.

The transitive dependency issue is out of scope for Dependency-Check. I think its our obligation to detect old and outdated libraries regardless of their transitive dependencies. A9, like any new type of issue, requires a bit of push back in order to make non-security developers aware of the situation.

I'm a big fan of simplicity, and envisioned something like this:

Ability to find 'old' libraries. 'old' can be defined in the properties file by using a date. Perhaps start with 2 years.

A secondary property file would be used to determine how many revisions out of date a library is. Perhaps a default of 3. Anything 4 or more revisions out of date and it will be flagged. This would only be used for releases, not alpha, beta or snapshot.

[colezlaw]

Okay, I like the idea of putting some sort of a line in the sand on age. And that only takes one more request back to Nexus, and it avoids a lot of the complication on when Nexus says that 20130405.122731 is "newer" than version 1.3 because 20130405 is bigger than 1.

[augustd]

For Maven at least, this function can be handled by the Versions Plugin:

http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html

[jeremylong]

Some preliminary work is in progress in the Maven plugin to list new versions of the identified dependency.

--Jeremy

[dwvisser]

Versions plugin page for Maven has moved: http://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html

I wonder if instead of trying to pull this functionality into Dependency Check, we could document on the site about the Versions plugin, and mention it in the output the Dependency Check Maven plugin.

[jeremylong]

The issue with just documenting dependency-updates-mogo is that not everyone is using Maven. Worst case we have the CLI.