It's good idea to check for vulnerabilities, but as Pramod said all softwares / libraries are going to have some or other vulnerability at any time. I will go with approach of "let's discuss this addition" and we should not affect PRs which are not adding any new dependencies (due to old vulnerabilities).
Also I also strongly feel, we need to be meticulous and think it through before introducing such checks for reasons discussed before. -Priyanka On Sat, Sep 9, 2017 at 8:36 PM, Vlad Rozov <vro...@apache.org> wrote: > CVE are classified by severity levels or CVSS scores [1]. Any CVE that has > a score above 9.0 is considered to be critical. I am OK with "let's discuss > this addition" and consider probability of a CVE in a dependency leading to > a security exploit in Apex when the severity of the CVE is not critical. > For critical and possibly high severity level CVE, the approach should be > reversed - reject the additional dependency automatically and discuss if it > is OK to accept the dependency with the critical severity level. We may > discuss what is a cut off level and my recommendation is to use middle > point of the high severity (8.0). > > Without penalizing PRs that have nothing to do with a CI build failures > whether it is caused by a dependency check, change in a CI environment or > any other reason like unit test failure you promote the current community > no appetite for addressing non functional issues in Apex (actually another > example where the appetite is driven not by the community but by the > vendor). IMO, PRs must be automatically rejected when build fails in CI > (whether in Travis or Jenkins) and the burden must be on the community to > troubleshoot and resolve issues in the build or unit test (including > intermittent failures in the unit test). An attitude of the majority of the > current Apex community not to care for CI builds (and other non functional > issues like package names) unless an issue is introduced directly in their > PR at minimum should not be encouraged. > > I don't know if other Apache projects automatically reject dependencies > based on CVE. Every Apache community is independent and establishes it's > own process. What I know is that it would be better for Apex to avoid > mentions like [2]. > > Thank you, > > Vlad > > [1] https://nvd.nist.gov/vuln-metrics/cvss > [2] http://thehackernews.com/2017/09/apache-struts-vulnerability.html > > > On 9/8/17 16:42, Sanjay Pujare wrote: > >> I am with Pramod on this one. >> >> Are there examples (Apache projects) where PRs are automatically rejected >> based on builds flagging CVEs? >> >> On Fri, Sep 8, 2017 at 4:21 PM, Pramod Immaneni <pra...@datatorrent.com> >> wrote: >> >> There are a couple of things here. You may be hard pressed to find >>> software >>> with no CVE vulnerabilities as security issues are found all the time so >>> we >>> should go with a guideline that is in the spirit of "let's discuss this >>> addition and weigh the pros and cons" rather than "don't add whatsoever >>> if >>> you find a vulnerability". Almost every software out there has >>> vulnerabilities including your OS, hadoop and the various other >>> dependencies. >>> >>> I am fine with the build failing for a PR that has a newly added >>> dependency >>> which has CVEs as long as we don't penalize PRs that have nothing to do >>> with a dependency change, i.e., don't fail builds for PRs because a new >>> CVE >>> was discovered in existing dependencies. Also, if there is a PR with a >>> new >>> dependency that has CVEs, let it not be an automatic disqualifier but >>> should be discussed on the dev list. >>> >>> Thanks >>> >>> On Fri, Sep 8, 2017 at 3:51 PM, Vlad Rozov <vro...@apache.org> wrote: >>> >>> +1 that PR with newly introduced vulnerability should not be merged. >>>> Actually, my preference will be that such PR should not be even open. >>>> >>>> Thank you, >>>> >>>> Vlad >>>> >>>> >>>> On 9/8/17 15:44, Thomas Weise wrote: >>>> >>>> On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni <pra...@datatorrent.com >>>>> wrote: >>>>> >>>>> 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 think that if a new problem is introduced, then it should be >>>>>> >>>>> discovered >>> >>>> in the CI and the PR that causes it not be merged until it is addressed. >>>>> >>>>> >>>>> >
