[ALL] Update to commons security page

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[ALL] Update to commons security page

sebb-2-2
It might be useful to add a note to the commons security page about
automated vulnerability checkers.

These tend to produce a lot of false positives and may report items
which could never be a security issue (e.g. poor code style, dead
code).

Even if the issue is potentially a vulnerability, it often depends on
the context.
This is particularly true of Commons - the code generally relies on
the application to do validation of input parameters.

Thoughts?

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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Update to commons security page

Claude Warren
If the style is to rely on external code to do input validation, then I
think that should be in the javadocs as well as on the page you mention.

Claude

On Tue, Oct 15, 2019 at 10:59 AM sebb <[hidden email]> wrote:

> It might be useful to add a note to the commons security page about
> automated vulnerability checkers.
>
> These tend to produce a lot of false positives and may report items
> which could never be a security issue (e.g. poor code style, dead
> code).
>
> Even if the issue is potentially a vulnerability, it often depends on
> the context.
> This is particularly true of Commons - the code generally relies on
> the application to do validation of input parameters.
>
> Thoughts?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Update to commons security page

sebb-2-2
On Tue, 15 Oct 2019 at 11:03, Claude Warren <[hidden email]> wrote:
>
> If the style is to rely on external code to do input validation, then I
> think that should be in the javadocs as well as on the page you mention.

Perhaps I phrased it wrong.

What I meant was that the code generally does what it is told to do.

e.g. a delete_tree(path) method is not going to prevent you from using path='/'

Commons cannot in general validate such parameters.

> Claude
>
> On Tue, Oct 15, 2019 at 10:59 AM sebb <[hidden email]> wrote:
>
> > It might be useful to add a note to the commons security page about
> > automated vulnerability checkers.
> >
> > These tend to produce a lot of false positives and may report items
> > which could never be a security issue (e.g. poor code style, dead
> > code).
> >
> > Even if the issue is potentially a vulnerability, it often depends on
> > the context.
> > This is particularly true of Commons - the code generally relies on
> > the application to do validation of input parameters.
> >
> > Thoughts?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren

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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Update to commons security page

Matt Sicker
What we’ve been doing in Jenkins Security about this has been to request
demonstrable exploits only. Output from an automated tool is not a security
vulnerability report. Plus, these tools generally don’t understand greater
context and usage of code, so you’ll get false positives that require
someone familiar with the code base to confirm or deny. With a huge report,
that can be a huge waste of time.

On Tue, Oct 15, 2019 at 05:55, sebb <[hidden email]> wrote:

> On Tue, 15 Oct 2019 at 11:03, Claude Warren <[hidden email]> wrote:
> >
> > If the style is to rely on external code to do input validation, then I
> > think that should be in the javadocs as well as on the page you mention.
>
> Perhaps I phrased it wrong.
>
> What I meant was that the code generally does what it is told to do.
>
> e.g. a delete_tree(path) method is not going to prevent you from using
> path='/'
>
> Commons cannot in general validate such parameters.
>
> > Claude
> >
> > On Tue, Oct 15, 2019 at 10:59 AM sebb <[hidden email]> wrote:
> >
> > > It might be useful to add a note to the commons security page about
> > > automated vulnerability checkers.
> > >
> > > These tend to produce a lot of false positives and may report items
> > > which could never be a security issue (e.g. poor code style, dead
> > > code).
> > >
> > > Even if the issue is potentially a vulnerability, it often depends on
> > > the context.
> > > This is particularly true of Commons - the code generally relies on
> > > the application to do validation of input parameters.
> > >
> > > Thoughts?
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > --
> > I like: Like Like - The likeliest place on the web
> > <http://like-like.xenei.com>
> > LinkedIn: http://www.linkedin.com/in/claudewarren
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Update to commons security page

garydgregory
On Tue, Oct 15, 2019 at 9:47 AM Matt Sicker <[hidden email]> wrote:

> What we’ve been doing in Jenkins Security about this has been to request
> demonstrable exploits only.


That sounds good but it should not be a requirement. Something might just
be plain wrong. I do agree that most of these tools turn up far too many
false positives.

Gary


> Output from an automated tool is not a security
> vulnerability report. Plus, these tools generally don’t understand greater
> context and usage of code, so you’ll get false positives that require
> someone familiar with the code base to confirm or deny. With a huge report,
> that can be a huge waste of time.
>
> On Tue, Oct 15, 2019 at 05:55, sebb <[hidden email]> wrote:
>
> > On Tue, 15 Oct 2019 at 11:03, Claude Warren <[hidden email]> wrote:
> > >
> > > If the style is to rely on external code to do input validation, then I
> > > think that should be in the javadocs as well as on the page you
> mention.
> >
> > Perhaps I phrased it wrong.
> >
> > What I meant was that the code generally does what it is told to do.
> >
> > e.g. a delete_tree(path) method is not going to prevent you from using
> > path='/'
> >
> > Commons cannot in general validate such parameters.
> >
> > > Claude
> > >
> > > On Tue, Oct 15, 2019 at 10:59 AM sebb <[hidden email]> wrote:
> > >
> > > > It might be useful to add a note to the commons security page about
> > > > automated vulnerability checkers.
> > > >
> > > > These tend to produce a lot of false positives and may report items
> > > > which could never be a security issue (e.g. poor code style, dead
> > > > code).
> > > >
> > > > Even if the issue is potentially a vulnerability, it often depends on
> > > > the context.
> > > > This is particularly true of Commons - the code generally relies on
> > > > the application to do validation of input parameters.
> > > >
> > > > Thoughts?
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > > --
> > > I like: Like Like - The likeliest place on the web
> > > <http://like-like.xenei.com>
> > > LinkedIn: http://www.linkedin.com/in/claudewarren
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
> Matt Sicker <[hidden email]>
>