Hello, instead of requiring everybody to come up with a CPE and add it to the POM, I would prefer if Maven Central publishes an approved (and registered) naming scheme to form CPEs which point to well known maven artifacts.
cpe:/a:org.maven.central:groupid,artifactid[,classifier]:version (or similiar, maybe ask the CPE team about it. alternative would be to have a common maven-style repo vendor and include the repoid in the "product") This would allow incidents and CVEs to unambigously refer to libraries and other artifacts. The Java eco system is really missing good reports based on open source components. If you are lucky you find an alert based on a product and can guess what underlying open source component was vulnerable. This makes (as you know) the life of a scanner pretty hard. Gruss Bernd 2014-09-30 21:53 GMT+02:00 Jeremy Long <[email protected]>: > There are commercial solutions (sonatype, contrast, blackduck, palamida, > etc.) and FOSS solutions (dependency-check, victims, retire.js, etc.) to > identify and report on known vulnerabilities. I would recommend looking at > these solutions (note, I am the main contributed to dependency-check). > > A better solution for the POM modification would be to add a CPE > identifier. This would also be a great entry for a jar file's manifest. CPE > identifiers can be requested even if there are no known CVEs, but the CPE > can be used to lookup the related CVEs. > > -jeremy > @ctxt > On Sep 30, 2014 2:45 PM, "David Dillard" <[email protected]> wrote: > > > Hi, > > > > I've been working on an internal presentation on how letting Maven's > > dependency mediation feature select versions of transitive dependencies > can > > introduce vulnerabilities into a product and how to deal with that > > problem. Unfortunately, it's a very manual process and I was thinking > that > > perhaps changes could be made to Maven that would provide better > > automation. To that end I'm wondering if the team has ever considered > > adding a section to the POM that would list significant changes in that > > release. This would include a list of vulnerabilities fixed (e.g. > > CVE-XXXX-YYYY) or serious bugs fixed. Each one could include a known set > > of versions affected (ala how CVEs work today) thus allowing tooling to > > say: the version of artifact XYZ you're using has a known vulnerability, > > would you like to upgrade to this new version with that vuln fixed? > > > > On a related note, has a different dependency mediation system ever been > > considered (as an option), e.g. latest version or latest version on a > > branch? > > > > > > Thanks, > > > > David > > > > >
