My response inline On Fri, Sep 8, 2017 at 3:20 PM, Vlad Rozov <vro...@apache.org> wrote:
> The proposal is to automate detecting CVEs in existing or newly added > dependencies based on an externally supported and updated database. > Currently, nobody from the community monitors new additions to known CVEs > and whether or not they affect dependencies used by Apex. By using the > proposed maven plugin, it is possible to set a severity level of CVE when > build would fail and gradually lower it over time. The CI build failure > will be a strong indication for the community to address the issue and > either reject newly introduced dependency or upgrade it to one where CVE is > fixed (the same applies if a new CVE would be found in an existing > dependency). > > I guess that it may be possible to suppress details of CVE and simply fail > the build. Will that address the concern that the vulnerabilities cannot be > reported in a public way? > Though I like the functionality of being able to detect if a new dependency being added has vulnerabilities and prompting the search for a better version, I am wary of tying a build strongly to vulnerability detection i.e., the build failing when vulnerabilities are discovered in dependencies. This immediately blocks our project till those vulnerabilities are addressed as nothing can go in because builds are failing. If details are suppressed and we have a summary warning but not fail the build, that should be ok. > > I tried implementing the plugin on my fork and the initial download size > seems to be OK. > > Thank you, > > Vlad > > > On 9/8/17 14:33, Pramod Immaneni wrote: > >> We will need to think about how much appetite the community has into >> looking into these issues if and once they are reported. Last time when a >> scan like this was run and several possible vulnerabilities in the >> dependencies were reported, it took about a year to verify and address >> them. Not because they were particularly hard to address but because there >> were no volunteers. In fact, the majority of them if I remember correctly, >> turned out to be non-issues for the software but somebody had to go >> through >> each one and make that determination. Also once these are reported they >> become a high priority as they come into the radar of the security teams >> in >> apache and they need to be addressed in a timely manner and appropriate >> reports filed. Second and more importantly, the vulnerabilities cannot be >> reported in a public way which integrating with the open build systems >> will >> do. For these reasons I am -1 but I am willing to change my opinion if we >> can find ways to mitigate both the concerns. >> >> Thanks >> >> On Fri, Sep 8, 2017 at 1:41 PM, Thomas Weise <t...@apache.org> wrote: >> >> +1 for implementing it. I'm not sure it will be suitable for CI build >>> though due to initial download overhead? >>> >>> >>> On Fri, Sep 8, 2017 at 1:33 PM, Vlad Rozov <v.rozo...@gmail.com> wrote: >>> >>> Any objections to implementing https://www.owasp.org/index.ph >>>> p/OWASP_Dependency_Check maven plugin that will run on Travis/Jenkins >>>> and >>>> check for known vulnerabilities? >>>> >>>> Thank you, >>>> >>>> Vlad >>>> >>>> >
