Amol,
Build may fail for multiple reasons, unless it outputs details of CVE
that outlines how vulnerability can be exploited, the vulnerability is
not exposed to the public.
I am +1 that it is better to know and monitor vulnerabilities than to
proceed with a risk of introducing new dependencies with known
vulnerabilities. All those tools that scan for vulnerabilities are
publicly available and anyone can run them including those who will try
to exploit the results of scans to maliciously gain access to data.
Thank you,
Vlad
On 9/8/17 15:41, Amol Kekre wrote:
Vlad,
Assuming you are in agreement that vulnerabilities should not be shown in
public way; how would failing the build help. The reasons for failure will
have be noted in public to be worked on. Anyway, IMO Apex may be better off
exposing CVE as we are better off knowing these. But if folks want to
details suppressed I am fine with it.
The more important part is to amortize the cost of fixing CVE in current
dependencies over time as pointed by you by lowering severity level
gradually.
Thks,
Amol
E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*
www.datatorrent.com
On Fri, Sep 8, 2017 at 3:21 PM, Pramod Immaneni <pra...@datatorrent.com>
wrote:
Manually during release is fine but we do need to come up with a process to
shorten the cycle it will take to address these. Maybe we can come up
with some guidelines on how to identify when something does not affect the
software, for example, if a vulnerability comes into picture when a
particular library is used in some way and we don't use it that way. It
could serve as an initial filter and those that make it out of that will
need deeper analysis to figure out whether they are real issues.
Thanks
On Fri, Sep 8, 2017 at 3:10 PM, Thomas Weise <t...@apache.org> wrote:
On Fri, Sep 8, 2017 at 2:33 PM, Pramod Immaneni <pra...@datatorrent.com>
wrote:
Second and more importantly, the vulnerabilities cannot be
reported in a public way which integrating with the open build systems
will
do.
How about implementing it so that it can be run manually, for example as
part of a release?
False alarms are a problem, but ultimately relevant vulnerabilities will
need to be identified and fixed. It's part of project maintenance (like
CI
and other times), which cannot be neglected.
