Re: checking dependencies for known vulnerabilities

Please see PR https://github.com/apache/apex-core/pull/585 comments and APEXCORE-790 for the further discussion and the resolution. There is still one open item - updating contributor/committer guidelines if someone wants to help with it. Thank you, Vlad On 11/2/17 16:55, Vlad Rozov wrote:

Re: checking dependencies for known vulnerabilities

After the PR CI build fails it should be straightforward to see if the dependency was part of the PR or not. On Thu, Nov 2, 2017 at 11:50 PM, Pramod Immaneni wrote: > Check is fine as long as we can identify whether the CVE was introduced by > a PR. It might still be

Re: checking dependencies for known vulnerabilities

Can you check if there is a possibility to distinguish between existing dependencies and dependencies introduced in a PR. AFAIK, it does not exist. Thank you, Vlad On 11/2/17 16:50, Pramod Immaneni wrote: Check is fine as long as we can identify whether the CVE was introduced by a PR. It

Re: checking dependencies for known vulnerabilities

Check is fine as long as we can identify whether the CVE was introduced by a PR. It might still be useful to fix a CVE even if there is no release, downstream projects might be able to use it. On Thu, Nov 2, 2017 at 4:42 PM, Thomas Weise wrote: > Check as part of PR build is

Re: checking dependencies for known vulnerabilities

Check as part of PR build is needed to ensure no new issues are introduced. I don't think it is necessary to have another build to notice pre-existing issues since releases won't occur without prior PRs. Whitelisting suggestion is for pre-existing problems and not for those introduced by a PR.

Re: checking dependencies for known vulnerabilities

If the PR introduces a CVE by all means lets fail it initally and later look at whitelisting it if needed. Why fail all PRs that haven't caused the problem. What happens when there are no PRs in a given period, wouldn't it be better to know above crtiical CVEs (that this proposal is trying to

Re: checking dependencies for known vulnerabilities

Do you mean that blocking my PR https://github.com/apache/apex-core/pull/585 is too drastic? I fully agree :). Why not to apply the same rule to that PR? Will you agree that somebody needs to look into CVE, build issues or failed unit tests? If yes, who is that "somebody" is? Let me give

Re: checking dependencies for known vulnerabilities

There is no question of which build as there is only one build. Once somebody puts an effort to create nightly build we can discuss moving the check from the current build to the nightly build, but then the question will be what do we do with PR that introduces new dependencies with CVE?

Re: checking dependencies for known vulnerabilities

The question is which build? We can definitely make it a mandatory release step and also have nightly builds that are meant for just these, detection of CVEs and even possible infra changes that might break tests. Those will work even if there are no PRs. On Thu, Nov 2, 2017 at 1:21 PM, Ananth G

Re: checking dependencies for known vulnerabilities

My vote would be to break the build. This can then force a “whitelisting” configuration in the maven plugin to be created as part of the review process ( along with a new JIRA ticket ). The concern would then be to ensure that the community works towards a resolution of the JIRA. Not breaking

Re: checking dependencies for known vulnerabilities

I like this suggestion. Blocking the PR is too drastic. I also second Pramod's point (made elsewhere) that we should try to encourage contribution instead of discouraging it by resorting to drastic measures. If you institute drastic measures to achieve a desired effect (e.g. getting contributors

Re: checking dependencies for known vulnerabilities

I don't see why it will be beneficial for the community to do something manually when it can be automated. Thank you, Vlad On 11/1/17 17:09, Munagala Ramanath wrote: Failing the CI build seems too drastic. My suggestion is to create a new profile that activates thisfunctionality and

Re: checking dependencies for known vulnerabilities

Failing the CI build seems too drastic. My suggestion is to create a new profile that activates thisfunctionality and encourage people to run with this profile and file JIRAs when somethingexciting happens. Ram On Wednesday, November 1, 2017, 1:26:00 PM PDT, Thomas Weise

Re: checking dependencies for known vulnerabilities

Considering typical behavior, unless the CI build fails, very few will be interested fixing the issues. Perhaps if after a CI failure the issue can be identified as pre-existing, we can whitelist and create a JIRA that must be addressed prior to the next release? On Wed, Nov 1, 2017 at 7:51 PM,

Re: checking dependencies for known vulnerabilities

I would like to hear what others think.. at this point I am -1 on merging the change as is that would fail all PR builds when a matching CVE is discovered regardless of whether the PR was the cause of the CVE or not. On Wed, Nov 1, 2017 at 12:07 PM, Vlad Rozov wrote: > On

Re: checking dependencies for known vulnerabilities

On 11/1/17 11:39, Pramod Immaneni wrote: On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov wrote: There is no independent build and the check is still necessary to prevent new dependencies with CVE being introduced. There isn't one today but one could be added. What kind of

Re: checking dependencies for known vulnerabilities

On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov wrote: > There is no independent build and the check is still necessary to prevent > new dependencies with CVE being introduced. > There isn't one today but one could be added. What kind of effort is needed. > > Look at Malhar

Re: checking dependencies for known vulnerabilities

There is no independent build and the check is still necessary to prevent new dependencies with CVE being introduced. Look at Malhar 3.8.0 thread. There are libraries from Category X introduced as a dependency, so now instead of dealing with the issue when such dependencies were introduced,

Re: checking dependencies for known vulnerabilities

Any other concerns regarding merging the PR? By looking at the active PRs on the apex core the entire conversation looks to be at the moot point. Thank you, Vlad On 10/30/17 18:50, Vlad Rozov wrote: On 10/30/17 17:30, Pramod Immaneni wrote: On Sat, Oct 28, 2017 at 7:47 AM, Vlad Rozov

Re: checking dependencies for known vulnerabilities

On 10/30/17 17:30, Pramod Immaneni wrote: On Sat, Oct 28, 2017 at 7:47 AM, Vlad Rozov wrote: Don't we use unit test to make sure that PR does not break an existing functionality? For that we use CI environment that we do not control and do not introduce any changes to, but

Re: checking dependencies for known vulnerabilities

On Sat, Oct 28, 2017 at 7:47 AM, Vlad Rozov wrote: > Don't we use unit test to make sure that PR does not break an existing > functionality? For that we use CI environment that we do not control and do > not introduce any changes to, but for example Apache infrastructure team

Re: checking dependencies for known vulnerabilities

Don't we use unit test to make sure that PR does not break an existing functionality? For that we use CI environment that we do not control and do not introduce any changes to, but for example Apache infrastructure team may decide to upgrade Jenkins and that may impact Apex builds. The same

Re: checking dependencies for known vulnerabilities

On Fri, Oct 27, 2017 at 11:51 AM, Vlad Rozov wrote: > On 10/26/17 11:46, Pramod Immaneni wrote: > >> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov wrote: >> >> I guess you are mostly concerned regarding new CVE in an existing >>> dependency. Once such CVE is

Re: checking dependencies for known vulnerabilities

On 10/26/17 11:46, Pramod Immaneni wrote: On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov wrote: I guess you are mostly concerned regarding new CVE in an existing dependency. Once such CVE is added to a database, will it be better to know about it or postpone discovery till we

Re: checking dependencies for known vulnerabilities

On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov wrote: > I guess you are mostly concerned regarding new CVE in an existing > dependency. Once such CVE is added to a database, will it be better to know > about it or postpone discovery till we cut release candidate? In case it is >

Re: checking dependencies for known vulnerabilities

I guess you are mostly concerned regarding new CVE in an existing dependency. Once such CVE is added to a database, will it be better to know about it or postpone discovery till we cut release candidate? In case it is reported only during release cycle, there is much less time for the

Re: checking dependencies for known vulnerabilities

On Thu, Oct 26, 2017 at 12:08 AM, Vlad Rozov wrote: > There is a way to add an exception, but it needs to be discussed on a case > by case basis. Note that CVEs are not published until a fix is available. > For severity 8 CVEs I expect patches to become available for the

Re: checking dependencies for known vulnerabilities

There is a way to add an exception, but it needs to be discussed on a case by case basis. Note that CVEs are not published until a fix is available. For severity 8 CVEs I expect patches to become available for the reported version unless it is an obsolete version in which case, the upgrade to

Re: checking dependencies for known vulnerabilities

Thanks that sounds mostly fine except what happens if there is a cve matching that severity in a dependency but it doesnt affect us because let's say we don't exercise that part of functionality *and* there isn't a fix available or there is a fix but the upgrade requires significant effort (for

Re: checking dependencies for known vulnerabilities

A CVE (should there be a vulnerability in existing or a newly introduced dependency) will not be exposed during the CI build, but the build will fail if the CVE has severity 8 or above. To get the details, it will be necessary to run dependency check manually. Thank you, Vlad On 10/24/17

Re: checking dependencies for known vulnerabilities

There was a lot of discussion on this but looks like there was no final agreement. Can you summarize what your PR does? Are we disclosing the actual vulnerabilities as part of the automated build for every PR? That would be a no-no for me. If it is something that requires manual steps, for example

Re: checking dependencies for known vulnerabilities

Please see https://github.com/apache/apex-core/pull/585 and APEXCORE-790. Thank you, Vlad On 9/14/17 09:35, Vlad Rozov wrote: Do you expect anything else from the community to recognize a contribution other than committing it to the code line? Once there is a steady flow of quality

Re: checking dependencies for known vulnerabilities

Do I understand your suggestion correctly that Apex should allow contributions that introduce dependencies with critical security CVE or that breaks CI build for the sake of not making contributions difficult for contributors that do not have appetite to deal with CI build or check

Re: checking dependencies for known vulnerabilities

I had one more point to add. During adding such checks we should think of all types of contributors. We don't want to make it very difficult to people to get in their PR, it will discourage people from putting any code changes. Ultimately we want to grow as a community where we would like people

Re: checking dependencies for known vulnerabilities

For a vendor too, quality ought to be as important as security so I don't think we disagree on the cost benefit analysis. But I get your drift. By "creative incentive" I didn't imply any material incentive (although a gift card would be nice :-)) but more along the lines of what a community can

Re: checking dependencies for known vulnerabilities

I guess we have a different view on the benefit and cost definition. For me the benefit of fixing CI build, flaky unit test, severe security issue is huge for the community and is possibly small (except for a security issues) for a vendor. By "creative" I hope you don't mean that other

Re: checking dependencies for known vulnerabilities

I don't want to speak for others and I don't want to generalize. But an obvious answer could be "cost-benefit analysis". In any case we should come up with a creative way to "incentivize" members to do these tasks. On Mon, Sep 11, 2017 at 10:59 PM, Vlad Rozov wrote: > So,

Re: checking dependencies for known vulnerabilities

So, you are saying that those members are eager to see new features, new functionalities and new code added to the project? Why they are not eager to see a unit test being fixed or a dependency with a severe security risk being removed? It is not that their original PR would be closed as a

Re: checking dependencies for known vulnerabilities

Comments inline: > On 9/10/17 23:40, Priyanka Gugale wrote: > >> 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

Re: checking dependencies for known vulnerabilities

Please see my comments inline. Thank you, Vlad On 9/10/17 23:40, Priyanka Gugale wrote: 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"

Re: checking dependencies for known vulnerabilities

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

Re: checking dependencies for known vulnerabilities

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

Re: checking dependencies for known vulnerabilities

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

Re: checking dependencies for known vulnerabilities

Can we build a way into CI to distinguish between these and a new vulnerability that has come up in an unchanged dependency? On Fri, Sep 8, 2017 at 3:44 PM, Thomas Weise wrote: > On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni > wrote: > > > Though I

Re: checking dependencies for known vulnerabilities

Amol, Build may fail for multiple reasons, unless it outputs details of CVE that outlines how vulnerability can be exploited, the vulnerability is not exposed to the public. I am +1 that it is better to know and monitor vulnerabilities than to proceed with a risk of introducing new

Re: checking dependencies for known vulnerabilities

+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 wrote: Though I like the

Re: checking dependencies for known vulnerabilities

On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni 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

Re: checking dependencies for known vulnerabilities

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

Re: checking dependencies for known vulnerabilities

I believe the cost will be higher as it won't be like checkstyle where we establish a baseline because these are external dependencies and I am sure vulnerabilities are being reported all the time. I don't mind trying this out with release as the checkpoint where these issues need to be addressed

Re: checking dependencies for known vulnerabilities

My response inline On Fri, Sep 8, 2017 at 3:20 PM, Vlad Rozov 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

Re: checking dependencies for known vulnerabilities

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

Re: checking dependencies for known vulnerabilities

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

Re: checking dependencies for known vulnerabilities

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

Re: checking dependencies for known vulnerabilities

+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 wrote: > Any objections to implementing https://www.owasp.org/index.ph > p/OWASP_Dependency_Check maven plugin that