Personally, I think vulnerable packages could be retained locally and was subscribable. Dealing with it during a build would be a local operation.
Here's a repo of all Maven Meta data (I wrote some stuff in Python and Herve redid it in Java) -> https://github.com/hboutemy/mcmm-yaml/ While vulnerability info could be woven into that repo with extra attributes, it might be better that there were a separate repo that listed vulnerbilities only. That Git repo would have the same structure but be limited to information around artifacts vulns only, and only the root cause vulns. For example CVE-2017-15707 says the REST Plugin for Apache Struts 2.5 to 2.5.14 is vulnerable, but it is really certain versions of JSON-lib that is vulnerabilities https://github.com/hboutemy/mcmm-yaml/blob/master/org/apache/struts/struts2-core.yaml https://github.com/hboutemy/mcmm-yaml/blob/master/net/sf/json-lib/json-lib.yaml Thus a revised vulnerability plugin would check against the local Git repo of vulns, AND have an option of doing a git-pull for the repo again of the determination. mvn vuln:report mvn vuln:fail mvn vuln:report -DupdateVulnDB mvn vuln:fail -DupdateVulnDB Being a git repo allows for mirrors. Also, git pull (especially for --depth=1) is quick. Interestingly this git repo could operate bare (no working copy on the local) as you're not going to change the files in an edit/commit/push cycle -ph On Tue, Mar 6, 2018 at 7:12 AM, Peter Muryshkin <murysh...@gmail.com> wrote: > Hi, all, > > currently you can run OWASP dependency check plugin against your projects. > > Though, this seems to make security more or less optional: unaware either > lightheaded teams could miss this. > > What if a package repository would integrate with this dependency checking > and issue a warning, say a special HTTP response code or a header? > > Then, Maven would raise the warning in the console log, like "this > component is known to have CVE-XYZ! consider upgrading" > > What do you think? > -- Paul Hammant DevOps <https://devops.paulhammant.com> Let me give your enterprise a step by step plan to get out of the hell of crazy branching models (ClearCase maybe?) and into the world of high-throughput CD on DevOps foundations.
