Create a periodically auto-refreshing list of fixed CVEs

[PushkarJ]

With growing number of eyes on Kubernetes, the number of CVEs related to Kubernetes have increased. Although most CVEs are regularly fixed that directly or indirectly or transitively impact Kubernetes, there is no single place to programmatically subscribe or pull the data of fixed CVEs, for the end users of Kubernetes.

Current State of the Art

All these options are broken or incomplete:

1. RSS feed with google groups is broken: Kubernetes Security and Disclosure Information website#29142
2. CVEDetails website seems to have incomplete data, with missing CVEs from 2021 and no mention of CVEs in base image or build time deps.
3. This page: https://kubernetes.io/docs/reference/issues-security/issues/ links to a Github issue filter for CVE related fixes but is a broad search term

Metadata

• Issue: Auto-refreshing Official CVE Feed enhancements#3203

Pre-requisites

• New label for officially announced CVEs by SRC test-infra#23428
• Search and Identify closed issues that have a CVE ID e.g. CVE-1001-12345 in the issue description or summary (This search filter is giving the most accurate data so far)
• Label those issues with official-cve-feed using https://docs.github.com/en/rest/reference/issues REST API
• Add official-cve-feed label to new vulnerability announcement issues committee-security-response#133

Implementation Details

https://github.com/kubernetes/enhancements/tree/master/keps/sig-security/3203-auto-refreshing-official-cve-feed

TestGrid for GCS Bucket is available here: https://testgrid.k8s.io/sig-security-cve-feed#auto-refreshing-official-cve-feed

Optional: Trigger k/website rebuild using netlify build-hook

Beta to GA Graduation Scope

• REQUEST: Migrate aquasecurity/vuln-list-k8s org#4873
• CVE-2023-5043 and CVE-2023-5044 missing from official list of vulnerabilities kubernetes#123964
• CVE feed doesn't include some vulnerabilities for in-project code website#45576
• CVE feed should update in near real time website#43968
• Publish CVE issue status in JSON CVE feed #98

Alpha to Beta Graduation Scope

Preview Give feedback

1. Support RSS feeds by generating data in Atom format #77
   sig/docs sig/security triage/accepted +3
   
2. CVE Feed: Sort Markdown Table from most recent to least recently announced CVE #73
   +0
3. CVE Feed: Add Prow job link as a metadata field #71
   kind/feature sig/docs sig/security triage/accepted +4
   
4. CVE Feed: Add lastUpdatedAt as a metadata field #72
   kind/feature sig/docs sig/security triage/accepted +4
   
5. CVE Feed: JSON feed should pass jsonfeed spec validator website#36808
   kind/bug priority/important-longterm sig/security triage/accepted +4
   
6. CVE Feed: Include a timestamp field for each CVE indicating when it was last updated #63
   kind/feature needs-triage sig/security triage/accepted +4
   

Feedback since beta that is resolved

Preview Give feedback

1. Include open issues in official CVE feed #97
   +0
2. CVE feed title doesn't mention project kubernetes#118437
   kind/bug sig/security triage/accepted +3
3. Update RSS feed title #92
   approved cncf-cla: yes lgtm size/XS +4
   
4. Remove the must be closed requirement in CVE feed #106
   approved cncf-cla: yes lgtm sig/security size/XS +5
5. Bug: Unbound variable in vulnerability scanning script #85
   help wanted kind/bug sig/k8s-infra sig/security sig/testing +5
   
6. Reduce curl calls to GH by eliminating duplicate CVEs test-infra#31076
   approved area/config area/jobs cncf-cla: yes lgtm ok-to-test sig/k8s-infra sig/testing size/XS +9
   

Feedback received but that requires more engagement and participation

• Support similar feeds for all CNCF projects

Related Discussions

• Kubernetes vulnerability dashboard committee-security-response#57
• Create Security Bulletins page kubernetes#89130
• Slack thread: https://kubernetes.slack.com/archives/C8P1DRTJA/p1632909102076400

cc @sftim @tallclair @kubernetes/sig-security-leads @raesene

/committee product-security
/sig security docs release

[coderanger]

Isn't this the problemspace https://osv.dev/ exists for? :)

[PushkarJ]

/assign @PushkarJ

[PushkarJ]

@coderanger https://osv.dev/ seems like a cool project, I did not know about this before :) I tried searching for kubernetes there and found one result. Maybe potential outcome of this exercise is a database (generated JSON doc) that can be consumed by https://osv.dev/ so users can use it to find out if their kubernetes version is impacted by any CVE or not.

[PushkarJ]

/transfer sig-security

[sftim]

generated JSON doc

We can almost certainly also consume that through Hugo and render a summary on https://k8s.io/

[PushkarJ]

@tabbysable @tallclair as SIG Security and SRC members, can you please confirm that you are in favor of this feature by commenting +1 to this issue. The progress on this issue is currently blocked, because of missing written consensus from SIG-Security and SRC as per this comment

[PushkarJ]

Just for everyone keeping track of this issue: We got a go ahead for starting work on this idea as KEP after merging the pre-requisite PR: kubernetes/test-infra#23428 . All the linked issues are coming from this filter.

Request @tabbysable and other SRC members to add / remove the label on anything we missed. The in-scope issues are the closed issues for which there is a CVE ID and is officially announced as a Kubernetes CVE by SRC in the past. Also, for any future such issues, please add this label so it will automatically get picked up by the feed!

[mtardy]

For the update, we merged:

• Fix CVE feed: comply with the JSON feed specifications and add the full JSON feed object in the script output to add last_updated root fields #76
• Update CVE feed layouts for new JSON feed format website#38579
• CVE feed: add RSS feed format website#39513

So now the CVE feed is JSON feed compliant, RSS compliant and has a top level last_updated field.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[PushkarJ]

Still working on this, until we are GA; currently at beta

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[PushkarJ]

Exciting updates coming soon

/remove-lifecycle stale

[andrewpollock]

Hi @PushkarJ could you provide an update on where things are at here?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[tabbysable]

/remove-lifecycle rotten

[tabbysable]

Discussed in today's Tooling meeting modifying the GA roadmap to replace "near-real-time update" milestone with "known and acceptable maximum delay", possibly including an ad-hoc refresh of the feed during CVE publication by SRC.

We are investigating.

[sftim]

If you (SRC) want to be able to trigger a website build, we (SIG Docs / K8s infra) can give you a webhook or something similar.

Either for manual use, automation, or a mix.

[sftim]

Also see kubernetes/website#43968 about options for near-realtime updates.

[mtardy]

If you (SRC) want to be able to trigger a website build, we (SIG Docs / K8s infra) can give you a webhook or something similar.

Either for manual use, automation, or a mix.

After discussion in the SIG security tooling meeting, we think the simplest solution would be to call a webhook to trigger the website build (like in k/website workflows) from the CVE feed generation script (this script) since it already knows when there's an update. The main difficulty would be to have a token at our disposal in the prow job that can call this webhook. Do you think it would be a good idea, and if so who can we contact to make it happen?

[sftim]

@mtardy SIG Docs! Try the Slack channel, but filing an issue against k/website would be best.

BTW, if there's any eventual consistency to account for with the object storage - let's account for it.

[mtardy]

@mtardy SIG Docs! Try the Slack channel, but filing an issue against k/website would be best.

BTW, if there's any eventual consistency to account for with the object storage - let's account for it.

Posted directly on the existing issue kubernetes/website#43968 (comment). I could try to join tomorrows SIG docs meeting to ask about this.

[mtardy]

Posting an update: it seems that many people from the community are doing effort on the CVEs for k8s, to my knowledge, today we have:

• The official CVE feed https://kubernetes.io/docs/reference/issues-security/official-cve-feed/ which is automated based on GitHub issues from k/k on CVEs.
• People from Aqua have been motivated to create an OSV feed that takes (amongst other things) the official CVE feed as an input https://github.com/kubernetes-sigs/cve-feed-osv/ which needs manual intervention
• We have govulncheck running in the CI but the result are not really exploited yet Scan kubernetes/kubernetes with govulncheck #95.

From the discussions, my understanding is that these projects could unite for a better CVE feed. The main requirement would be for the k8s SRC to have a way to generate the initial source information in OSV format. Indeed, the fact that the automated official CVE feed cannot provide much more information is because we don't have well formed input to consume, detailing for example which versions of k8s are affected (which is an information they provide to SIG release), or which binaries. From what I've been told, the SRC process today is fairly laborious and manual and using OSV could potentially make things simpler.

So I'd love to help to push the initiative forward and see how we can discuss with the SRC to consolidate the information they are already distributing in order to have a structured input for the CVE feeds!

cc @tabbysable @puerco @itaysk