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