[Feature Contributor Blog] K8s CVE Feed

- Supporting blog to the announcement of the CVE feed
- Covers implementation details, design considerations
- Links to original blog

Updates based on PR feedback by `jberkus`

content/en/blog/2022/2022-09-12-Implementing-the-Auto-Refreshing-Official-CVE-Feed/index.md

@@ -0,0 +1,121 @@
+---
+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._