Community: Security audit WG disclosure process

[zelivans]

The security reports requested by the Security Audit Working Group were released two days ago on Github and published in the CNCF website.

The majority of the issue identified by the researchers in the ToB report have seemingly not been addressed at the time of the release. In the past day the new issues were assigned public GitHub issues. The issues can be tracked under https://github.com/kubernetes/kubernetes/issues/81146.

Some of the issues described in the report should be treated as security enhancements or feature suggestions, and it may be desirable to make them public and open GitHub issues for their discussion. However, there are some issues that should be considered security vulnerabilities that would normally not be disclosed prior to a fix release.

• Was there any reason for the full release of the reports publicly instead of being solved by a fix team and then released as described in the Kubernetes security release process?

• Will any CVE IDs be allocated by the Kubernetes CNA for the specific issues that are to be considered security bugs?

[zelivans]

/committee product-security
/wg security-audit

[cblecker]

cc: @kubernetes/product-security-committee

[liggitt]

• Was there any reason for the full release of the reports publicly instead of being solved by a fix team and then released as described in the Kubernetes security release process?

The report was disclosed privately and each item reviewed by the product security committee prior to release. All of the identified items were judged to be appropriate to fix via a public issue, for one or more of the following reasons:

• they were already disclosed/tracked in public issues (e.g. https://github.com/kubernetes/kubernetes/issues/81111 / https://github.com/kubernetes/kubernetes/issues/18982, https://github.com/kubernetes/kubernetes/issues/81137 / https://github.com/kubernetes/kubernetes/issues/31824)
• they were considered a feature request (e.g. https://github.com/kubernetes/kubernetes/issues/81110)
• they require breaking backwards compatibility which must be done over multiple releases and pre-announced (e.g. https://github.com/kubernetes/kubernetes/issues/81115, https://github.com/kubernetes/kubernetes/issues/81136, https://github.com/kubernetes/kubernetes/issues/81112, https://github.com/kubernetes/kubernetes/issues/81128)
• they identify configurations which can be secured (and are in recommended deployments), but which permit insecure use (e.g. https://github.com/kubernetes/kubernetes/issues/81119, https://github.com/kubernetes/kubernetes/issues/81145)
• they were defense-in-depth or low severity recommendations (e.g. https://github.com/kubernetes/kubernetes/issues/81133)

[liggitt]

/close

[k8s-ci-robot]

@liggitt: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[liggitt]

Will any CVE IDs be allocated by the Kubernetes CNA for the specific issues that are to be considered security bugs?

Yes, CVE IDs will be issued for security vulnerabilities