|
Re: [cncf-sig-security] Vulnerability scanning for CNCF projects
Gareth Rushgrove
On Wed, 18 Nov 2020 at 16:54, Emily Fox <themoxiefoxatwork@gmail.com> wrote:
I'd be happy to join and help here. HUGE DISCLAIMER. I work at Snyk, which is the service powering the scans. I'm also a maintainer of Conftest as part of the Open Policy Agent project and know a bunch of folks on here. I'm not trying to sell you anything, other nice vendors exist, etc. I just happen to have opinions and experience here. The current numbers for a lot of our projects look really quite badThis is nearly always the case when projects or company first look at vulnerabilities. It's indicative of the problem domain more so than projects doing the wrong thing. Fixing starts with visibility. reviewing such a massive amount of data for project owners might take way too much timeThe main thing to do is break the problem down. Luckily there are a few things you can do here. * As you note, starting with non-test dependencies is a good idea * Then start with the most severe and those which can be fixed, and repeat. Standards like CVSS exist, as well as more involved vendor-specific mechanisms. CVSS is mainly simple to read on the surface (Low 0.1 - 3.9, Medium 4.0 - 6.9, High 7.0 - 8.9, Critical 9.0 - 10.0) * Each time you clear a new threshold, put in checks in CI to help enforce things in the future For instance: * Start with Critical (CVSS 9+), non-test issues that have a fix available * Add a CI check to break the build for CVSS 9+, non-test, fixable issues * Do the same for 8+ non-test * Do the same for 9+ test ... etc. In this way what seems an impossibly large bit of work gets broken down and you get value quickly. You can absolutely do this at your own pace. I wouldn't advocate for CNCF to set deadlines, though guidelines and reporting for graduated projects might be useful. Separately, you likely want to have some level of triage for vulnerabilities that don't have fixes available yet. The above approach is somewhat mechanical, triage needs more context and security experience. I'd at least recommend having maintainers triage Critical severity issues in dependencies. Assuming that's rare, you can extend this as far as you like and have time to do (to High, or Medium, or a specific CVSS threshold). false positives from things like dependencies only used in testI wouldn't think of test vulnerabilities as false positives, just potential a different type of vulnerability. As one example, compromised test vulnerabilities have the potential to steal build credentials and suddenly someone is shipping a compromised version of software to end users using your release toolchain. I'm sure the above is obvious to some, but I thought it was worth laying out. It should also be pretty tool agnostic. As mentioned, happy to join conversations if folks are discussing. Gareth ~Emily Fox -- Gareth Rushgrove @garethr garethr.dev devopsweekly.com
|
|||||||||||||
|
|
|||||||||||||
|
Re: [cncf-sig-security] Vulnerability scanning for CNCF projects
Eli Nesterov <eli.nesterov@...>
Liz, this is great! Having vulnerability scanning is a good thing, but looking into the results might be too many false positives (as you pointed out) and noise. In my experience, reviewing such a massive amount of data for project owners might take way too much time. I actually like the idea of the security scorecard https://github.com/ossf/scorecard which covers lots of security best practices and provides lots of actionable feedback along with advice on how to improve using different tools. --eli
On Wed, Nov 18, 2020 at 8:41 AM Liz Rice <liz@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Re: FYI: Cloud Native Security Whitepaper 2020
Matt Jarvis
This is awesome ! Well done folks ...
On Wed, 18 Nov 2020 at 17:41, Justin Cormack via lists.cncf.io <justin.cormack=docker.com@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
[RESULT] Buildpacks moves to incubation
Amye Scavarda Perrin
Buildpacks has been approved to move to incubation. (https://lists.cncf.io/g/cncf-toc/message/5385) +1 Binding 9/11 Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/5392 Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/5393 Xiang Li: https://lists.cncf.io/g/cncf-toc/message/5396 Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/5399 Dave Zolotusky: https://lists.cncf.io/g/cncf-toc/message/5406 Saad Ali: https://lists.cncf.io/g/cncf-toc/message/5439 Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/5441 Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/5443 Liz Rice: https://lists.cncf.io/g/cncf-toc/message/5499 +1 NB Josh Berkus: https://lists.cncf.io/g/cncf-toc/message/5386 Joe Beda: https://lists.cncf.io/g/cncf-toc/message/5387 Gadi Naor: https://lists.cncf.io/g/cncf-toc/message/5390 Stephen Augustus: https://lists.cncf.io/g/cncf-toc/message/5391 Chris Short: https://lists.cncf.io/g/cncf-toc/message/5394 Adam FitzGerald: https://lists.cncf.io/g/cncf-toc/message/5395 Kevin Wang: https://lists.cncf.io/g/cncf-toc/message/5403 Andrés Vega: https://lists.cncf.io/g/cncf-toc/message/5404 Romaric Philogène: https://lists.cncf.io/g/cncf-toc/message/5444 Sandeep Lahane: https://lists.cncf.io/g/cncf-toc/message/5446 Amye Scavarda Perrin | Program Manager | amye@...
|
|||||||||||||
|
|
|||||||||||||
|
Re: FYI: Cloud Native Security Whitepaper 2020
Justin Cormack
Thanks to everyone who worked so hard on this. Congratulations on shipping it, it will be very helpful. Justin
On Wed, Nov 18, 2020 at 5:38 PM Chris Aniszczyk <caniszczyk@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
FYI: Cloud Native Security Whitepaper 2020
The CNCF Security SIG did an excellent job putting together a white paper around cloud native security: https://github.com/cncf/sig-security/blob/master/security-whitepaper/cloud-native-security-whitepaper.md It's great! Please check it out and feel free to provide their community feedback on it! Chris Aniszczyk (@cra)
|
|||||||||||||
|
|
|||||||||||||
|
Re: FYI: New Training Course on Diversity in Open Source
Let's put it as a discussion item for the next meeting and consider rolling it out in 2021
On Wed, Nov 18, 2020 at 9:47 AM Liz Rice <liz@...> wrote:
--
Chris Aniszczyk (@cra)
|
|||||||||||||
|
|
|||||||||||||
|
Re: [cncf-sig-security] Vulnerability scanning for CNCF projects
" Should we have something in place for requiring projects to have a process to fix vulnerability issues (at least the serious ones)?" We have a graduation requirement around CII badging which requires a security disclosure process so it's there but not codified formally, we could do that, I think the important thing is that projects also publish advisories in a standard way (like via the github security API) We should treat the LF tool suite as another option for projects to take advantage of, already many projects are using Snyk, FOSSA, Whitesource etc that is listed here: https://github.com/cncf/servicedesk#tools You can kind of get an SBOM (depending you define sbom ;p) for some of our projects already: https://app.fossa.com/attribution/c189c5b9-fe2c-45f2-ba40-c34c36bab868 I think offering projects more choice is always better as the landscape changes often in tooling.
On Wed, Nov 18, 2020 at 10:54 AM Emily Fox <themoxiefoxatwork@...> wrote:
--
Chris Aniszczyk (@cra)
|
|||||||||||||
|
|
|||||||||||||
|
Re: [cncf-sig-security] Vulnerability scanning for CNCF projects
Liz, Love this. As part of the assessments SIG-Security performs, we've begun highlighting the importance of secure development practices. The last few assessments we've begun pushing more for this, as well as responsible disclosure instructions and general security mindedness for project sustainment. This fits in alignment with those efforts. We currently have the assessment process undergoing some updates (held currently for kubecon) and this make it a great time to potentially include this. I personally would like to see license dependencies and dependency trees to help push forward in the area of SBOM. I think we should be clear however in what our thresholds and terms are in this area, offhand i can think of the following potentials: * Listing of vulns in deliverable artifacts * Listing licensing dependencies * SBOM * vulnerability threshold and prioritizing resolution in prior to artifact delivery * vulnerability threshold and prioritizing resolution post artifact delivery Definitely worth a conversation and follow-ups. Do you have anything in mind that are must haves off the above or anything I missed or misunderstood? ~Emily Fox
On Wed, Nov 18, 2020 at 11:41 AM Liz Rice <liz@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Vulnerability scanning for CNCF projects
Liz Rice
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
|
|||||||||||||
|
|
|||||||||||||
|
Re: FYI: New Training Course on Diversity in Open Source
Liz Rice
Thanks Chris. We could also require it for TOC members & SIG chairs too
On Wed, Nov 18, 2020 at 2:40 PM Chris Aniszczyk <caniszczyk@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Re: FYI: New Training Course on Diversity in Open Source
Thanks! Liz I have added this as a requirement per the project proposal process: https://github.com/cncf/toc/pull/570 We can discuss at the next TOC meeting to vote/finalize the changes, but I think the best place to put the requirement is at the project proposal phase where we can easily check against the initial list of maintainers. In the future, we can try to do something fancy like an automated audit report based on what's in maintainers.cncf.io and if they have taken the course.
On Wed, Nov 18, 2020 at 8:30 AM Bartłomiej Płotka <bwplotka@...> wrote:
--
Chris Aniszczyk (@cra)
|
|||||||||||||
|
|
|||||||||||||
|
Re: FYI: New Training Course on Diversity in Open Source
Hi, Just completed it (takes ~20 min) and definitely can recommend it to all who maintain projects on open source! 🤗 It's actionable and insightful, +1 to make it mandatory. BTW, direct training link: https://training.linuxfoundation.org/training/inclusive-open-source-community-orientation-lfc102/ (it's free) Kind Regards, Bartek Płotka (@bwplotka)
On Wed, 18 Nov 2020 at 10:07, Liz Rice <liz@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Re: [VOTE] Buildpacks to move to incubation
Archy k
+1 NB
On Wed, Oct 7, 2020 at 5:21 PM Amye Scavarda Perrin <ascavarda@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Re: [VOTE] Buildpacks to move to incubation
Romaric Philogène
+1
--
|
|||||||||||||
|
|
|||||||||||||
|
Re: [VOTE] Buildpacks to move to incubation
Liz Rice
+1 binding
On Tue, 3 Nov 2020 at 17:08, sandeep lahane <sandeep@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Re: FYI: New Training Course on Diversity in Open Source
Liz Rice
I’d like to see all project maintainers taking this at all maturity levels Probably getting carried away here, but it would be nice if we could automate this, a bit like CLA bots: automatically flagging up anyone who’s listed in a Maintainers file if they haven’t taken the course
On Fri, 13 Nov 2020 at 15:31, Chris Aniszczyk <caniszczyk@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Re: [VOTE] etcd for graduation
Robert Wilkins III
+1 NB
|
|||||||||||||
|
|
|||||||||||||
|
Re: [VOTE] etcd for graduation
Liz Rice
+1 binding
On Mon, Nov 16, 2020 at 4:36 PM Justin Cormack via lists.cncf.io <justin.cormack=docker.com@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Re: [VOTE] etcd for graduation
Justin Cormack
+1 (binding) Justin
On Fri, Nov 13, 2020 at 5:51 PM Amye Scavarda Perrin <ascavarda@...> wrote:
|
|||||||||||||
|
|
