Re: Security related metadata

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Security related metadata

Bernd Eckenfels
There is the problem of missing CPE/maven-coordinates mappings. owasp,dependency check can work around that only with crude heuristics. Therefore it would be at least nice if we can add a CPE to the POM (or define an official mapping to CPEs, but last time I tried to address that on different lists nobody really agreed)

Having a standard way to attach annotations might do the whole eco system a favor.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Hervé BOUTEMY <[hidden email]>
Sent: Wednesday, March 14, 2018 11:48:35 PM
To: Maven Developers List
Subject: Re: Security related metadata

using a plugin like OWASP Dependency-Check (or any other tool like it), and
its dedicated security issues storage and update workflow, avoid adding a new
management nightmare at every level of Maven

Regards,

Hervé

Le mercredi 14 mars 2018, 13:27:53 CET Jochen Wiedmann a écrit :

> Hi,
>
> recently I had an issue, where a security problem was claimed, because
> a published POM was using a jar version, for which a CVE exists. The
> reporter requested to upgrade to a current version, and publish an
> updated POM.
>
> As you know, we cannot update the POM. We only publish new POM's, so
> the case resulted in publication of a new version. However, this case
> got me thinking:
>
> 1.) Whether we like it, or not, the published POM is an artifact, that we
> have to maintain. (And, in the case of the ASF: For which we might be
> legally responsible.)
> 2.) Knowing, that one can exclude the jar file in question in a
> downstream POM, is not sufficient. You've got to know, that there is a
> problem.
>
> Point one is a simple statement of fact. Nothing much to do
> here.Regarding point two, however: Here's something, that the Maven
> world could do better.
>
> My suggestion would be:
>
>   a) Introduce a new artifact (say <ARTIFACTID>-<VERSION>-issues.xml).
>
>       The idea would be, to publish such an artifact, if an issue with the
> jar, war, or whatever file (the original artifact, without
> classifier) has been
>        detected.
>
>   b) On occasion, Maven would check, whether there is an issues file
> for a dependency. If so, it would issue a warning, break the build, or
> do whatever seems appropriate.
>       Of course, this action would be done in a plugin, which might be
>       skipped.
>
> Leaving out questions like update of an issues file (There might be
> other issues, later on, or more serious issues.), I think this should
> be doable with moderate efforts.
>
> Jochen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Security related metadata

Hervé BOUTEMY
I like this idea: seems reasonable, even if I don't really see yet the full
implications

I had a look at the 2 CVEs for Maven and could not find any CPE
Is it really something used for every CVE?

Regards,

Hervé

Le jeudi 15 mars 2018, 00:14:34 CET Bernd Eckenfels a écrit :

> There is the problem of missing CPE/maven-coordinates mappings.
> owasp,dependency check can work around that only with crude heuristics.
> Therefore it would be at least nice if we can add a CPE to the POM (or
> define an official mapping to CPEs, but last time I tried to address that
> on different lists nobody really agreed)
>
> Having a standard way to attach annotations might do the whole eco system a
> favor.
>
> Gruss
> Bernd
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: Hervé BOUTEMY <[hidden email]>
> Sent: Wednesday, March 14, 2018 11:48:35 PM
> To: Maven Developers List
> Subject: Re: Security related metadata
>
> using a plugin like OWASP Dependency-Check (or any other tool like it), and
> its dedicated security issues storage and update workflow, avoid adding a
> new management nightmare at every level of Maven
>
> Regards,
>
> Hervé
>
> Le mercredi 14 mars 2018, 13:27:53 CET Jochen Wiedmann a écrit :
> > Hi,
> >
> > recently I had an issue, where a security problem was claimed, because
> > a published POM was using a jar version, for which a CVE exists. The
> > reporter requested to upgrade to a current version, and publish an
> > updated POM.
> >
> > As you know, we cannot update the POM. We only publish new POM's, so
> > the case resulted in publication of a new version. However, this case
> > got me thinking:
> >
> > 1.) Whether we like it, or not, the published POM is an artifact, that we
> > have to maintain. (And, in the case of the ASF: For which we might be
> > legally responsible.)
> > 2.) Knowing, that one can exclude the jar file in question in a
> > downstream POM, is not sufficient. You've got to know, that there is a
> > problem.
> >
> > Point one is a simple statement of fact. Nothing much to do
> > here.Regarding point two, however: Here's something, that the Maven
> > world could do better.
> >
> > My suggestion would be:
> >   a) Introduce a new artifact (say <ARTIFACTID>-<VERSION>-issues.xml).
> >  
> >       The idea would be, to publish such an artifact, if an issue with the
> >
> > jar, war, or whatever file (the original artifact, without
> > classifier) has been
> >
> >        detected.
> >  
> >   b) On occasion, Maven would check, whether there is an issues file
> >
> > for a dependency. If so, it would issue a warning, break the build, or
> > do whatever seems appropriate.
> >
> >       Of course, this action would be done in a plugin, which might be
> >       skipped.
> >
> > Leaving out questions like update of an issues file (There might be
> > other issues, later on, or more serious issues.), I think this should
> > be doable with moderate efforts.
> >
> > Jochen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]