[cncf-sig-security] [cncf-toc] Vulnerability scanning for CNCF projects


Vinay Venkataraghavan <vvenkatara@...>
 

Hello everyone, 
Just catching up on the thread and a little late to the discussion. I'm in total agreement with other points already brought up that we should:
  • Have some policies and guidance around visibility into the vulnerabilities in container images. 
  • Broad guard rails which call out certain gates that have to pass (within reason). 
  • Sticking to process of visibility and continuous improvement to ensure that over time the incubating and graduated projects are improving their security posture. 
I love the dashboard of the LFX security tool / project. Would be great to see how we could either incorporate or expand that for other security usecases for projects going through graduation. 
Thanks,
- Vinay 




On Thu, Nov 19, 2020 at 10:01 AM Emily Fox <themoxiefoxatwork@...> wrote:
Same!   We would love a presentation!  Shubhra please add itself to the agenda for an upcoming meeting in December.

The Security SIG group meets every Wednesday at 10:00am PT (USA Pacific)

Meeting minutes and agenda:https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/

- Emily Fox

@TheMoxieFox (personal handle)

On Thu, 19 Nov 2020, 12:26 Justin Cormack via lists.cncf.io, <justin.cormack=docker.com@...> wrote:
I would be interested in that. 

Justin


On Thu, 19 Nov 2020 at 17:23, Shubhra Kar <skar@...> wrote:
If this group is interested, my team would love to present the capabilities and limitations alike of the LFX security tool project. We are working on items like creating a SBOM policy management, adding support for scanning build systems and container images next. Secrets management and static analysis are longer term roadmap items. 

Top challenges we need to solve collectively relatively quickly:

1. The tool provides capability to turn on/off dev dependencies, need the group to identify if we need to do that and which dev dependencies in particular. Project maintainers are probably the best equipped to determine this list.
2. A project is usually spread over multiple orgs and repo combinations. Some repos don't have a manifest file, which LFX needs in order to scan. A best practice would be to ensure there is consistent manifest creation.


Kind Regards,

Shubhra Kar
CTO and GM of Products and IT
tweet: @shubhrakar



On Wed, Nov 18, 2020 at 8: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



--
Technical Director, Office of the CTO
Prisma Cloud | Palo Alto Networks


Emily Fox
 

Same!   We would love a presentation!  Shubhra please add itself to the agenda for an upcoming meeting in December.

The Security SIG group meets every Wednesday at 10:00am PT (USA Pacific)

Meeting minutes and agenda:https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/

- Emily Fox

@TheMoxieFox (personal handle)


On Thu, 19 Nov 2020, 12:26 Justin Cormack via lists.cncf.io, <justin.cormack=docker.com@...> wrote:
I would be interested in that. 

Justin


On Thu, 19 Nov 2020 at 17:23, Shubhra Kar <skar@...> wrote:
If this group is interested, my team would love to present the capabilities and limitations alike of the LFX security tool project. We are working on items like creating a SBOM policy management, adding support for scanning build systems and container images next. Secrets management and static analysis are longer term roadmap items. 

Top challenges we need to solve collectively relatively quickly:

1. The tool provides capability to turn on/off dev dependencies, need the group to identify if we need to do that and which dev dependencies in particular. Project maintainers are probably the best equipped to determine this list.
2. A project is usually spread over multiple orgs and repo combinations. Some repos don't have a manifest file, which LFX needs in order to scan. A best practice would be to ensure there is consistent manifest creation.


Kind Regards,

Shubhra Kar
CTO and GM of Products and IT
tweet: @shubhrakar



On Wed, Nov 18, 2020 at 8: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