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]
