apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad Rozov <vro...@apache.org>
Subject Re: checking dependencies for known vulnerabilities
Date Fri, 08 Sep 2017 23:04:52 GMT
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:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*
>
> www.datatorrent.com
>
>
> On Fri, Sep 8, 2017 at 3:21 PM, Pramod Immaneni <pramod@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 <thw@apache.org> wrote:
>>
>>> On Fri, Sep 8, 2017 at 2:33 PM, Pramod Immaneni <pramod@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.
>>>


Mime
View raw message