Implementing the Auto-refreshing Official Kubernetes CVE Feed

Author: Pushkar Joglekar (VMware)

Accompanying the release of Kubernetes v1.25, we announced availability of an official CVE feed as an alpha feature. This blog will cover how we implemented this feature.

Implementation Details

An auto-refreshing 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.


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 .

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 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 . Any updates to this configuration file require the changes to go through the existing code review and approval process

Prow Configuration

The Prow job is defined in a kubernetes/infra configuration file The shell script to push and pull the data in Google Cloud Bucket is defined in a kubernetes/sig-security file 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 under the 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 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) and Tim Bannister (@sftim) for their stellar collaboration for many months from “ideation to implementation” of this feature.