Hi, Even if I get the idea and where you come from, the CVE are basically moving databases and not something you put in a project - or worse an artifact - and deploy with it so it sounds like something unrelated to maven itself but that maven could exploit or host - it is possible to host such an incremental database in a maven artifact but it is not related to the projects it covers. Concretely it should take the form of a database - whatever it means maven, pure REST or anything else - which is handled by a plugin checking project artifacts. It is exactly what https://sonatype.github.io/ossindex-maven/maven-plugin/ and a few others do. In terms of ownership then you just get the database owner as "admin" and the database update process can be the one matching the best the "owner" - form to report a CVE, scrapper, ....
At apache level we have a security "team" so we could centralize the apache CVE in one place and publish them each time it is needed (when a CVE becomes public) in an incremental artifact as mentionned before but not sure we could do anything more general. An "openCVE" initiative can likely be created on github and we could try to get foundations joining (thinking to apache and eclipse but maybe sonatype and other vendors could) but not sure it would get traction but it is how I can envision it working as of today. Side note: the CPE notation is known as *not* working - we have a tons of false positive for geronimo for example - so I assume it can be worth reporting it to them again to get some change at some point to ensure their database is usable by enterprises at least. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 27 déc. 2021 à 09:26, < [email protected]> a écrit : > Hello, > > I hope this is the right place to make this suggestion and to discuss > this. If not, please let me know where to write this instead. > > For software projects it is important to know whether vulnerable > dependencies are used as part of the build. Especially the recent Log4j 2 > vulnerabilities have shown the importance of this. While at the moment the > awareness for this is still high, in a few years most people might have > forgotten this specific vulnerability again, and might be using vulnerable > versions, or they might be using other vulnerable dependencies where the > vulnerabilities got less public attention. > > For other ecosystems such checks are part of the default build tool > functionality, for example for npm. Maven unfortunately does not offer such > functionality on its own, but the third-party OWASP Dependency-Check plugin > can be used. However, there are several drawbacks: > > - Because it is a third-party plugin, many users of Maven are not aware of > it > - It works by creating a complete database of CVE entries: > - Initial setup requires multiple minutes and a good internet connection > - Caching and restoring the database can be challenging for CI servers > - It works based on CPE (Common Platform Enumeration) values, this can > lead to false positives (and false negatives) because CPE entries can be > ambiguous and do not necessarily match the Maven artifact coordinates. For > example for the recent Log4j 2 vulnerabilities one of the CPE entry is > "cpe:2.3:a:apache:log4j:2.0:-:*:*:*:*:*:*"; this causes false positives for > the "log4j-api" artifact. > > My question / suggestion would be whether you think Maven remote > repositories should provide some way of attaching CVE / vulnerability > information to an artifact. This could have the following advantages: > > - Maven and other Maven-based build tools could by default perform > vulnerability checks and for example fail a build if critical > vulnerabilities are found (but allowing users to suppress them) > - The connection between CVE and Maven artifact would be unambigous; > multiple vulnerable release branches could easily be marked by adding the > CVE information to all affected versions of the artifact > - The vulnerability lookup could be performed efficiently; no need to > create a local CVE database > > It would not render the OWASP Dependency-Check plugin obsolete. That > plugin has additional features, such as inspecting JAR files and support > for other programming languages. Users could still use it to detect > vulnerabilities there, but for the average user which only uses artifacts > from a Maven remote repository the default vulnerability checks might > already suffice. > > This would then raise (at least) the following questions: > > - How well does this work with the concept that Maven artifacts are > immutable once deployed? > Ideally it should be possible to add CVE information to existing > artifacts. Additionally, it should be possible to correct CVE references, > for example when an incorrect reference was added. Also, Maven would need > to fetch this information from the remote repository even when the artifact > itself already exists in the local repository. > - Who should be able to edit the CVE information attached to an artifact? > Obviously the owner of the group ID, but maybe also Maven Central staff, > so that for unmaintained artifacts it will be possible to add CVE > references (at least critical ones). > - Which CVE data should be added to artifacts? > Including data other than the CVE number itself, such as impact score or > description would risk that this information becomes outdated, because in > some cases it is updated after a CVE entry is published. Maybe only the CVE > numbers should be added and build tools then would have to look up the > information through other means, e.g. the NIST NVD REST API, see > https://nvd.nist.gov/developers/vulnerabilities > - Which vulnerability identifiers should be supported? > This affects in which format the remote repository should store this > information. Besides CVE entries there are also other identifiers, such as > GitHub Security Advisories. However, CVE is the industry standard, so maybe > only supporting it would suffice. In the case of GitHub Security > Advisories, GitHub also offers to assign a CVE number, so GitHub Security > Advisories without corresponding CVE should be rather rare, see also > https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories#cve-identification-numbers > > Alternatively the question would be whether Maven could by default support > such vulnerability checks in an efficient way (that is, unlike OWASP > Dependency-Check, without creating a large CVE database locally) without > any changes to the Maven remote repository data. Websites such as > https://mvnrepository.com/ and https://security.snyk.io/ are matching CVE > entries to Maven artifacts correctly, so maybe there is a "secret" way how > this can be done in a less error-prone way. Or maybe they are also manually > fixing false positives or manually maintaining the mappings. > > What do you think about this suggestion? > I am not familiar enough with the code base to propose any concrete code > changes, but hopefully at least this mail starts a useful discussion about > this feature. In case someone wants to implement this, I could offer a > rough code review though, if that is desired. > > Kind regards > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
