Date
1 - 5 of 5
Vulnerability scanning for CNCF projects
Liz Rice
Hi TOC and SIG Security folks
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. .
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.
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 ITtweet: @shubhrakar
On Wed, Nov 18, 2020 at 8:41 AM Liz Rice <liz@...> wrote:
Hi TOC and SIG Security folksOn 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
Justin Cormack
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 KarCTO and GM of Products and ITtweet: @shubhrakarOn Wed, Nov 18, 2020 at 8:41 AM Liz Rice <liz@...> wrote:Hi TOC and SIG Security folksOn 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.JustinOn 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 KarCTO and GM of Products and ITtweet: @shubhrakarOn Wed, Nov 18, 2020 at 8:41 AM Liz Rice <liz@...> wrote:Hi TOC and SIG Security folksOn 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
Luke A Hinds <lhinds@...>
Add me as well.
I am one of the maintainers on bandit (python ast based security linter) which hits around 25k downloads a day, so I have a fair amount of experience in what works / does not work well with security linters. As others have mentioned, false positives always happen so you need a developer UX that does not make the linter into something that gets yelled at all the time.
Same, I'd be interested.~DaveOn 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.JustinOn 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 KarCTO and GM of Products and ITtweet: @shubhrakarOn Wed, Nov 18, 2020 at 8:41 AM Liz Rice <liz@...> wrote:Hi TOC and SIG Security folksOn 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