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