Apologies I don't think I will make it due to reschedules from yesterday's holiday.

Justin

On Tue, Apr 6, 2021 at 1:33 AM Amye Scavarda Perrin <ascavarda@...> wrote:

Hi all, 

We'll be meeting tomorrow at 8am Pacific.

Agenda: https://docs.google.com/document/d/1jpoKT12jf2jTf-2EJSAl4iTdA7Aoj_uiI19qIaECNFc/edit

Presentation: https://docs.google.com/presentation/u/2/d/1jfMLPvO-oRFSwCyNYWCmZnhY5_qwi0PKinuvSMKmkxs/edit#slide=id.g25ca91f87f_0_0 

Thanks! 

--

Amye Scavarda Perrin | Program Manager | amye@...

Hi all, 

We'll be meeting tomorrow at 8am Pacific.

Agenda: https://docs.google.com/document/d/1jpoKT12jf2jTf-2EJSAl4iTdA7Aoj_uiI19qIaECNFc/edit

Presentation: https://docs.google.com/presentation/u/2/d/1jfMLPvO-oRFSwCyNYWCmZnhY5_qwi0PKinuvSMKmkxs/edit#slide=id.g25ca91f87f_0_0 

Thanks! 

--

Amye Scavarda Perrin | Program Manager | amye@...

+1 binding 

On Thu, 4 Mar 2021 at 17:53, Johan Tordsson via lists.cncf.io <johan.tordsson=elastisys.com@...> wrote:

+1 NB

Den 2021-03-03 kl. 20:44, skrev Richard Li:

+1 NB

On Wed, Mar 3, 2021 at 2:42 PM Chris Short <chris@...> wrote:

+1 non-binding

Chris Short

He/Him/His

Blog | Newsletter | Twitch | Twitter | LinkedIn

TZ=America/Detroit

On Wed, Mar 3, 2021 at 2:40 PM Adam FitzGerald via lists.cncf.io <adam.fitzgerald=hashicorp.com@...> wrote:

+1 NB

Regards

Adam

On Wed, Mar 3, 2021 at 7:19 AM Flynn <flynn@...> wrote:

+1 NB

-- 
Johan Tordsson, PhD
CTO & Co-founder
www.elastisys.com

Not on the TOC, so hope it's ok to comment.

I have the same concerns as Liz, quite often metrics are gathered without all factors considered.

Take kubernetes for example, huge code base, huge user base and so many eyes looking to find vulnerabilities, compounded even more by a financial incentive with the bug bounty system. I monitor the hackone queue as a PSC member, and they come in thick and fast everyday (pleased to say most of them are invalids).

This naturally results in a high vulnerability count, but it's not as simple as a high count equals bad project, if just means more have been discovered, not necessarily produced. 

I am also sceptical of using code scanners to assess the security posture of a project, great tools to use, but they do get it wrong and unless the false positives are constantly pruned out, they will make a project look much worse than it is.  I can say this even after maintaining an OSS scanner project that hits around 100k downloads a week [0]

[0] https://github.com/PyCQA/bandit 

On Wed, Feb 17, 2021 at 10:05 AM Liz Rice <liz@...> wrote:

I've realised that one reason the results look so damning for the projects is that they are the sum of vulnerabilities found over a period of time (and an arbitrary period of time at that). For example, here's the front page result for Kubernetes, which makes it look incredibly bad: 

It's pretty hard to tell, but I think this is telling me that the latest release of Kubernetes has 9 high sev vulns, not 261

These pretty graphs are pointless if they don't convey useful information. IMO, the most useful result for an end user is whether the current release has vulnerabilities. What maintainers need to see is what vulnerabilities exist in the currently-supported set of releases, plus the main branch. Neither of these are currently easy to access, as presented. 

Liz

On Tue, Feb 16, 2021 at 7:38 PM Alexis Richardson <alexis@...> wrote:

I understand this is Beta

I believe all of the CNCF community should have equal access.   

On Tue, 16 Feb 2021 at 19:25, Chris Aniszczyk <caniszczyk@...> wrote:

Alexis, the tool is freely available just like a variety of other security tools that CNCF projects use, from LFX Security (white labeled Snyk), Snyk, FOSSA, CodeQL, WhiteSource etc, lots of great options out there that we all support and encourage projects to check out. This tool is simply white labeled Snyk so it's nothing necessarily new and properly labeled here: https://github.com/cncf/servicedesk#tools - projects use what is best for them always.  We will have it setup for Flux soon for you to experiment with both inside and outside of GitHub.

To Liz's point, like any security tool, there's a ton of false positives to deal with and should be handled on a per project / maintainer basis. Almost by default, every project looks terrible based on the default scan. This is why things like GitHub's codescan tooling is built in by default to only show information to maintainers: first https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/about-code-scanning

The LFX Security work is still in "beta" and a work in progress so keep that in mind.

On Tue, Feb 16, 2021 at 1:10 PM Alexis Richardson <alexis@...> wrote:

I strongly disagree Chris, this is a great resource that all should be aware of.

Now that we don’t have FPs, can we just publish the data?  Please do not assume that end users will not run their own scans too

On Tue, 16 Feb 2021 at 18:49, Chris Aniszczyk <caniszczyk@...> wrote:

+1 to what Liz said here, this should be opt-in for project maintainers like any tool

Can we please just leave this as a per project decision as any other tool as we decided last time this came up, the TOC list is the wrong place for this discussion

https://github.com/cncf/servicedesk#tools

Thanks!

On Tue, Feb 16, 2021 at 12:47 PM Shubhra Kar <skar@...> wrote:

The scan data from Snyk right now is fairly clean as they curate and weed out false positives proactively. In the tool, we do have flags on the bugs to dismiss it (in case it's still a false positive).

We can definitely put a big Beta tag on the service. We are adding code secrets scanning from another vendor partnership in the next couple of months. We are planning to provide a  "regex" filter to maintainers to eliminate FPs globally as well. 

Shubhra

On Tue, Feb 16, 2021, 10:36 AM Liz Rice <liz@...> wrote:

I have an idea that there were concerns about making the data publicly available because of false positives, and the worry that if projects appear (incorrectly) to be unsafe that will impede adoption. Do we have progress on reducing those FPs e.g. being able to flag parts of a project as not relevant to scan? (I hope Kubernetes doesn't really have 261 high-severity vulnerabilities, as it currently appears). 

Can we also more clearly flag that this is a work in progress? 

Thanks,

Liz

On Tue, Feb 16, 2021 at 6:23 PM Shubhra Kar <skar@...> wrote:

Essentially we want them to create LFIDs to grant access.

Shubhra

On Tue, Feb 16, 2021, 10:05 AM Vasu Naidu <vnaidu@...> wrote:

Thanks Stephen.

 

We have granted access to given access to stefan@....

 

We are unable to find accounts for hidde@... and michael@... .

 

Regards,

Vasu

 

 

From: Stephen Augustus <hey@...>
Date: Tuesday, February 16, 2021 at 9:52 AM
To: Shubhra Kar <skar@...>
Cc: Alexis Richardson <alexis@...>, Vasu Naidu <vnaidu@...>, St Leger, Jim <jim.st.leger@...>, Chris Aniszczyk <caniszczyk@...>, Pranab Bajpai (pbajpai@...) <pbajpai@...>, Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] security & CNCF projects

As I understand it, https://maintainers.cncf.io/ holds the aggregate maintainers for CNCF project.

For flux, specifically: https://github.com/fluxcd/flux/blob/master/MAINTAINERS

 

-- Stephen

 

On Tue, Feb 16, 2021 at 12:46 PM Shubhra Kar <skar@...> wrote:

I would suggest we add access for all the maintainers of the project and anyone on the governance committees (example TSCs).

 

Do you maintain a maintainers.md file or better for us to just scan the repos and find the contributors ?

Kind Regards,

 

Shubhra Kar

CTO and GM of Products and IT

tweet: @shubhrakar

 

 

On Tue, Feb 16, 2021 at 9:10 AM Alexis Richardson <alexis@...> wrote:

thanks, how do I share these with the flux maintainers and community

 

On Tue, Feb 16, 2021 at 4:59 PM Vasu Naidu <vnaidu@...> wrote:

Hi Alexis,

 

You should have access to the security reports of the flux project. Please let me know if you have any questions.

 

https://security.lfx.linuxfoundation.org/#/a0941000002wBz4AAE/foundation-details

 

Regards,

Vasu

 

 

From: St Leger, Jim <jim.st.leger@...>
Date: Tuesday, February 16, 2021 at 7:06 AM
To: Chris Aniszczyk <caniszczyk@...>, alexis richardson <alexis@...>, Pranab Bajpai (pbajpai@...) <pbajpai@...>, Vasu Naidu (vnaidu@...) <vnaidu@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: RE: [cncf-toc] security & CNCF projects

+ Pranab and Vasu (product/eng leads on LFX I believe.)

 

Jim

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Chris Aniszczyk
Sent: Tuesday, February 16, 2021 7:13 AM
To: alexis richardson <alexis@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] security & CNCF projects

 

I'll follow up Alexis on the ticket but it's just white labeled https://snyk.io 

 

If you are already using, say Snyk via github action (https://github.com/snyk/actions/tree/master/golang) you won't see anything new (which is available for open source projects).

 

On Tue, Feb 16, 2021 at 3:54 AM alexis richardson <alexis@...> wrote:

Hi all

 

Has anyone looked at this? 

https://security.lfx.linuxfoundation.org/#/

 

How do we see project data?  I wanted to take a look at flux.  I had to create a login.  Then, I had to "request" a view, which turned out to mean filing a JIRA ticket.  Since then, tumbleweed.

 

Can we have something more open & useful please?

 

a

 

 

 

--

Chris Aniszczyk (@cra)

--

Chris Aniszczyk (@cra)

--

Chris Aniszczyk (@cra)

+1

On Tue, Mar 2, 2021 at 5:21 PM Alex Chircop <alex.chircop@...> wrote:

Hi all,

As a follow up from the TOC call today, the Storage SIG would like to nominate two candidates for the tech lead role: Raffaele Spazzoli and Sheng Yang.   Both have been members of the SIG for a while and have been active contributors - they will continue to help strengthen the community and bring a wealth of experience and expertise to the group.

Following the SIG operating model, Tech leads are assigned following a 2/3 majority vote of the TOC and a 2/3 majority vote of SIG Chairs.

Short bios are listed below for convenience:

Raffaele Spazzoli - Tech Lead Nominee

Senior Principal Architect - Red Hat

Raffaele is a full-stack enterprise architect with 20+ years of experience. Raffaele started his career in Italy as a Java Architect then gradually moved to Integration Architect and then Enterprise Architect. Later he moved to the United States to eventually become an OpenShift Architect for Red Hat consulting services, acquiring, in the process, knowledge of the infrastructure side of IT.  Currently Raffaele covers a consulting position of cross-portfolio application architect with a focus on OpenShift. Most of his career Raffaele worked with large financial institutions allowing him to acquire an understanding of enterprise processes and security and compliance requirements of large enterprise customers.

Sheng Yang - Tech Lead Nominee

Senior Manager, Engineering - SUSE

Sheng Yang is a Senior Manager and Software Architect at SUSE. He is a maintainer of project Longhorn, CNCF's open-source Cloud Native distributed storage solution. He joined SUSE through the Rancher Labs acquisition, where he worked on Longhorn, Harvester, local path provisioner, and other projects. Before Rancher Labs, he joined Citrix through the Cloud.com acquisition, where he worked on CloudStack project and CloudPlatform product. Before that, he had spent a few years as a kernel developer at Intel, focused on KVM, Xen, and Linux kernel development. He has worked in the fields of virtualization and cloud computing for the last fourteen years.

Kind Regards,

Alex Chircop

Co-chair CNCF SIG Storage

Dear Liz,

I am cc-ing TOC, SIG Observability, Alolita, Constance, Priyanka, Richi and Chris for transparency.

During the last SIG Observability call on 2021-03-16, when I was recommending against the OpenTelemetry incubation, it was stated that I had “conflict of interest”, “bias”, “subjective opinion” and “rude behavior”.

I take those things very seriously. I am afraid that this accusation not only impacts me personally and professionally. Such accusation potentially silences any diverse, opposite opinions in the SIG Observability community. I already saw this during the calls with OpenTelemetry when many SIG members did not have enough safety to speak up and were contacting me privately to agree instead.

To be clear, I am not offended. I just want to find a positive resolution and finish my work. At this point, I don’t know how and I’m asking for help. I would like to ask for an outside review of all my actions, documents and calls as the Tech Lead SIG Observability, doing Due Diligence for the OpenTelemetry. My honest belief is that I performed the assessment thoroughly and objectively to my best ability. I looked at all aspects of OpenTelemetry in the context of the CNCF Principles and Incubation requirements. I did an investigation and interviewed developers and users and listened to the advantages of OpenTelemetry.

These accusations should be proven or disproven. I would love to improve my work if I did it wrong. I would love the feedback.

We can discuss my assessment on the technical level, but last SIG Observability calls were less about the technical aspect, more about attempts to adjust Tech Lead opinion, make it sound softer, mask it (e.g put it out of the DD document), or even disregard completely from the TOC eyes due to accusations. I am not a decision-maker, I would be happy with any decision CNCF will make in the end. I only want my assessment to be registered as I take my duties as the Tech Lead seriously.

Relevant SIG Observability calls:

• 2021-02-02

• 2021-02-16

• 2021-03-02

• 2021-03-09 (extra call outside of 2w schedule, asked for to speedup due diligence)

• 2021-03-16

Relevant documents: 

• OpenTelemetry Incubation Proposal

• Tech Lead Assessment 

• SIG Observability Meeting Notes

I would greatly appreciate your feedback.

Kind Regards,

Bartek Plotka, SIG Observability Tech Lead