toggle quoted messageShow quoted text
Can we have a refresh on this.
I think we need to get grown up about security processes for our projects.
On Wed, 17 Feb 2021, 11:44 Luke Hinds, <lhinds@...
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 
On Wed, Feb 17, 2021 at 10:05 AM Liz Rice <liz@...
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.
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.
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.
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
+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
On Tue, Feb 16, 2021 at 12:47 PM Shubhra Kar <skar@...
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.
On Tue, Feb 16, 2021, 10:36 AM Liz Rice <liz@...
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?
On Tue, Feb 16, 2021 at 6:23 PM Shubhra Kar <skar@...
Essentially we want them to create LFIDs to grant access.
On Tue, Feb 16, 2021, 10:05 AM Vasu Naidu <vnaidu@...
We have granted access to
given access to stefan@....
We are unable to find accounts for
hidde@... and michael@... .
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 ?
CTO and GM of Products and IT
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:
+ Pranab and Vasu (product/eng leads on LFX I believe.)
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
On Tue, Feb 16, 2021 at 3:54 AM alexis richardson <alexis@...> wrote:
Has anyone looked at this?
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,
Can we have something more open & useful please?