If it's possible to record exclusions for issues identified as irrelevant (similar to rat/license check), then after paying the initial cost it will be incremental effort if and when something changes.
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. > > >
