Date   

Re: [VOTE] Flux for incubation

banu.parasuraman@wipro.com
 

+1 ,

GitOps is the Way

 

Banu A Parasuraman

Chief Technologist – Cloud Native

+1-734-9287788

 

From: <cncf-toc@...> on behalf of "Toni Menzel via lists.cncf.io" <toni.menzel=rebaze.com@...>
Reply-To: "toni.menzel@..." <toni.menzel@...>
Date: Friday, February 19, 2021 at 1:03 PM
To: Amye Scavarda Perrin <ascavarda@...>, CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] Flux for incubation

 

CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
.
 

+1 non-binding. Go GitOps! ;)

 

rebaze GmbH | Develop Like Tomorrow

Developer focused Technology Consulting & Cloud Native Infrastructure.

 


From: cncf-toc@... <cncf-toc@...> on behalf of Amye Scavarda Perrin <ascavarda@...>
Sent: Friday, February 19, 2021 7:40:33 PM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] Flux for incubation

 

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: https://docs.google.com/document/d/1Z6yPN9-bWeVGpMrBxXJ3NBTBYZowJ3R93wKHEVmBJ1A/edit#heading=h.kd4eg2uz3lt0

Michelle Noorali has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5679

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

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

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'


Re: [VOTE] Flux for incubation

Toni Menzel
 

+1 non-binding. Go GitOps! ;)

rebaze GmbH | Develop Like Tomorrow
Developer focused Technology Consulting & Cloud Native Infrastructure.


From: cncf-toc@... <cncf-toc@...> on behalf of Amye Scavarda Perrin <ascavarda@...>
Sent: Friday, February 19, 2021 7:40:33 PM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] Flux for incubation
 
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: https://docs.google.com/document/d/1Z6yPN9-bWeVGpMrBxXJ3NBTBYZowJ3R93wKHEVmBJ1A/edit#heading=h.kd4eg2uz3lt0

Michelle Noorali has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5679

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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


Re: [VOTE] Flux for incubation

Justin Cormack
 

+1 binding.


On Fri, Feb 19, 2021 at 6:40 PM Amye Scavarda Perrin <ascavarda@...> wrote:
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: https://docs.google.com/document/d/1Z6yPN9-bWeVGpMrBxXJ3NBTBYZowJ3R93wKHEVmBJ1A/edit#heading=h.kd4eg2uz3lt0

Michelle Noorali has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5679

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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


Re: [VOTE] Flux for incubation

Ken Owens
 

+1 NB


On Fri, Feb 19, 2021, 12:40 PM Amye Scavarda Perrin <ascavarda@...> wrote:
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: https://docs.google.com/document/d/1Z6yPN9-bWeVGpMrBxXJ3NBTBYZowJ3R93wKHEVmBJ1A/edit#heading=h.kd4eg2uz3lt0

Michelle Noorali has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5679

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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


Re: [VOTE] Flux for incubation

Sheng Liang <sheng.liang@...>
 

+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 <cncf-toc@...>
Subject: [cncf-toc] [VOTE] Flux for incubation

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: https://docs.google.com/document/d/1Z6yPN9-bWeVGpMrBxXJ3NBTBYZowJ3R93wKHEVmBJ1A/edit#heading=h.kd4eg2uz3lt0

Michelle Noorali has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5679

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

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


Re: [VOTE] Flux for incubation

Jeff Billimek
 

+1 nb


Re: [VOTE] Flux for incubation

Michelle Noorali <michelle.noorali@...>
 

+1 binding

On Fri, Feb 19, 2021 at 1:45 PM Joe Beda <jbeda@...> wrote:

+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@... <cncf-toc@...> on behalf of Amye Scavarda Perrin <ascavarda@...>
Date: Friday, February 19, 2021 at 10:41 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] Flux for incubation

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: https://docs.google.com/document/d/1Z6yPN9-bWeVGpMrBxXJ3NBTBYZowJ3R93wKHEVmBJ1A/edit#heading=h.kd4eg2uz3lt0

Michelle Noorali has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5679

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

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


Re: [VOTE] Flux for incubation

Joe Beda <jbeda@...>
 

+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@... <cncf-toc@...> on behalf of Amye Scavarda Perrin <ascavarda@...>
Date: Friday, February 19, 2021 at 10:41 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] Flux for incubation

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: https://docs.google.com/document/d/1Z6yPN9-bWeVGpMrBxXJ3NBTBYZowJ3R93wKHEVmBJ1A/edit#heading=h.kd4eg2uz3lt0

Michelle Noorali has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5679

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

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


[VOTE] Flux for incubation

Amye Scavarda Perrin
 

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: https://docs.google.com/document/d/1Z6yPN9-bWeVGpMrBxXJ3NBTBYZowJ3R93wKHEVmBJ1A/edit#heading=h.kd4eg2uz3lt0

Michelle Noorali has called for the vote: https://lists.cncf.io/g/cncf-toc/message/5679

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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


Re: [cncf-flux-maintainers] [cncf-toc] Flux for Incubation Public Comment Period

Michelle Noorali <michelle.noorali@...>
 

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

Thanks all.

On Fri, Feb 19, 2021 at 12:16 PM Liz Rice <liz@...> wrote:
Thanks Michael, Daniel & Stefan for your responses - this all seems reasonable to me so you can consider my comments resolved :-) 


On Mon, Feb 15, 2021 at 6:37 PM Michael Bridgen <michael@...> wrote:
Hi Liz, Michelle, all,

Stefan and Daniel have responded on individual points. I'll attempt to fill in the remainder --

On Thu, 11 Feb 2021 at 14:17, Liz Rice <liz@...> wrote:
I see the note that Flux is working on a broader project description, which is great. Is this close? If it's possible I'd love to have this in place so that CNCF doesn't end up promoting a description that is out of date. 

The discussion in https://github.com/fluxcd/flux2/discussions/620 may run for a while. Current project descriptions for Flux are a little vague (my fault) and don't account for recent developments like Flagger being included; but I don't think they mischaracterise Flux. If they are not quite fit for official communications, we'll happily work with CNCF folks to tighten them up -- or indeed, put more effort into bringing #620 to a conclusion.

As I understand it the idea is to include Flagger as part of Flux in this move to Incubation? It's part of the gIthub.com/fluxcd org. But a couple of notes on the Flagger docs that I would like to see resolved before incubation: 
* The intro page says "Flagger is a Cloud Native Computing Foundation project." but doesn't mention that it's part of Flux
* Uses the Weave logo (though I see this is noted as a to-do in the DD doc) 

These are now resolved, as Stefan reported.
 
Looks like lots of work went into helping users transition from Flux v1 to v2. Do we know what proportion of end users have made the migration? When the Technology Radar put it in the "adopt" category, would this have referred to v1, v2, or a mixture? 

There is good circumstantial evidence that people are migrating from v1, in addition to those coming new to Flux v2:

 - there's a steady stream of people asking about using image update automation (a Flux v1 feature that's only recently been added to Flux v2). Some of those people mention holding off migration until they can use the automation, and some people appear to be migrating in two stages (without automation first, and planning to add the automation when ready);
 - similarly, people asking about updating from Helm operator (v1) to Helm controller (v2) -- this was made more urgent by Helm2 being deprecated, of course;
 - we get a lot of engagement from people who want parts of Flux v2 to work a little more like v1 (e.g., people weighing in on https://github.com/fluxcd/kustomize-controller/pull/253)

However, I'm afraid we don't have telemetry or other data from which to calculate the proportion of Flux v1 end users that have migrated.

The CNCF Technology Radar is based on reports from Flux v1 users only -- v2 was at version 0.0.1 at the time the radar was published. I feel that being placed in the "Adopt" category of the radar is not simply a one-off endorsement, but sets the bar to keep measuring ourselves against. In consequence, there's a strong impetus to help people migrate their systems to v2, and give them plenty of time, so they don't feel stranded and let down.

Something of a small aside - I think the first Q&A in this FAQ about Argo / Flux collaboration reflects the current status, but do the subsequent questions reflect what the aspirations were originally in the Flux/Argo collaboration? And those are no longer being worked on together, right?

Thanks for pointing that out -- after the first question, the FAQs there are out of date. Daniel has given things a nudge.

Cheers,
Michael


On Thu, Feb 4, 2021 at 2:00 PM Michelle Noorali via lists.cncf.io <michelle.noorali=microsoft.com@...> wrote:
Hello,

Flux is applying for incubation status:
DD has been reviewed by myself and SIG App Delivery. We've also conducted interviews with end users. We are supportive of Flux going into incubation. We are now calling for the 2 week public comment period prior to the vote.



Thank you,

Michelle Noorali


Re: [cncf-flux-maintainers] [cncf-toc] Flux for Incubation Public Comment Period

Liz Rice
 

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


On Mon, Feb 15, 2021 at 6:37 PM Michael Bridgen <michael@...> wrote:
Hi Liz, Michelle, all,

Stefan and Daniel have responded on individual points. I'll attempt to fill in the remainder --

On Thu, 11 Feb 2021 at 14:17, Liz Rice <liz@...> wrote:
I see the note that Flux is working on a broader project description, which is great. Is this close? If it's possible I'd love to have this in place so that CNCF doesn't end up promoting a description that is out of date. 

The discussion in https://github.com/fluxcd/flux2/discussions/620 may run for a while. Current project descriptions for Flux are a little vague (my fault) and don't account for recent developments like Flagger being included; but I don't think they mischaracterise Flux. If they are not quite fit for official communications, we'll happily work with CNCF folks to tighten them up -- or indeed, put more effort into bringing #620 to a conclusion.

As I understand it the idea is to include Flagger as part of Flux in this move to Incubation? It's part of the gIthub.com/fluxcd org. But a couple of notes on the Flagger docs that I would like to see resolved before incubation: 
* The intro page says "Flagger is a Cloud Native Computing Foundation project." but doesn't mention that it's part of Flux
* Uses the Weave logo (though I see this is noted as a to-do in the DD doc) 

These are now resolved, as Stefan reported.
 
Looks like lots of work went into helping users transition from Flux v1 to v2. Do we know what proportion of end users have made the migration? When the Technology Radar put it in the "adopt" category, would this have referred to v1, v2, or a mixture? 

There is good circumstantial evidence that people are migrating from v1, in addition to those coming new to Flux v2:

 - there's a steady stream of people asking about using image update automation (a Flux v1 feature that's only recently been added to Flux v2). Some of those people mention holding off migration until they can use the automation, and some people appear to be migrating in two stages (without automation first, and planning to add the automation when ready);
 - similarly, people asking about updating from Helm operator (v1) to Helm controller (v2) -- this was made more urgent by Helm2 being deprecated, of course;
 - we get a lot of engagement from people who want parts of Flux v2 to work a little more like v1 (e.g., people weighing in on https://github.com/fluxcd/kustomize-controller/pull/253)

However, I'm afraid we don't have telemetry or other data from which to calculate the proportion of Flux v1 end users that have migrated.

The CNCF Technology Radar is based on reports from Flux v1 users only -- v2 was at version 0.0.1 at the time the radar was published. I feel that being placed in the "Adopt" category of the radar is not simply a one-off endorsement, but sets the bar to keep measuring ourselves against. In consequence, there's a strong impetus to help people migrate their systems to v2, and give them plenty of time, so they don't feel stranded and let down.

Something of a small aside - I think the first Q&A in this FAQ about Argo / Flux collaboration reflects the current status, but do the subsequent questions reflect what the aspirations were originally in the Flux/Argo collaboration? And those are no longer being worked on together, right?

Thanks for pointing that out -- after the first question, the FAQs there are out of date. Daniel has given things a nudge.

Cheers,
Michael


On Thu, Feb 4, 2021 at 2:00 PM Michelle Noorali via lists.cncf.io <michelle.noorali=microsoft.com@...> wrote:
Hello,

Flux is applying for incubation status:
DD has been reviewed by myself and SIG App Delivery. We've also conducted interviews with end users. We are supportive of Flux going into incubation. We are now calling for the 2 week public comment period prior to the vote.



Thank you,

Michelle Noorali


KEDA Annual Review

Tom Kerkhove
 

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 Ambassador - AZUG Crew Member - Azure Architect at Codit

Blog - blog.tomkerkhove.be
Twitter - @TomKerkhove


Vote - renaming CNCF SIGs to TAGs

Liz Rice
 

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, especially where SIGs with the same name exist in both places. 

We also talked about holding votes through comments on GitHub. We are using this vote as an experiment of that mechanism, so please cast your vote on this issue (and not as response to this mailing list). https://github.com/cncf/toc/issues/549

Thanks,
Liz


Re: security & CNCF projects

Luke A Hinds
 

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]


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: 
image.png

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

Screenshot 2021-02-17 at 09.54.59.png

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

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.

 

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

 

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)





Re: security & CNCF projects

alexis richardson
 

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


On Wed, Feb 17, 2021 at 10:01 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: 
image.png

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

Screenshot 2021-02-17 at 09.54.59.png

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

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.

 

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

 

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)


Re: security & CNCF projects

Liz Rice
 


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: 
image.png

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

Screenshot 2021-02-17 at 09.54.59.png

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

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.

 

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

 

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)


Re: security & CNCF projects

alexis richardson
 

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

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.

 

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

 

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)


Re: security & CNCF projects

Chris Aniszczyk
 

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

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.

 

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

 

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)


Re: security & CNCF projects

alexis richardson
 

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

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.

 

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

 

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)


Re: security & CNCF projects

Chris Aniszczyk
 

+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

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.

 

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

 

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)

661 - 680 of 6343