1. Messages
  2. [cncf-sig-security] Vulnerability scanning for CNCF projects

Re: [cncf-sig-security] Vulnerability scanning for CNCF projects

Chris Aniszczyk
 

" Should we have something in place for requiring projects to have a process to fix vulnerability issues (at least the serious ones)?"

We have a graduation requirement around CII badging which requires a security disclosure process so it's there but not codified formally, we could do that, I think the important thing is that projects also publish advisories in a standard way (like via the github security API)

We should treat the LF tool suite as another option for projects to take advantage of, already many projects are using Snyk, FOSSA, Whitesource etc that is listed here: https://github.com/cncf/servicedesk#tools

You can kind of get an SBOM (depending you define sbom ;p) for some of our projects already: https://app.fossa.com/attribution/c189c5b9-fe2c-45f2-ba40-c34c36bab868

I think offering projects more choice is always better as the landscape changes often in tooling.

On Wed, Nov 18, 2020 at 10:54 AM Emily Fox <themoxiefoxatwork@...> wrote:
Liz,
  Love this.  As part of the assessments SIG-Security performs, we've begun highlighting the importance of secure development practices.  The last few assessments we've begun pushing more for this, as well as responsible disclosure instructions and general security mindedness for project sustainment.   This fits in alignment with those efforts.  We currently have the assessment process undergoing some updates (held currently for kubecon) and this make it a great time to potentially include this.  I personally would like to see license dependencies and dependency trees to help push forward in the area of SBOM.
  I think we should be clear however in what our thresholds and terms are in this area, offhand i can think of the following potentials:
* Listing of vulns in deliverable artifacts
* Listing licensing dependencies
* SBOM
* vulnerability threshold and prioritizing resolution in prior to artifact delivery
* vulnerability threshold and prioritizing resolution post artifact delivery

Definitely worth a conversation and follow-ups.  Do you have anything in mind that are must haves off the above or anything I missed or misunderstood?

~Emily Fox


On Wed, Nov 18, 2020 at 11:41 AM Liz Rice <liz@...> wrote:
Hi TOC and SIG Security folks 

On Friday I got a nice preview from Shubhra Kar and his team at the LF about some tools they are building to provide insights and stats for LF (and therefore CNCF) projects. One that's of particular interest is an integration of scanning security issues.

We require graduated projects to have security reviews, and SIG Security are offering additional assessments, but we don't really have any standards around whether project artifacts shipping with vulnerabilities. Should we have something in place for requiring projects to have a process to fix vulnerability issues (at least the serious ones)? 

This tooling is off to a great start. The current numbers for a lot of our projects look really quite bad, but this may be to do with scanning all the repos related to a project's org. I'd imagine there are also some false positives from things like dependencies only used in test that don't affect the security of the executables that end users run - we may want to look at just reporting vulnerabilities from a project's deployable artifacts. 

As well as vulnerability scanning this is showing license dependencies, which could be very useful.

For discussion, how we want to use this kind of info, and whether we want to formalize requirements on projects (e.g. at graduation or incubation levels).  

Copying Shubra in case he would like to comment further. .

Enjoy KubeCon!
Liz



--
Chris Aniszczyk (@cra)
Join {cncf-toc@lists.cncf.io to automatically receive all group messages.