Updates based on PR feedback

- Revisited section placements
- Added clarity on use of labels under risks

Author: PushkarJ

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

@@ -171,23 +171,6 @@ An auto-refreshing CVE feed will allow end users to programmatically fetch the l
 
 Create a periodically auto-refreshing list of official Kubernetes CVEs
 
-
-## Proposal {#proposal}
-
-### 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](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+in%3Abody+%22CVSS%3A3.%22+label%3Acommittee%2Fsecurity-response+is%3Aclosed+) 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
-
-
-### Goals
-
-- Generate a JSON document using the results from the filtered label on `k/k` repo.
-- Create a Prow job to periodically generate this JSON document.
-- Update the JSON doc when needed (e.g. when a new CVE is announced) in `k/website`
-- Using Hugo, publish the list from this JSON document on official k8s website
-
 ### Non-Goals
 
 - Triage and vulnerability disclosure: This will continue to be done by SRC
@@ -210,6 +193,22 @@ As a K8s end user, I want a list of CVEs with relevant information that I can fe
 
 As a K8s maintainer, I want to create a process that auto-updates CVE feed, when SRC announces new CVEs such that I do not have to do extra work to maintain this feed manually
 
+## Proposal {#proposal}
+
+### 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](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+in%3Abody+%22CVSS%3A3.%22+label%3Acommittee%2Fsecurity-response+is%3Aclosed+) 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
+
+
+### Overview
+
+- Generate a JSON document using the results from the filtered label on `k/k` repo.
+- Create a Prow job to periodically generate this JSON document.
+- Update the JSON doc when needed (e.g. when a new CVE is announced) in `k/website`
+- Using Hugo, publish the list from this JSON document on official k8s website
+
 ### Risks and Mitigations
 
 #### JSON blob construction will fail
@@ -220,6 +219,15 @@ If this happens, we expect the job too fail. If blob construction fails, the fai
 
 In some extenuating circumstances, we may need to update the CVE feed within minutes of the official CVE announcement, instead of waiting for the merge based or periodical website rebuild. In those situations, manual updates to JSON blob using usual PR reviews and approval process can be implemented.
 
+### Misuse of Auto-Refresh feature
+
+Without proper filtering and control over who can label GitHub issues, the list of CVEs can become a list with poor signal to noise ratio making the list unusable. 
+
+For this purpose, the filtering is applied such that only issues that are marked as `closed`
+will be part of the list. Also, additionally, the `official-cve-feed` label is a 
+[restricted](https://github.com/kubernetes/test-infra/blob/master/config/prow/plugins.yaml#L140-L150)
+label that can only be applied by SRC and SIG Security Tooling Leads.
+
 ### Storage of CVE feed blob
 
 There are two options to store the CVE feed JSON blob: