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. > > >
