Rename Product Security Team to Committee

7 files changed, 9 insertions, 9 deletions

diff --git a/committee-steering/governance/sig-governance.md b/committee-steering/governance/sig-governance.md
index bc646430..8cb5a174 100644
--- a/committee-steering/governance/sig-governance.md
+++ b/committee-steering/governance/sig-governance.md
@@ -74,7 +74,7 @@ Subproject Owner Role.  (this different from a SIG or Organization Member).
 ### Security Contact
 
 - Security Contact
-  - *MUST* be a contact point for the Product Security Team to reach out to for
+  - *MUST* be a contact point for the Product Security Committee to reach out to for
     triaging and handling of incoming issues
   - *MUST* accept the [Embargo Policy]
   - Defined in `SECURITY_CONTACTS` files, this is only relevant to the root file in
diff --git a/contributors/guide/bug-bounty.md b/contributors/guide/bug-bounty.md
index 634dff1d..3ca26006 100644
--- a/contributors/guide/bug-bounty.md
+++ b/contributors/guide/bug-bounty.md
@@ -64,7 +64,7 @@ vulnerability reports in these areas, they are not (currently) eligible to recei
 - Linux privilege escalations<br>
   _Please report these through security@kernel.org_
 - Attacks against containers from the host they are running on
-- Attacks relying on insecure configurations (subject to the [Product Security Team][]'s opinion),
+- Attacks relying on insecure configurations (subject to the [Product Security Committee][]'s opinion),
   such as clusters not utilizing mutual authentication or encryption between Kubernetes components.
 - Attacks relying on or against deprecated components (e.g. gitrepo volumes)
 - Vulnerabilities in etcd<br>
@@ -74,6 +74,6 @@ vulnerability reports in these areas, they are not (currently) eligible to recei
 - Vulnerabilities specific to a hosted Kubernetes setup<br>
   _Please report these through the associated provider_
 
-[Product Security Team]: https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#product-security-team-pst
+[Product Security Committee]: https://git.k8s.io/security/security-release-process.md#product-security-committee-psc
 [CoreOS's disclosure process]: https://coreos.com/security/disclosure/
 [CoreDNS's disclosure process]: https://github.com/coredns/coredns#security
diff --git a/sig-auth/archive/meeting-notes-2018.md b/sig-auth/archive/meeting-notes-2018.md
index b67e1ec0..4b40c044 100644
--- a/sig-auth/archive/meeting-notes-2018.md
+++ b/sig-auth/archive/meeting-notes-2018.md
@@ -582,7 +582,7 @@ q2Xz68mF3_LggEY/edit?ts=5a68cdbc
         *   Tim Allclair (@tallclair, Google) nominated as replacement
             *   Long-term contributor to k8s auth/security
             *   Helped drive pod security policy and audit features
-            *   Member of kubernetes product security team
+            *   Member of kubernetes product security committee
             *   Brings container/node security expertise
             *   Unanimous support from other leads (Jordan Liggitt, Red Hat; Eric Chiang, CoreOS)
         *   Feedback on the change welcome (either public or private)
diff --git a/sig-auth/charter.md b/sig-auth/charter.md
index 541c854e..7bd49bb5 100644
--- a/sig-auth/charter.md
+++ b/sig-auth/charter.md
@@ -49,7 +49,7 @@ Link to SIG section in [sigs.yaml]
   - Protection of volume data, container ephemeral data, and other non-API data (prefer: sig-storage
     and sig-node)
   - Container isolation (prefer: sig-node and sig-networking)
-  - Bug bounty (prefer: product security team)
+  - Bug bounty (prefer: product security committee)
   - Resource quota (prefer: sig-scheduling)
   - Resource availability / DOS protection (prefer: sig-apimachinery, sig-network, sig-node)
 
diff --git a/sig-service-catalog/charter.md b/sig-service-catalog/charter.md
index 6597ad82..2c7bab17 100644
--- a/sig-service-catalog/charter.md
+++ b/sig-service-catalog/charter.md
@@ -109,7 +109,7 @@ roles. We do not have the Tech Lead role, and have a honorary Emeritus Chair rol
     related events, such as KubeCon.
 
 - Security Contacts
-  - Are a contact point for the Product Security Team to reach out to for
+  - Are a contact point for the Product Security Committee to reach out to for
     triaging and handling of incoming issues.
   - Must be a maintainer.
   - Must accept and adhere to the Kubernetes [Embargo
diff --git a/wg-k8s-infra/charter.md b/wg-k8s-infra/charter.md
index c5d00064..1b42503c 100644
--- a/wg-k8s-infra/charter.md
+++ b/wg-k8s-infra/charter.md
@@ -98,7 +98,7 @@ time.
   must be  staffed / owned by at least 3 volunteers
 
   - We aspire to follow the same 1/3 maximal representation rules used by the
-    Steering Committee, Product Security Team, and other groups that have
+    Steering Committee, Product Security Committee, and other groups that have
     project-wide impact
   - However, while we are bootstrapping, we consider it acceptable for maximal
     representation concerns to be violated, since this will often be necessary
@@ -106,7 +106,7 @@ time.
   - Our plan would be to rectify this when choosing new members or rotating
     old members such that we eventually meet maximal representation criteria
 
-- We plan to follow the model set forth by the Product Security Team for
+- We plan to follow the model set forth by the Product Security Committee for
   suitable vetting new subproject owners
 
 - Subproject owners must provide additional contact details within the WG, and
diff --git a/wg-lts/charter.md b/wg-lts/charter.md
index 2c81e445..d2018723 100644
--- a/wg-lts/charter.md
+++ b/wg-lts/charter.md
@@ -79,7 +79,7 @@ There is yet another set of developers of Kubernetes internals who are
 those involved in meta-topics:
 * SIG Release: production of supported release artifacts
 * SIG Testing: how we can most effectively test Kubernetes
-* Product Security Team (PST): security vulnerability handling
+* Product Security Committee (PSC): security vulnerability handling
 * SIG Architecture: maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time.  Also defines conformance testing.
 * Steering Committee: scope includes deciding how and when official releases of Kubernetes artifacts are made and what they include