Apply suggestions from code review

Co-authored-by: Mahé <[email protected]>
Co-authored-by: Batuhan Apaydın <[email protected]>
Co-authored-by: Cailyn <[email protected]>

Added link to existing options that are broken or incomplete

Add testing sections for v1.25

Co-authored-by: Rey Lejano <[email protected]>

Author: PushkarJ

keps/sig-security/3203-auto-refreshing-official-cve-feed/README.md

@@ -97,6 +97,10 @@ tags, and then generate with `hack/update-toc.sh`.
     - [Large JSON blob could lead to slower read/write and resource consumption](#large-json-blob-could-lead-to-slower-readwrite-and-resource-consumption)
 - [Design Details](#design-details)
   - [Test Plan](#test-plan)
+      - [Prerequisite testing updates](#prerequisite-testing-updates)
+      - [Unit tests](#unit-tests)
+      - [Integration tests](#integration-tests)
+      - [e2e tests](#e2e-tests)
   - [Graduation Criteria](#graduation-criteria)
   - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
   - [Version Skew Strategy](#version-skew-strategy)
@@ -167,26 +171,27 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
 ## Summary
 
 Currently it is not possible to filter for issues or PRs that are related to
-CVEs announced by kubernetes. This KEP addresses this concern by labelling this
+CVEs announced by kubernetes. This KEP addresses this concern by labeling these
 issues or PRs with the new label **official-cve-feed** using the automation. 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.
 
 ## Motivation
 
 With the 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 options are either broken or incomplete.
+Kubernetes have increased. Although most CVEs that directly, indirectly, or
+transitively impact Kubernetes are regularly fixed, there is no single place
+for the end users of Kubernetes to programmatically subscribe or pull the data
+of fixed CVEs. Current options are either
+[broken or incomplete](https://github.com/kubernetes/sig-security/issues/1).
 
 An auto-refreshing CVE feed will allow end users to programmatically fetch the
-list of CVEs and allow them to get the latest information from kubernetes
+list of CVEs and allow them to get the latest information from Kubernetes
 community.
 
 ### Goals
 
-Create a periodically auto-refreshing machine-readable list of official
+Create a periodically auto-refreshing, machine-readable list of official
 Kubernetes CVEs
 
 ### Non-Goals
@@ -203,7 +208,7 @@ Kubernetes CVEs
 #### Story 1
 
 As a K8s end user, I want a list of CVEs with relevant information that I can
-fetch programmatically, so I can understand when new CVEs are announced
+fetch programmatically, so I can track when new CVEs are announced.
 
 #### Story 2
 
@@ -219,7 +224,7 @@ feed manually
 
 ### Story 4
 
-As a K8s platform provider, I want to automatically to know if my kubernetes 
+As a K8s platform provider, I want to automatically know if my Kubernetes 
 clusters are vulnerable to any of the CVEs SRC have announced. I want to have a
 programmatically available API to parse this kind of data so I can easily
 provide it to users of my platform.
@@ -276,7 +281,7 @@ label that can only be applied by SRC and SIG Security Tooling Leads.
 Blobs will only be rewritten, if the generated blob is different from existing
 blob. As hash file would be created and stored alongside generated blob. This
 hash file will be check everytime before push to the hash of the generated file.
-If the hash file matches, writing to bucket will be skipped, If hash file is
+If the hash file matches writing to the bucket will be skipped, if hash file is
 different writing to bucket, will be triggered.
 
 ## Design Details
@@ -306,16 +311,10 @@ The steps to implement this design will involve a prow job that:
 
 ### Test Plan
 
+<!--
 <!--
 **Note:** *Not required until targeted at a release.*
-
-Consider the following in developing a test plan for this enhancement:
-- Will there be e2e and integration tests, in addition to unit tests?
-- How will it be tested in isolation vs with other components?
-
-No need to outline all of the test cases, just the general strategy. Anything
-that would count as tricky in the implementation, and anything particularly
-challenging to test, should be called out.
+The goal is to ensure that we don't accept enhancements with inadequate testing.
 
 All code is expected to have adequate tests (eventually with coverage
 expectations). Please adhere to the [Kubernetes testing guidelines][testing-guidelines]
@@ -324,6 +323,67 @@ when drafting this test plan.
 [testing-guidelines]: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md
 -->
 
+[ ] I/we understand the owners of the involved components may require updates to
+existing tests to make this code solid enough prior to committing the changes necessary
+to implement this enhancement.
+
+##### Prerequisite testing updates
+
+<!--
+Based on reviewers feedback describe what additional tests need to be added prior
+implementing this enhancement to ensure the enhancements have also solid foundations.
+-->
+
+##### Unit tests
+
+<!--
+In principle every added code should have complete unit test coverage, so providing
+the exact set of tests will not bring additional value.
+However, if complete unit test coverage is not possible, explain the reason of it
+together with explanation why this is acceptable.
+-->
+
+<!--
+Additionally, for Alpha try to enumerate the core package you will be touching
+to implement this enhancement and provide the current unit coverage for those
+in the form of:
+- <package>: <date> - <current test coverage>
+The data can be easily read from:
+https://testgrid.k8s.io/sig-testing-canaries#ci-kubernetes-coverage-unit
+
+This can inform certain test coverage improvements that we want to do before
+extending the production code to implement this enhancement.
+-->
+
+- `<package>`: `<date>` - `<test coverage>`
+
+##### Integration tests
+
+<!--
+This question should be filled when targeting a release.
+For Alpha, describe what tests will be added to ensure proper quality of the enhancement.
+
+For Beta and GA, add links to added tests together with links to k8s-triage for those tests:
+https://storage.googleapis.com/k8s-triage/index.html
+-->
+
+- <test>: <link to test coverage>
+
+##### e2e tests
+
+<!--
+This question should be filled when targeting a release.
+For Alpha, describe what tests will be added to ensure proper quality of the enhancement.
+
+For Beta and GA, add links to added tests together with links to k8s-triage for those tests:
+https://storage.googleapis.com/k8s-triage/index.html
+
+We expect no non-infra related flakes in the last month as a GA graduation criteria.
+-->
+
+- <test>: <link to test coverage>
+-->
+
 ### Graduation Criteria
 
 <!--