on the "better education" journey, I started by adding OWASP Dependency Check to our list of remarkable third party projects that provide a Maven plugin
http://maven.apache.org/plugins/index.html#Misc Don't hesitate to provide little patches for other documentation improvements Regards, Hervé Le mercredi 7 mars 2018, 08:21:37 CET Hervé BOUTEMY a écrit : > Hi, > > A few thoughts: > > - there are more than 2 repository providers: > http://maven.apache.org/repository-management.html > > - issuing a warning only when *downloading* content that has a CVE IMHO > won't really be efficient, given there is a local cache: if you miss the > warning at first download, you'll miss the risk for ever. > > - this will require also a mechanism to disable false positives, because > downloading a component that has a CVE does not mean there is really an > issue on the features that are really used > > - if people don't care about security when it just costs to add a check > plugin, I'm not sure nagging them by default will help them. But I know that > the reputation of the tool that will nag them won't be good. > > Personnally, I'm more in favor of better documentation of the consequences > when using third party libraries, and the ways to manage them, to better > educate people than going direct brute nag. > I know that our documentation is silent on this currently: if someone write > some good doc on this (not vendor oriented), I'd be happy to integrate the > content in http://maven.apache.org/repository/ and http://maven.apache.org/ > security.html > > Regards, > > Hervé > > Le mercredi 7 mars 2018, 07:50:20 CET Peter Muryshkin a écrit : > > Hi, Chas, > > > > thanks for answering, absolutely! I see this as a comprehensive approach > > which cannot be done on just one side: > > - IETF to define a new header X-something or even HTTP response code > > standard i.e. "460 - Content generally known to be insecure" > > - Repository providers to implement issuing this header (could be a > > community plugin you install on a mirror repo); in fact this is JFrog's > > and > > Sonatype's business to license dashboards with exactly this information; > > my > > point is to iterate whether they would like to issue such a > > header/response > > code > > - None of the above would make sense if Maven community does not have > > stakes here. > > > > So now from your answer I could read between the lines "ok in general why > > not if repository gives you such a notification" :-) > > > > kind regards > > Peter > > > > 2018-03-07 4:56 GMT+01:00 Chas Honton <c...@honton.org>: > > > If you want the package repository to add the header, you will need to > > > make your request to Sonatype (Nexus) and JFrog (Artifactory) > > > > > > Chas > > > > > > > On Mar 6, 2018, at 4: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? > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
