---
layout: blog
title: Implementing the Auto-refreshing Official Kubernetes CVE Feed
date: 2022-09-12
slug: k8s-cve-feed-alpha
---

**Author**: Pushkar Joglekar (VMware)

Accompanying the release of Kubernetes v1.25, we announced
[availability of an official CVE feed](https://kubernetes.io/blog/2022/09/12/k8s-cve-feed-alpha/)
as an `alpha` feature. This blog will cover how we implemented this feature.

## Implementation Details

An [auto-refreshing CVE feed](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/)
allows users and implementers to programmatically fetch the list of CVEs announced by the
Kubernetes SRC (Security Response Committee).

To ensure freshness and minimal maintainer overhead, the feed updates automatically by
fetching the CVE related information from the CVE announcement GitHub Issues. Creating these issues is already part of the existing Security Response Committee (SRC) workflow.

### Pre-requisites

Until December 2021, it was not possible to filter for issues or PRs that are
tied to CVEs announced by Kubernetes SRC. We added a new
label, `official-cve-feed` to address that, and SIG-Security labelled relevant issues with it. The in-scope issues are `closed` issues for which there is a CVE
ID(s) and is officially announced as a Kubernetes security vulnerability by SRC.
You can now filter on all of these issues and find them
[here](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aclosed+label%3Aofficial-cve-feed+)
.

For future security vulnerabilities, we added the label to the SRC playbook
so that all the future in-scope issues will automatically have this label.

### Building on existing tooling

For the next step, we created a `prow` job in order to periodically query the
GitHub REST API and pull the relevant issues. The job runs
every two hours and pushes the CVE related information fetched from GitHub into a Google Cloud Bucket.

For every website build (at least twice a day), `Netlify` data templates make a
call to this Google Cloud Bucket to pull the CVE information and then parses into
fields that are [JSON Feed v1.1](https://www.jsonfeed.org/version/1.1/)
compliant. The JSON file is available for programmatic consumption by automated security tools.
For humans, the JSON also gets transformed into a Markdown table for easy viewing.

## Design Considerations

Building trust and ensuring that the feed is not stale were our main priorities
when designing this feature for success and widespread adoption.

### Integrity and Access Control Protections

Changes to any of the four artifacts used to build this feed could lead to feed
tampering, broken JSON, and inconsistent or stale data.

Let's look at how access is controlled for them one by one:

#### GitHub Issues for Publicly Announced CVEs

Adding the `official-cve-feed` label is restricted to limited number of trusted
community members. Access to add this label is defined
in [this configuration file](https://github.com/kubernetes/test-infra/blob/master/config/prow/plugins.yaml#L149-L159). Any updates to this configuration file require the changes to go through the
existing [code review and approval process](/docs/guide/pull-requests/)

#### Prow Configuration

The Prow job is defined in
a [`kubernetes/infra` configuration file](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-k8s-infra/trusted/sig-security-trusted.yaml#L94-L115)
The shell script to push and pull the data in Google Cloud Bucket is defined in a
[`kubernetes/sig-security` file](https://github.com/kubernetes/sig-security/tree/main/sig-security-tooling/cve-feed/hack)
under `sig-security-tooling` sub-project. Both of these files go through the
same code review and approval process mentioned earlier.

#### Google Cloud Bucket

Write access to Google Cloud bucket is configured to be restricted to a set of
trusted community members managed via an
invite-only [Google Groups Membership](https://github.com/kubernetes/k8s.io/blob/main/groups/sig-security/groups.yaml)
under the `kubernetes.io` domain.

#### Website Data templates

Website data templates that fetch and parse the stored JSON blob are managed
under `kubernetes/website` and have to follow the same code review and approval
process as mentioned earlier.

### Freshness Guarantees

The feed is updated everytime new CVE data is available by periodically
verifying if generated data is not the same as the stored data in the feed.

The `prow` job runs every two hours and compares the `sha256` checksum of the
existing contents of the bucket with checksum of the latest JSON file generated
through GitHub issues. If the there is new data available, the hashes do not
match (typically because of a newly announced CVE) and the updated JSON file is
pushed onto the bucket replacing the old file and old hash checksum.

If the hashes match, the `write to bucket` operation is skipped to reduce
redundant updates to the cloud bucket. This also sets us up for more frequent
runs of the prow job if needed in the future.

## What's Next?

If you would like to get involved in future iterations of this feed or other security relevant work, please consider
joining [Kubernetes SIG Security](https://github.com/kubernetes/community/tree/master/sig-security#contact)
by joining our bi-weekly meetings or hanging out with us on our Slack Channel.

_A special shout out and massive thanks to Neha Lohia
[(@nehalohia27)](https://github.com/nehalohia27) and Tim
Bannister [(@sftim)](https://github.com/sftim) for their stellar collaboration
for many months from "ideation to implementation" of this feature._