On Tue, Oct 15, 2019 at 9:47 AM Matt Sicker 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 t
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
someo
On Tue, 15 Oct 2019 at 11:03, Claude Warren 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 d
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 wrote:
> It might be useful to add a note to the commons security page about
> automated vulnerability ch
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 o
