Re: RFC: Maven to raise a notification if downloading vulnerable content

2018-03-09 Thread Paul Hammant
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  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  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.


Re: RFC: Maven to raise a notification if downloading vulnerable content

2018-03-08 Thread Hervé BOUTEMY
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 :
> > > 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 
> > > > 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



Re: RFC: Maven to raise a notification if downloading vulnerable content

2018-03-06 Thread Hervé BOUTEMY
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 :
> > 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  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



Re: RFC: Maven to raise a notification if downloading vulnerable content

2018-03-06 Thread Peter Muryshkin
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 :

> 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  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
>
>


Re: RFC: Maven to raise a notification if downloading vulnerable content

2018-03-06 Thread Chas Honton
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  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