Create RFP.md
The initial draft of the RFP for the Kubernetes Third-Party Security Audit.
This commit is contained in:
Aaron Small
GitHub
parent
3005cd4324
commit
4da4a63021
|
|
@ -0,0 +1,95 @@
|
|||
# Request for Proposal
|
||||
|
||||
## Kubernetes Third Party Security Audit
|
||||
|
||||
The Kubernetes Third-Party Audit Working Group (working group, henceforth) is soliciting proposals from select Information Security vendors for a comprehensive security audit of the Kubernetes Project.
|
||||
|
||||
### Eligible Vendors
|
||||
|
||||
Only the following vendors will be permitted to submit proposals:
|
||||
- NCC Group
|
||||
- Trail of Bits
|
||||
- Cure53
|
||||
- Bishop Fox
|
||||
- Insomnia
|
||||
- Atredis Partners
|
||||
|
||||
|
||||
### RPF Process
|
||||
|
||||
This RFP will be open between 2018/10/22 and 2019/11/18.
|
||||
|
||||
The working group will answer questions for the first two weeks of this period.
|
||||
|
||||
Questions can be submitted [here](https://docs.google.com/forms/d/e/1FAIpQLSd5rXSDYQ0KMjzSEGxv0pkGxInkdW1NEQHvUJpxgX3y0o9IEw/viewform?usp=sf_link). All questions will be answered publicly in this document.
|
||||
|
||||
Proposals must include CVs, resumes, and/or example reports from staff that will be working on the project.
|
||||
|
||||
- 2018/10/22: RFP Open, Question period open
|
||||
- 2018/11/05: Question period closes
|
||||
- 2018/11/19: RFP Closes
|
||||
- 2018/11/26: The working group will announce vendor selection
|
||||
|
||||
|
||||
|
||||
## Audit Scope
|
||||
|
||||
The scope of the audit is the 3 most recent releases (1.10, 1.11, 1.12) of the core [Kubernetes project](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
- Findings within the [bug bounty program](https://github.com/kubernetes/community/blob/master/contributors/guide/bug-bounty.md) scope are in scope.
|
||||
|
||||
> We want the focus of the audit to be on bugs on Kubernetes. While Kubernetes relies upon a container runtimes such as Docker and CRI-O, we aren't looking for (for example) container escapes that rely upon bugs in the container runtime (unless, for example, the escape is made possible by a defect in the way that Kubernetes sets up the container).
|
||||
|
||||
### Focus Areas
|
||||
|
||||
The Kubernetes Third-Party Audit Working Group is specifically interested in the following areas. Proposals should indicate their level of expertise in these fields as it relates to Kubernetes.
|
||||
|
||||
- Networking
|
||||
- Cryptography
|
||||
- Authentication & Authorization (including Role Based Access Controls)
|
||||
- Secrets management
|
||||
- Multi-tenancy isolation along Kubernetes namespace boundaries
|
||||
|
||||
### Out of Scope
|
||||
|
||||
Findings specifically excluded from the [bug bounty program](https://github.com/kubernetes/community/blob/master/contributors/guide/bug-bounty.md) scope are out of scope.
|
||||
|
||||
## Methodology
|
||||
|
||||
We are allowing 8 weeks for the audit. Artifacts must be supplied to the working group by January 21, 2019.
|
||||
|
||||
The audit should not be treated as a penetration test, or red team exercise. The should be comprehensive and not end with the first successful exploit or critical vulnerability.
|
||||
|
||||
The vendor should preform both source code analysis as well as live evaluation of Kubernetes.
|
||||
|
||||
After vendor selection the working group will establish a 60 minute kick-off meeting to answer any initial questions and explain Kubernetes architecture.
|
||||
|
||||
The working group will be available weekly to meet with the selected vendor. And provide subject matter experts on requested components.
|
||||
|
||||
The vendor must report urgent security issues immediately to both the working group and security@kubernetes.io.
|
||||
|
||||
## Confidentiality and Embargo
|
||||
|
||||
All information gathered and artifacts created as a part of the audit must not be shared outside the vendor or the working group without the explicit consent of the working group.
|
||||
|
||||
## Artifacts
|
||||
|
||||
The audit should result in the following artifacts, which will be made public after any sensitive security issues are mitigated.
|
||||
|
||||
- Findings report, including and executive summary
|
||||
- Formal threat model
|
||||
- Any proof of concept exploits that we can use to investigate and fix defects
|
||||
|
||||
- Retrospective white paper(s) on important security considerations in Kubernetes
|
||||
|
||||
*This artifact can be provided up to 3 weeks after deadline for the others.*
|
||||
|
||||
- E.g. [NCC Group: Understanding hardening linux containers](https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf)
|
||||
- E.g. [NCC Group: Abusing Privileged and Unprivileged Linux
|
||||
Containers](https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf)
|
||||
|
||||
## Q & A
|
||||
|
||||
This section intentionally left empty until the question period opens.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue