Has this plugin been obsoleted by the OWASP Dependency-Check plugin?

[volkertb]

Dear developers,

First of all, thank you for developing this useful tool.

However, I haven't noticed much activity in this project lately. In fact, with the exception of pull request #33 a few weeks ago, there hasn't been any activity (whether new issues or commits) in years.

Given the fact that there is also the OWASP Dependency-Check Maven plugin, how useful is the victims-enforcer plugin these days? Would there be any increased security by using both plugins side by side, for instance? Given the fact that both plugins need to be configured differently (particularly the proxy settings), which complicates maintenance of our POMs, would such effort still be justified?

Or has the OWASP plugin made the victims-enforcer plugin completely obsolete and redundant?

Are there any known vulnerabilities in the Red Hat Victims database that are not also categorized in the CVE database(s) accessed by the OWASP Dependency-Check plugin?

Please understand that this is not meant to disparage your hard work or to troll you. I genuinely appreciate your important work! But I'd really like to know if it's still worth it to go through the effort of configuring the victims-enforcer plugin in our projects, even though it appears to have been receiving little maintenance lately and there is an alternative out there.

Thanks.

[ashcrow]

@volkertb I totally understand your question and take no offence. Thank you for framing your question in a friendly and understanding way. To be honest I don't know much about the internals of the OWASPs dependency check maven plugin. I have a feeling there are a lot of overlap between the two but differences between how we look for vulnerabilities. I'll defer to @gcmurphy and @jasinner on specifics.

In the victims project we are in a bit of flux at the moment to re-architect the components from the server side to the clients. Because of that, if I was a user, I'd probably focus on using OWASP Dependency-Check for a Java project until the victims project finished their re-architecture. Once the re-architecture occurred I'd probably use both as, while there is overlap I also have a feeling we scan differently.

Again, I'd like @jasinner and @gcmurphy to jump in and give their $0.02 as well.

[gcmurphy]

That's a fair question. TBH I haven't been actively working on this project for a long time (basically since I left Red Hat). I will try to find some time to do a clear out of outstanding issues soon. However it is worth mentioning that much of the core functionality of this plugin is abstracted to victims-lib-java which is actively being maintained.

As to the technical merits of the victims project vs something like dependency check, the key difference comes down is in the detection mechanism. The Victims project attempts to create a platform agnostic fingerprint of the vulnerable .jar based on the file content. Dependency check is based solely on version checking against a list of known vulnerable .jars. So an example of why you would use victims over dependency check would be to detect vulnerable jars if they've been 'vendored' or embedded within another .jar file by a developer.

If you're concerned about the configuration overhead of running both dependency-check and victims side by side another option would be to include https://github.com/victims/victims-client-java in your ci/cd pipeline and scan the build artifacts as a catch-all type solution.

Hope that helps answer your question.

[jasinner]

Hi @volkertb, In our research comparing OWASP Dependency Check and Victims we've found that Victims has less false positives than Victims. That's why we continue to maintain victims, and contribute vulnerability reports. However we've focusing our efforts on a direct Web API call to the Victims-API instead of using either the Victims Enforcer Plugin or Victims Client Java. That's why this project hasn't received many updates from us recently. In the future we may improve these client programs as well. If you want to experiment with Victims Maven integration today I'd encourage you to take a look at this project, which bypasses the Victims API, which is currently unavailable. The Victims API should become available again soon, once we've migrated it off Openshift V2.

[gcmurphy]

@jasinner is that the right project link? AFAICT that is an untouched fork of this project..

[jasinner]

Sorry, that was the wrong link. Here it is:

https://github.com/GoSecure/maven-security-versions

[volkertb]

First of all, thank you all for your comprehensive answers!

So if I understand correctly, the major advantage that Victims has over the OWASP Dependency-check plugin is that the former actually checks the hashes of JAR files, including those embedded in other JAR files, whereas the latter only checks the artifact names and version numbers declared in the POM and/or manifest files, if any. I absolutely agree that checking hashes is by far the most robust and reliable approach to scanning for vulnerabilities.

Considering the fact that both plugins ultimately have the same goal, have you considered joining forces with the OWASP Dependency-check developers to work on a unified plugin that employs the best of both worlds? Perhaps initially in the short term simply by adding optional integration with victims-client-java to the OWASP plugin and building from there?

I wasn't able to find out through Googling whether Red Hat is currently a member/sponsor of OWASP, but I would be shocked if they weren't.

There may be some underlying reasons that I'm not aware of that would justify both plugins to exist separately from each other, but from the surface of it, a merger of the two would seem quite logical.

Have people from either project already reached out to the other, regarding this?

[ashcrow]

Considering the fact that both plugins ultimately have the same goal, have you considered joining forces with the OWASP Dependency-check developers to work on a unified plugin that employs the best of both worlds? Perhaps initially in the short term simply by adding optional integration with victims-client-java to the OWASP plugin and building from there?

It's not come up AFAIK. To be frank I hadn't heard that OWASP had a dependency project like this until this issue was opened 😄. I wouldn't be against optional integration at all!

There may be some underlying reasons that I'm not aware of that would justify both plugins to exist separately from each other, but from the surface of it, a merger of the two would seem quite logical.

The main reason both exist is they were created at different times, by different groups of people. @jbowes and I came up with the victims idea while working at Red Hat around 2009. It looks like the OWASP dep checker was created a few years later. Likely they didn't know about this project either.

I primarily stay more server/process side with the victims project. If @jasinner and @gcmurphy think it's a good idea to reach out to the OWASP dep checker team I'd 👍 it.