Enable Snyk and White-source scanning on knative repos

[steven0711dong]

Problem
We see some dependencies that are considered as vulnerable by both Snyk and White-source scanning. I found out about this because our organization does the scanning after we clone the repo. Keda does both snyk and white-source scanning so I would like to propose that we enabled these 2 scans on this repo as well so that any vulnerable libraries could be caught on PR and people no longer open git issues on vulnerable libraries and users that have dependency on this repo do not have to patch the vulnerable libraries themselves. Any new vulnerable libraries introduced by contributors should be caught immediately after PR creation and commits. Existing libraries that are considered to have vulnerabilities should be caught by nightly scan.

[krsna-m]

/kind security

[steven0711dong]

White-source and Snyk scanning

Current status:

Currently there is no scanning tool in knative workspace that discovers vulnerable libraries. Cloned knative repos(downstream repos) in other organizations ends up having to deal with each individual vulnerability on their own. This creates two issues:

1. By replacing the vulnerable libraries in, downstream repos end up with a knative project with different dependencies. And this is a less than optimal situation because the new dependencies were introduced after the continuous development process, which happens before PR merge in upstream repo.

2. Some projects such as k8s.io/utils, knative/eventing are frequently referenced in other projects and the projects became inter-connected. So it is common to end up with a scenario that after replacing the direct dependent vulnerable libraries, the vulnerability still shows up in the scan because indirect dependency on the vulnerable library still exists, and we end up having to patch another repo.

Potential action items:

• Obtain license and setup WhiteSource Bolt/Snyk scan tool on knative repos.
• Update Security Policy

We should try our best effort to enable white-source and snyk scan generic enough to run on across all knative repos in our workspace. Since knative heavily depends on k8s repos, I'm also working to try convince k8s community to adopt white-source and snyk scan.

[krsna-m]

@carlisia is also working on security scanning. Would be nice to hear her thoughts as well.

[steven0711dong]

@carlisia Hi, I'm working on enabling white-source scan and snyk scan on this repo, could you take a look at the proposal I wrote above and see whether you have anything to add?

[carlisia]

Hey @steven0711dong, apologies for not responding earlier. Initially I am very much onboard with this. Some time ago I had installed a Snyk extension for my editor and it worked well. Maybe too well, I turned it off because there were too many warnings (forgot which project).

Thank you so much for bringing this up.

I haven't had a chance to look into the license issue. Do you know what is required for us to be able to run each on our CI systems, is there a cost?

Have you set these up before? I'm wondering how much time/effort this will be, and if it's a straight up config or if there could be some trial/error/tweak time to be accounted for.

I am thinking that probably would be wise to set aside resources (human time) to address the bulk of the warnings we currently will get in each of our repos. Does this thinking make sense? Maybe we can phase in an implementation where we slowly turn on separate categories of scanning to get this done in a sustainable pace. But I don't actually know if their scanning have settings for categories of vulnerabilities that could be turned off. I can look into this, unless you know already.

Lastly, we should aim to not make the contributor experience worse. In this case, we would avoid going in that direction if we could have the same check available for Knative developers to run locally, regardless of what IDE/editor they use. Ideally, a script (maybe the same that CI runs). This way they/we wouldn't be surprised with warnings only after running PR checks. Also something I haven't looked at, please let us know if you have ideas here.

Let us know about the questions above.

@kvmware:

• if we go ahead with this I'd suggest we pick a repo to try it on first. I'd be glad to try it on one of the net-* repos unless you have another candidate. What do you think?
• is this something we would want to add as a periodic job to testgrid, do you know?

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.