Create a periodically auto-refreshing list of fixed CVEs

[PushkarJ]

trafficstars

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: https://github.com/kubernetes/website/issues/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: https://github.com/kubernetes/enhancements/issues/3203

Pre-requisites

• [x] https://github.com/kubernetes/test-infra/pull/23428
• [x] 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)
• [x] Label those issues with official-cve-feed using https://docs.github.com/en/rest/reference/issues REST API
• [x] https://github.com/kubernetes/committee-security-response/pull/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

• [x] https://github.com/kubernetes/org/issues/4873
• [x] https://github.com/kubernetes/kubernetes/issues/123964
• [x] https://github.com/kubernetes/website/issues/45576
• [ ] https://github.com/kubernetes/website/issues/43968
• [x] https://github.com/kubernetes/sig-security/issues/98

### Alpha to Beta Graduation Scope
- [x] https://github.com/kubernetes/sig-security/issues/77
- [x] https://github.com/kubernetes/sig-security/issues/73
- [x] https://github.com/kubernetes/sig-security/issues/71
- [x] https://github.com/kubernetes/sig-security/issues/72
- [x] https://github.com/kubernetes/website/issues/36808
- [x] https://github.com/kubernetes/sig-security/issues/63

### Feedback since `beta` that is resolved
- [ ] https://github.com/kubernetes/sig-security/issues/97
- [ ] https://github.com/kubernetes/kubernetes/issues/118437
- [ ] https://github.com/kubernetes/sig-security/pull/92
- [ ] https://github.com/kubernetes/sig-security/pull/106
- [ ] https://github.com/kubernetes/sig-security/issues/85
- [ ] https://github.com/kubernetes/test-infra/pull/31076

Feedback received but that requires more engagement and participation

• [ ] Support similar feeds for all CNCF projects

Related Discussions

• https://github.com/kubernetes/security/issues/57
• https://github.com/kubernetes/kubernetes/issues/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: https://github.com/kubernetes/test-infra/pull/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!

[PushkarJ]

/assign @nehaLohia27

(She is going to get the ball rolling on the KEP)

[tabbysable]

PR is open to update SRC documentation: https://github.com/kubernetes/committee-security-response/pull/133

[sbs2001]

FWIW I've been converting the security announcements to yaml format as part of ismyk8ssecure. See advisories in particular. It contains the CVE and a list of versions of the particular kubernetes component which is vulnerable to it.

We should be able to add the first patched version, fairly easily.

[sftim]

Would anyone like help on this? I can try to provide advice on next steps.

[sbs2001]

@sftim I would be happy to help. Let me know the next steps.

[sftim]

Here's the key / blocking challenge:

Create a Prow job to periodically generate this JSON document

if someone's picking this up who knows Prow: great! Feel free to get started on work to generate that document and publish it. if you're new to Prow but would like help, SIG Testing are the folks who can ask. It's also OK to reply here to ask for advice.

(personally, I don't have much experience with Prow)

[PushkarJ]

@sbs2001 As Tim suggested the prow job work is the main piece that needs help. @nehaLohia27 has a lot of context on this issue (and a little on prow) so please connect with her as well if you start exploring this.

[oliverchang]

Hi there! https://osv.dev maintainer here.

We'd love for Kubernetes to be able to publish its feed of vulnerabilities in our machine readable OSV format. We developed this format in collaboration with many in the open source community, including GitHub. This has so far been adopted by many other open source vulnerability feeds.

Our goal with this format was to make it:

• Easy for humans to produce and read
• Machine readable with unambiguous version ranges and package specification, to allow for easy vulnerability scanning/matching.
• Enable unified tooling for consumers of open source to aggregate vulnerabilities across all open source ecosystesm, and to make it easier for vulnerabilities to be shared.

I'd be very happy to work with the folks involved here to work out the details together. All that's really involved is to make this feed available in the OSV format as JSON files in either a git repo or cloud bucket.

[sftim]

OSV format feed

Sounds reasonable. Maybe some other project already has tooling we can borrow ideas from. Also, if we want to publish the equivalent data in another format as well one day, that should be feasible (we don't have to settle on OSV only).

[PushkarJ]

Agree with the suggestion on OSV. I have added a to-do to support OSV format. Once the data munging is ready, will let everyone know so we can start publishing the CVEs in OSV, JSON and maybe other formats too.

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[PushkarJ]

/remove-lifecycle stale

(KEP is in progress)

[PushkarJ]

Alpha (in-scope of v1.25) implementation of Auto-refreshing CVE feed is now complete. In other words the feed should be available for consumption once v1.25 is GA.

Feature blog describing this feature is in progress.

[oliverchang]

Awesome to hear! Is there any way we can help with getting OSV support for this?

Are there any details on how the CVE JSON feeds are generated?

[PushkarJ]

OSV support is planned for beta stage.

For more details on current implementation please check this: https://github.com/kubernetes/enhancements/issues/3203

[PushkarJ]

:sparkles: Kubernetes v1.25 is live :sparkles:

What that means is that the official CVE feed (feature state: alpha) built as part of KEP-3203 is live too. You can find it here:

• Markdown: https://kubernetes.io/docs/reference/issues-security/official-cve-feed
• JSON: https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json

Upcoming blog posts to be published on Sept 12 will cover more details

[angusm43ge]

This is a great idea. One observation about the current alpha version -I picked a few CVEs at random from the list, and when I got into the detail, saw that they were found and resolved in older versions (for ex. 1.5.1). Support for OSV, which I see is planned for the beta, should sort that out, as the "affected versions" etc items in the schema capture that : https://ossf.github.io/osv-schema/#affectedversions-field

[kevincox]

The CVE feed is not valid: https://validator.jsonfeed.org/?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Freference%2Fissues-security%2Fofficial-cve-feed%2Findex.json

Is there any tracking work to ensure that the feed is valid? The most notable issue is that one of the entries (https://github.com/kubernetes/kubernetes/issues/91507) has a null ID but all of the entries are also invalid because they contain no content. Maybe a simple <a> tag linking to the GitHub issue should be added as content?

[PushkarJ]

Thanks @angusm43ge that is good point. It is going to take some work to have meaningful automation to detect affected versions, but we will mark it as a future feature request along with osv like you pointed out.

[PushkarJ]

@kevincox thanks for making me aware that a validator for JSON feed spec exists - I was not aware of this.

We will consider in future, making the feed support the spec fully or move away from the spec with our own modifications that serve the purpose for this feed.

[kevincox]

Thanks. I would highly recommend updating to match the spec because it opens a wide set of preexisting tooling for things like automatically notifying people when a new item is posted. But of course if for some reason you don't want to it is definitely better to completely move away and stop pretending than the current "inspired by" version.

[sftim]

The CVE feed is not valid: https://validator.jsonfeed.org/?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Freference%2Fissues-security%2Fofficial-cve-feed%2Findex.json

Is there any tracking work to ensure that the feed is valid? The most notable issue is that one of the entries (kubernetes/kubernetes#91507) has a null ID but all of the entries are also invalid because they contain no content. Maybe a simple <a> tag linking to the GitHub issue should be added as content?

@kevincox would you be willing to file this as an issue against k/website specifically?

[sftim]

We also need work to make sure that the data that the website consumes are valid too.