<commit_before># Security Release Process

Kubernetes is a large growing community of volunteers, users, and vendors. The Kubernetes community has adopted this security disclosures and response policy to ensure we responsibly handle critical issues.

## Product Security Team (PST)

By their nature security vulnerabilities should be handled quickly and sometimes privately. The Product Security Team is responsible for running the communication, disclosure, and CVE/patch processes. They are not solely responsible for fixing issues and can loop in necessary engineers to test and verify the fixes.

The initial Product Security Team will consist of five volunteers who are all subscribed to the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list. These are the people who have been involved in the initial discussion and volunteered:

- <NAME> <brandon.philips> [4096R/154343260542DF34]
- <NAME> <<EMAIL>>
- <NAME> <<EMAIL>>
- <NAME> <<EMAIL>>

**Known issues**

- We haven't specified a way to cycle the Product Security Team; but we need this process deployed quickly as our current process isn't working. I (@philips) will put a deadline of March 1st 2017 to sort that.

## Disclosures

### Private Disclosure Processes

We ask that suspected vulnerabilities should be responsibility disclosed via our disclosure process. Please visit [http://kubernetes.io/security](http://kubernetes.io/security] to learn more.

### Public Disclosure Processes

If a security issue has been publicly disclosed please IMMEDIATELY email [<EMAIL>](mailto:<EMAIL>) to inform the Product Security Team about the vulnerability and start the patch, release, and communication process.

Next, ask the reporter if the issue can be handled via the private disclosure process. If the reporter denies it is best to proceed publicly and swiftly with the fix and release process. In extreme cases you can ask GitHub to delete the issue but this generally shouldn’t be necessary and is unlikely to make a public disclosure less damaging.

## Patch, Release, and Public Communication

- Request CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) (for embargoed issues) or [oss-security](http://www.openwall.com/lists/oss-security/) (for public issues)
- Set the issue priority based on rough criteria
  - P0 - **Critical impact**, flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact.
  - P1 - **Important impact**, flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.
  - P2 - **Moderate impact**, flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a Critical impact or Important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
  - P3 - **Low Impact**, other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.<commit_msg>security-release-process: add release managers<commit_after># Security Release Process

Kubernetes is a large growing community of volunteers, users, and vendors. The Kubernetes community has adopted this security disclosures and response policy to ensure we responsibly handle critical issues.

## Product Security Team (PST)

By their nature security vulnerabilities should be handled quickly and sometimes privately. The Product Security Team is responsible for running the communication, disclosure, and CVE/patch processes. They are not solely responsible for fixing issues and can loop in necessary engineers to test and verify the fixes.

The initial Product Security Team will consist of five volunteers who are all subscribed to the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list. These are the people who have been involved in the initial discussion and volunteered:

- <NAME> <brandon.philips> [4096R/154343260542DF34]
- <NAME> <<EMAIL>>
- <NAME> <<EMAIL>>
- <NAME> <<EMAIL>>

**Known issues**

- We haven't specified a way to cycle the Product Security Team; but we need this process deployed quickly as our current process isn't working. I (@philips) will put a deadline of March 1st 2017 to sort that.

## Release Manager Role

ALso included on the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list are all [Release Managers](https://github.com/kubernetes/community/wiki).

It is the responsbility of the Product Security Team to add new Release Managers and remove Release Managers as Kubernetes minor releases are deprecated.

## Disclosures

### Private Disclosure Processes

We ask that suspected vulnerabilities should be responsibility disclosed via our disclosure process. Please visit [http://kubernetes.io/security](http://kubernetes.io/security] to learn more.

### Public Disclosure Processes

If a security issue has been publicly disclosed please IMMEDIATELY email [<EMAIL>](mailto:<EMAIL>) to inform the Product Security Team about the vulnerability and start the patch, release, and communication process.

Next, ask the reporter if the issue can be handled via the private disclosure process. If the reporter denies it is best to proceed publicly and swiftly with the fix and release process. In extreme cases you can ask GitHub to delete the issue but this generally shouldn’t be necessary and is unlikely to make a public disclosure less damaging.

## Patch, Release, and Public Communication

- Request CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) (for embargoed issues) or [oss-security](http://www.openwall.com/lists/oss-security/) (for public issues)
- Set the issue priority based on rough criteria
  - P0 - **Critical impact**, flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact.
  - P1 - **Important impact**, flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.
  - P2 - **Moderate impact**, flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a Critical impact or Important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
  - P3 - **Low Impact**, other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.
{'fraction_non_alphanumeric': 0.05543683218101823, 'fraction_numerical': 0.006788183532369579, 'mean_word_length': 5.0594059405940595, 'pattern_counts': {'":': 0, '<': 29, '<?xml version=': 0, '>': 29, 'https://': 6, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2822946', 'n_tokens_mistral': 1868, 'n_tokens_neox': 1716, 'n_words': 1063}