+1 NB

+1 binding From:cncf-toc@... <cncf-toc@...> on behalf of Amye Scavarda Perrin via lists.cncf.io <ascavarda=linuxfoundation.org@...> Date: Friday, February 19, 2021 at 10:41 AM To: CNCF TOC

+1 nb

+1 binding

+1 Non-binding. I’m really excited by the “toolkit” approach that is part of flux2. That, for me, makes this much more useful in many more situations. Joe From:cncf-toc@...

The Flux project has applied to move from sandbox to incubation: (https://github.com/cncf/toc/pull/567) The due diligence document can be found here:

Sounds great. We're ready to call for a vote then if you'll do the honors @Amye. Thanks all.

Thanks Michael, Daniel & Stefan for your responses - this all seems reasonable to me so you can consider my comments resolved :-)

Dear CNCF TOC, We are happy to share that the annual review for KEDA is open on https://github.com/cncf/toc/pull/607. Kind regards, Tom Kerkhove Microsoft Azure MVP & Advisor - GitHub Star – CNCF

In this week's meeting we talked about renaming CNCF SIGs to TAGs (Technical Advisory Group) to avoid confusion with the pre-existing Kubernetes SIGs. As discussed, the current confusion is real,

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

thanks Liz this is a *terrific resource* that costs lots of money & time, and it is useless if we don't make it public and prune out old stuff

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

I understand this is Beta I believe all of the CNCF community should have equal access.

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

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

+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 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

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.

Idea: It would be cool if all CNCF projects had the same metadata for representing "maintainers". If that was standardized, some tool could ingest and compare against LFIDs. -- Stephen