Skip to content
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

Merged
merged 3 commits into from Mar 2, 2019
Merged

Conversation

@caniszczyk
Copy link
Contributor

caniszczyk commented Aug 20, 2018

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/

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.
@yurishkuro

This comment has been minimized.

Copy link
Contributor

yurishkuro commented Aug 20, 2018

A couple of questions

  • what is the cost of 3rd party audit?
  • how much value is in a (one time) security audit for projects with frequent releases?
@caniszczyk

This comment has been minimized.

Copy link
Contributor Author

caniszczyk commented Aug 20, 2018

@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

@caniszczyk

This comment has been minimized.

Copy link
Contributor Author

caniszczyk commented Aug 20, 2018

@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

process/graduation_criteria.adoc Outdated Show resolved Hide resolved
@JustinCappos

This comment has been minimized.

Copy link
Contributor

JustinCappos commented Aug 20, 2018

@bgrant0607

This comment has been minimized.

Copy link
Contributor

bgrant0607 commented Jan 25, 2019

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:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md

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.

@david-a-wheeler

This comment has been minimized.

Copy link

david-a-wheeler commented Jan 25, 2019

@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.

@bgrant0607

This comment has been minimized.

Copy link
Contributor

bgrant0607 commented Jan 25, 2019

Thanks @david-a-wheeler! Will take a look.

@mayakacz

This comment has been minimized.

Copy link

mayakacz commented Jan 31, 2019

This is a very reasonable minimum bar.

critical vulnerabilities need to be addressed before graduation
@mattklein123

This comment has been minimized.

Copy link
Contributor

mattklein123 commented Feb 19, 2019

+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.

@brendandburns

This comment has been minimized.

Copy link

brendandburns commented Feb 22, 2019

This seems reasonable to me as a place to start.

@caniszczyk

This comment has been minimized.

Copy link
Contributor Author

caniszczyk commented Mar 2, 2019

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!

@caniszczyk caniszczyk merged commit 44e023d into master Mar 2, 2019
@caniszczyk caniszczyk deleted the audit-graduation branch Mar 14, 2019
@caniszczyk caniszczyk moved this from To do to Done in TOC Project Backlog Apr 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
9 participants
You can’t perform that action at this time.