+1 nb

On Wed, Sep 30, 2020 at 9:01 AM Amye Scavarda Perrin <ascavarda@...> wrote:

The Open Policy Agent project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)

The due diligence document can be found here: https://docs.google.com/document/d/19M5fTpe57rQIMNxawRl5wSWvJUapuzY-CkV4O5pvieU/edit
 
Brendan Burns has called for public comment: https://lists.cncf.io/g/cncf-toc/message/5281

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 Open Policy Agent project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)

The due diligence document can be found here: https://docs.google.com/document/d/19M5fTpe57rQIMNxawRl5wSWvJUapuzY-CkV4O5pvieU/edit
 
Brendan Burns has called for public comment: https://lists.cncf.io/g/cncf-toc/message/5281

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@...

+1, Binding

---

From: cncf-toc@... <cncf-toc@...> on behalf of Amye Scavarda Perrin via lists.cncf.io <ascavarda=linuxfoundation.org@...>
Sent: Wednesday, September 30, 2020 9:00 AM
To: CNCF TOC <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] [VOTE] Open Policy Agent from incubating to graduated

 

The Open Policy Agent project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)

The due diligence document can be found here: https://docs.google.com/document/d/19M5fTpe57rQIMNxawRl5wSWvJUapuzY-CkV4O5pvieU/edit
 
Brendan Burns has called for public comment: https://lists.cncf.io/g/cncf-toc/message/5281

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@...

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

Should we make it mandatory (which I think is a good idea), it would be useful to cross reference kubernetes who took the same approach for all leaders (I did the course as part of product security). That way we won't be nagging people to do training they have already completed.

On Fri, Nov 20, 2020 at 1:55 AM Arun Gupta <arun.gupta@...> wrote:

Chris,

I just completed the course and it's extremely valuable. As already mentioned and noted for next TOC agenda, this should be a must for all leadership positions in CNCF.

It took me > 1 hour to listen all audio transcripts and taking the quiz, but a great use of time. Here is the direct link: https://trainingportal.linuxfoundation.org/learn/course/inclusive-open-source-community-orientation-lfc102/

Thanks,

Arun

On Nov 13, 2020, at 7:30 AM, Chris Aniszczyk <caniszczyk@...> wrote:

As a follow up from previous discussions on D&I training, we at The Linux Foundation in partnership with NCWIT are launching a new course on building inclusive open source communities that CNCF helped fund: https://training.linuxfoundation.org/announcements/linux-foundation-and-ncwit-release-free-training-course-on-diversity-in-open-source/

We should consider making this as a graduation requirement or even as part of project acceptance, food for thought as we ramp up for kubecon + cloudnativecon next week!

--

Chris Aniszczyk (@cra)

Chris,

I just completed the course and it's extremely valuable. As already mentioned and noted for next TOC agenda, this should be a must for all leadership positions in CNCF.

It took me > 1 hour to listen all audio transcripts and taking the quiz, but a great use of time. Here is the direct link: https://trainingportal.linuxfoundation.org/learn/course/inclusive-open-source-community-orientation-lfc102/

Thanks,

Arun

On Nov 13, 2020, at 7:30 AM, Chris Aniszczyk <caniszczyk@...> wrote:

As a follow up from previous discussions on D&I training, we at The Linux Foundation in partnership with NCWIT are launching a new course on building inclusive open source communities that CNCF helped fund: https://training.linuxfoundation.org/announcements/linux-foundation-and-ncwit-release-free-training-course-on-diversity-in-open-source/

We should consider making this as a graduation requirement or even as part of project acceptance, food for thought as we ramp up for kubecon + cloudnativecon next week!

--

Chris Aniszczyk (@cra)

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

Same, I'd be interested.

~Dave

On Thu, Nov 19, 2020 at 6:26 PM 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

--

~Dave

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

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