New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a requirement regarding security audits #145
Conversation
A part of achieving a CII Badge involves in setting up a security disclosure process, which is a great practice for all open source projects to have. However, not all security disclosure processes are tested so the TOC is considering the requirement moving forward to have CNCF projects go through a third party security audit which helps test the security disclosure process.
A couple of questions
|
@yurishkuro CNCF would cover the costs of any audit, we have done so already for a few projects who were part of a pilot program |
@yurishkuro regarding the value, it's hard to say, it definitely ensures that the security disclosure process works at one point in time. It can also help a project when adopted by large enterprises who have selection criteria that involve having an audit, for example, this was the case with Envoy recently: https://envoyproxy.slack.com/archives/C78M4KW76/p1534181685000447 |
@yurishkuro
I'll also mention that good security audits cover much more than the
existing code base. Auditing the security architecture, design, tradeoffs,
etc. is also of great value across even completely different
implementations of the same project.
…On Mon, Aug 20, 2018 at 4:01 PM Chris Aniszczyk ***@***.***> wrote:
@yurishkuro <https://github.com/yurishkuro> regarding the value, it's
hard to say, it definitely ensures that the security disclosure process
works at one point in time. It can also help a project when adopted by
large enterprises who have selection criteria that involve having an audit,
for example, this was the case with Envoy recently:
https://envoyproxy.slack.com/archives/C78M4KW76/p1534181685000447
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#145 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA0XD9JCo_0FWaTXViKVP0Ow6kr7UXORks5uSxW3gaJpZM4WEmnX>
.
|
In addition to the audit and existing CII standards, we probably should look at security and quality more holistically. The CII criteria are a good start, but don't cover everything: For instance, I don't think code review is even recommended. Other possible areas include test coverage, design documentation, security team and response procedures, dependency analysis automation, and observability (at least for server components). Kubernetes falls short in a number of those areas, so we are working on defining a higher bar. |
@bgrant0607 - thanks for referring to the CII Best Practices passing badge criteria (which Kubernetes already meets)! However, https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md is only the criteria for the passing badge. We have two higher level badges, silver and gold, which might in part be what you're looking for. The silver and gold criteria are also posted on GitHub. Each level requires that you meet the previous one (e.g., to get silver, you first have to get a passing badge). Please take a look! If you have questions, feel free to ask, I'd love to help. |
Thanks @david-a-wheeler! Will take a look. |
This is a very reasonable minimum bar. |
critical vulnerabilities need to be addressed before graduation
+1 from me on this as an independent change, although I would still like to discuss the periodic aspect separately if folks are more comfortable doing it that way. |
This seems reasonable to me as a place to start. |
No objections, will merge it in. We will deal with the periodic aspect later as that's more complicated given the recurring budget requirements + balancing security audit contractor availability. Thanks all! |
A part of achieving a CII Badge involves in setting up a security disclosure process, which is a great practice for all open source projects to have. However, not all security disclosure processes are tested so the TOC is considering the requirement moving forward to have CNCF projects go through a third party security audit which helps test the security disclosure process.
Some examples here:
https://github.com/envoyproxy/envoy#security-audit
https://coredns.io/2018/03/15/cure53-security-assessment/