Updates based on feedback for the triage process

Author: PushkarJ

sig-security/README.md

@@ -47,6 +47,13 @@ Security Documents and Documentation
   - [kubernetes/community/sig-security/sig-security-docs](https://github.com/kubernetes/community/blob/master/sig-security/sig-security-docs/OWNERS)
 - **Contact:**
   - Slack: [#sig-security-docs](https://kubernetes.slack.com/messages/sig-security-docs)
+### security-tooling
+Development and Enhancements of Security Tooling
+- **Owners:**
+  - [kubernetes/community/sig-security/sig-security-tooling](https://github.com/kubernetes/community/blob/master/sig-security/sig-security-tooling/OWNERS)
+- **Contact:**
+  - Slack: [#sig-security-tooling](https://kubernetes.slack.com/messages/sig-security-tooling)
+  - [Mailing List]([email protected])
 
 [subproject-definition]: https://github.com/kubernetes/community/blob/master/governance.md#subprojects
 <!-- BEGIN CUSTOM CONTENT -->

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

@@ -1,25 +1,25 @@
 # Vulnerability Management
-Covers kubernetes wide vulnerability management process, policies and workflows 
+Covers Kubernetes wide vulnerability management process, policies and workflows 
 that tackle known vulnerabilities in kubernetes artifacts
 
 ## Goals
 
-1. Identify known vulnerabilities in kubernetes artifacts by scanning them periodically
+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
+   to document and resolve any vulnerabilities that impact Kubernetes
 3. Create community driven awareness and documentation around known 
-   CVEs in kubernetes related artifacts
+   CVEs in Kubernetes related artifacts
 
 ### Build Time Dependencies
 
 A tool agnostic periodic scanning of build time dependencies 
-(typically dependencies found in `go.mod` file) of kubernetes. 
+(typically dependencies found in `go.mod` file) of Kubernetes. 
 More details can be found [here](build-time-dependencies.md)
 
 ### Vulnerability Resolution Policy
 
 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)
+vulnerabilities in Kubernetes artifacts. More details can be found [here](policy-for-vulnerability-resolution.md)
 
 *NOTE*: Artifacts here refer to code, images and binaries
 
@@ -31,7 +31,7 @@ vulnerabilities in kubernetes artifacts. More details can be found [here](policy
 2. **Runtime dependencies**: Triaging of vulnerabilities found in components
    that are runtime dependencies for an on-premises or _*
    -as-a-service_
-   kubernetes deployment. Examples include but are not limited to container
+   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:
@@ -42,7 +42,7 @@ vulnerabilities in kubernetes artifacts. More details can be found [here](policy
 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
+images in Kubernetes repo
 
 ### Container Images
 

sig-security/sig-security-tooling/vulnerability-mgmt/build-time-dependencies.md

@@ -1,7 +1,7 @@
 # Periodic scanning for vulnerabilities in build time dependencies
 
 Report vulnerabilities in build time dependencies
-of [kubernetes](https://github.com/kubernetes/kubernetes) repository
+of [Kubernetes](https://github.com/kubernetes/kubernetes) repository
 
 Tracker: [Issue #101528](https://github.com/kubernetes/kubernetes/issues/101528)
 
@@ -22,7 +22,7 @@ in place, [snyk](https://snyk.io/) was chosen for following reasons:
 
 ## Implementation with Snyk
 
-There are two ways to scan the kubernetes repo for vulnerabilities in
+There are two ways to scan the Kubernetes repo for vulnerabilities in
 dependencies at build time
 
 ### Running the scan locally
@@ -65,7 +65,7 @@ here: https://testgrid.k8s.io/sig-security-snyk-scan#ci-kubernetes-snyk-master
 
 #### Improvements to the raw scan results
 
-Raw scan results were useful, but needed some kubernetes specific work
+Raw scan results were useful, but needed some Kubernetes specific work
 
 ##### JSON output
 
@@ -89,7 +89,7 @@ cat licenses-cves.json | jq '.vulnerabilities | .[] | select (.type=="license" |
 
 Since these are really pointing to the code at HEAD in git tracking, we can
 ignore the vulnerabilities that are generated when snyk detects v0.0.0 as
-kubernetes version because of the way
+Kubernetes version because of the way
 [replace](https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive)
 directives are used.
 
@@ -101,6 +101,10 @@ cat licenses-cves.json | jq '.vulnerabilities | .[] | select ((.type=="license")
 
 ### Example of filtered JSON scan result
 
+__Note__: Results of the filtered scan are not printed as part of the CI job. 
+However, the following historical scan result is mentioned here for 
+reference purposes only:
+
 <!-- markdownlint-disable MD033 -->
 <details><summary>Click to view result</summary>
 <!-- markdownlint-enable MD033 -->

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

@@ -1,7 +1,7 @@
 # Policy for Vulnerability resolution
 
 Depending on the impact of the vulnerability identified, appropriate resolution
-is triggered to apply the fix to kubernetes or document the cause for not fixing
+is triggered to apply the fix to Kubernetes or document the cause for not fixing
 
 ## Assumptions
 
@@ -13,13 +13,25 @@ is triggered to apply the fix to kubernetes or document the cause for not fixing
 
 ## Triage process
 
-|No.   |  Category |  Definition |  Resolution |
-|---|---|---|---|
-| 1  | False positive  |  k/k and vulnerable package is not impacted by this CVE | Open a Github issue and log the resolution  |
-| 2  | True positive but no impact  | Package version used in k/k is vulnerable, but k/k is not using the vulnerable code  | Open a Github issue and a PR to bump the dependency to the version with a fix. This fix will go in subsequent release of k/k  |
-| 3  | True positive with negligible impact  | Package version used in k/k is vulnerable, but k/k is using the vulnerable code, but the vulnerability does not apply as per k/k threat model  |  Open a Github issue that describes why this will have negligible impact with relevant compensatory controls. Also, open a PR to bump the dependency to the version with a fix. This fix will go in subsequent release of k/k |
-| 4  | True positive with impact  | Package version used in k/k is vulnerable, and k/k is using the vulnerable code  |  Open a Github issue, that assesses impact, modifies CVSS rating for k8s, if needed and suggest compensatory controls. Also, open a PR to bump the dependency and backport the fix up to n-2 k/k version |
-| 5  | Embargoed vulnerability  | No CVE ID is assigned so scanners do not detect it  |  Product Security Committee / Security Response Committee triages and follows existing process for embargoed CVEs |
+- 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 group members then triages this vulnerability and classifies it
+  into one of the following categories:
+
+  |No.   |  Category |  Definition |  Resolution |
+     |---|---|---|---|
+  | 1  | False positive  |  k/k and vulnerable package is not impacted by this CVE | Open a Github issue and log the resolution  |
+  | 2  | True positive but no impact  | Package version used in k/k is vulnerable, but k/k is not using the vulnerable code  | Open a Github issue and a PR to bump the dependency to the version with a fix. This fix will go in subsequent release of k/k  |
+  | 3  | True positive with negligible impact  | Package version used in k/k is vulnerable, but k/k is using the vulnerable code, but the vulnerability does not apply as per k/k threat model  |  Open a Github issue that describes why this will have negligible impact with relevant compensatory controls. Also, open a PR to bump the dependency to the version with a fix. This fix will go in subsequent release of k/k |
+  | 4  | True positive with impact  | Package version used in k/k is vulnerable, and k/k is using the vulnerable code  |  Open a Github issue, that assesses impact, modifies CVSS rating for k8s, if needed and suggest compensatory controls. Also, open a PR to bump the dependency and backport the fix up to n-2 k/k version |
+  | 5  | Embargoed vulnerability  | No CVE ID is assigned so scanners do not detect it  |  Product Security Committee / Security Response Committee triages and follows existing process for embargoed CVEs |
+
+- Once the category is identified, the resolution is triggered manually by the
+  member triaging the vulnerability.
 
 ## Examples
 

sigs.yaml

@@ -2154,6 +2154,13 @@ sigs:
       slack: sig-security-docs
     owners:
     - https://raw.githubusercontent.com/kubernetes/community/master/sig-security/sig-security-docs/OWNERS
+  - name: security-tooling
+    description: Development and Enhancements of Security Tooling
+    contact:
+      slack: sig-security-tooling
+      mailing_list: [email protected]
+    owners:
+    - https://raw.githubusercontent.com/kubernetes/community/master/sig-security/sig-security-tooling/OWNERS
 - dir: sig-service-catalog
   name: Service Catalog
   mission_statement: >