Minor updates for clarity and specificity

Author: PushkarJ

sig-security/sig-security-tooling/vulnerability-mgmt/README.md

@@ -1,54 +1,59 @@
 # Vulnerability Management
-Covers Kubernetes wide vulnerability management process, policies and workflows 
-that tackle known vulnerabilities in kubernetes artifacts
+
+Covers Kubernetes wide vulnerability management process, policies and workflows
+that tackle *known* vulnerabilities in Kubernetes artifacts that can be found
+via automation
 
 ## Goals
 
-1. Identify known vulnerabilities in Kubernetes artifacts by scanning them periodically
-2. Leverage the existing triage and resolution process (i.e. Github issues, PRs) 
+1. Identify known vulnerabilities in Kubernetes artifacts by scanning them
+   periodically
+2. Leverage the existing triage and resolution process (i.e. Github issues, PRs)
    to document and resolve any vulnerabilities that impact Kubernetes
-3. Create community driven awareness and documentation around known 
-   CVEs in Kubernetes related artifacts
-   
+3. Create community driven awareness and documentation around known CVEs in
+   Kubernetes related artifacts
+
+### Vulnerability Triage and Resolution Process
+
+Leverage community driven triage and impact assessment to resolve known
+vulnerabilities in Kubernetes artifacts. More details can be
+found [here](process-for-vulnerability-triage-and-resolution.md)
+
 ### Build Time Dependencies
 
-A tool agnostic periodic scanning of build time dependencies 
-(typically dependencies found in `go.mod` file) of Kubernetes. 
-More details can be found [here](build-time-dependencies.md)
+A tool agnostic periodic scanning of build time dependencies
+(typically dependencies found in `go.mod` file) of Kubernetes. More details can
+be found [here](build-time-dependencies.md)
+
+This track is a partnership between SIG
+Architecture's [Code Organization](https://github.com/kubernetes/community/tree/master/sig-architecture#code-organization)
+sub-project and SIG Security's Tooling sub-project
+
+### Container Images
 
-### Vulnerability Resolution Policy
+Automating triage and resolution of vulnerabilities as it relates to container
+images in Kubernetes Github Org. This effort is beginning to take form and is being tracked in
+[Issue #5920](https://github.com/kubernetes/community/issues/5920)
 
-Leveraging community driven triage and impact assessment to resolve known 
-vulnerabilities in Kubernetes artifacts. More details can be found [here](policy-for-vulnerability-resolution.md)
+This track is a partnership
+between [SIG Release](https://github.com/kubernetes/sig-release)
+and SIG Security's Tooling sub-project
 
-*NOTE*: Artifacts here refer to code, images and binaries
+**Note**: Artifacts here refer to code, images and binaries
 
 ## Non-Goals
 
 1. **Responsible disclosure of vulnerabilities**: This will continue to be the
    responsibility
-   of [Product Security Committee / Security Response Committee](../../../committee-product-security/README.md)
+   of [Security Response Committee](https://github.com/kubernetes/community/tree/master/committee-product-security/README.md)
 2. **Runtime dependencies**: Triaging of vulnerabilities found in components
-   that are runtime dependencies for an on-premises or _*
-   -as-a-service_
+   that are runtime dependencies for an on-premises or *-as-a-service*
    Kubernetes deployment. Examples include but are not limited to container
    runtimes, container registries, Node OS
 3. **Resolving license violations**: Allowed third party license policy can be
-   found here:
-   https://github.com/cncf/foundation/blob/master/allowed-third-party-license-policy.md#approved-licenses-for-allowlist
-
-## Upcoming work
-
-Although, more items will be added through community feedback and organic growth of
-security needs of the project, currently identified work includes automating 
-triage and resolution of vulnerabilities as it relates to container 
-images in Kubernetes repo
-
-### Container Images
-
-The effort is beginning to take form and is being
-tracked [Issue #1833](https://github.com/kubernetes/release/issues/1833)
+   found [here](https://github.com/cncf/foundation/blob/master/allowed-third-party-license-policy.md#approved-licenses-for-allowlist)
 
-*NOTE*: If you have a topic that you think is missing, please hop on over to our
+**Note**: If you have a topic that you think is missing, please hop on over to
+our
 [slack channel](https://kubernetes.slack.com/messages/sig-security-tooling)
-to discuss more
+to discuss more :-)

sig-security/sig-security-tooling/vulnerability-mgmt/policy-for-vulnerability-resolution.md

@@ -0,0 +1,48 @@
+# Process for Vulnerability Triage and Resolution
+
+Depending on the assessed impact of the vulnerability, appropriate resolution
+is triggered to apply the fix to Kubernetes or document the reason for not fixing
+
+## Assumptions
+
+- For undisclosed or non-public vulnerabilities, the 
+[responsible disclosure process](https://kubernetes.io/docs/reference/issues-security/security/) 
+  is followed
+- Reduce the window of opportunity for an attacker for exploiting known 
+  vulnerabilities by shortening the gap between `mean time to detect` and `mean 
+  time to fix`
+
+## Triage process
+
+- The vulnerabilities are triaged in private, by members of
+  `[email protected]`
+- Membership to this group is restricted due to the confidential nature of the
+  responsibilities
+- Once a vulnerability is found through automation, the group members get
+  notified via an email about it
+- One of the SIG Security Tooling member on rotation triggers assessment of the 
+  reported vulnerability as follows:
+
+  |No.   |  Category |  Definition | Partners | Lead | Assessment | Resolution |
+  |---|---|---|---|---|---|---|
+  | 1  | False positive  |  Kubernetes and vulnerable artifact is not impacted by this CVE | Optional | SIG Security Tooling | Open a Github issue and log the resolution as *False Positive* in issue description. Appropriate labels will be added to get attention from code owners when required  | Not Applicable
+  | 2  | True positive: No impact  | Artifact version used in Kubernetes is vulnerable, but Kubernetes is not using the vulnerable code  | Release Engineering, K8s Code Organization | SIG Security Tooling | Open a Github issue and log the resolution as *True Positive: No Impact* in the issue description with reasoning behind assessed impact | Existing Issue assignment, PR creation, review and approval process is followed to ensure relevant code owners are involved in some capacity. <br> The fix is applied to subsequent release of Kubernetes
+  | 3  | True positive: Negligible impact  | Artifact version used in Kubernetes is vulnerable, and Kubernetes is using the vulnerable code, but the vulnerability does not apply to Kubernetes | Release Engineering, K8s Code Organization, Security Response Committee | SIG Security Tooling |  SIG Security Tooling and Security Response Committee discuss the security implications of the vulnerability privately. If needed, the vulnerability is reclassified to Category 4. <br> <br>If the category is unchanged, open a Github issue classifying the vulnerability into category *True Positive: Negligible Impact*. It should also include reasoning behind assessed impact including but not limited to existence of a compensatory control* | Same as category 2
+  | 4  | True positive: With impact  | Artifact version used in Kubernetes is vulnerable, and Kubernetes is using the vulnerable code  | Release Engineering, K8s Code Organization, Security Response Committee | SIG Security Tooling | SIG Security Tooling and Security Response Committee discuss the security implications of the vulnerability privately. If needed, the vulnerability is reclassified to Category 3. <br><br> If category is unchanged, open a Github issue classifying the vulnerability into category *True Positive: With Impact*. It should also include the reasoning behind assessed impact, modified CVSS rating for Kubernetes if applicable and any workarounds that completely or partially mitigate the vulnerability | Issue is followed soon with PRs that cherry pick the fixes to master/main and all the supported [versions](https://kubernetes.io/releases/version-skew-policy/#supported-versions). Code Owners if not creating the PR should review, approve and merge the PR within a reasonable time duration depending on severity of impact. <br> The Release managers ensure that the vulnerability fix is then, shipped with the next patch release of Kubernetes.
+  | 5  | Embargoed vulnerability  | No CVE ID is assigned so scanners do not detect it  | Release Engineering | Security Response Committee | This category is only mentioned here for completeness | [Security Release Process](https://github.com/kubernetes/security/blob/master/security-release-process.md#disclosures)
+
+*<sub>Example of a compensating control: The vulnerability can be exploited only when unsafe user input can be injected but Kubernetes is doing input verification prior to accepting user input
+
+## Examples
+
+- [CVE-2020-26160](https://github.com/kubernetes/kubernetes/issues/100401)
+- [CVE-2021-20206](https://github.com/kubernetes/kubernetes/issues/101758)
+
+## Next Steps
+
+1. Create ignore lists for category 1, 2 and 3. Build a process to evaluate
+   ignore lists for category 2 and 3 periodically.
+2. Formalize or
+   modify [this](https://github.com/kubernetes/security/blob/master/security-release-process.md#severity-thresholds---how-we-do-vulnerability-scoring)
+   process from Product Security Committee / Security Response Committee, when
+   the modifying original CVSS score makes sense