Questions Seeking Clarification on Publicly Documented Security Engineering Practices in the Kubernetes Community
8 views
Skip to first unread message
n05ec
Jun 8, 2026, 5:28:30 AM (12 days ago) Jun 8
to contri...@kubernetes.io, comm...@kubernetes.io, stee...@kubernetes.io, release-...@kubernetes.io
Dear Kubernetes community maintainers / responsible contacts,
Hello.
As the N05ec Security Team, we have continuously observed over the past six months that vulnerability reports generated through AI-driven automated vulnerability discovery are exerting a significant impact on the open source community ecosystem. We are therefore conducting a systematic study of security engineering practices in the Kubernetes community, with the goal of clarifying the deeper impact of AI-based vulnerability discovery and AI-assisted code development on open source security processes, and of providing reliable reference material for improving the security resilience of the open source ecosystem. Based on publicly available Kubernetes materials, we have completed an initial round of analysis. To avoid overstating the boundary of publicly documented rules, and to avoid mischaracterizing non-public internal processes as formal community practices, we would like to seek clarification on several points concerning publicly visible facts and current evidence gaps.
Based on kubernetes.io, kubernetes.dev, official repository rule files, and official security and release documentation, our current understanding is as follows.
First, we understand that Kubernetes has formalized its private vulnerability reporting and disclosure path as an explicit institutional chain. Public materials appear to support the statement that security vulnerabilities affecting upstream Kubernetes are first handled privately through secu...@kubernetes.io and the SRC, and are then disclosed externally through the official CVE Feed and related security announcement channels.
Second, we understand that Kubernetes has publicly documented the mainline code acceptance path as a continuous gated chain. Public rules appear to support the description that external contributors first pass through CLA and /ok-to-test to enter central testing resources, then receive /lgtm from a reviewer based on OWNERS, /approve from an approver, and then proceed through presubmit, Prow, Tide, and related status checks before code enters the merge pool and is ultimately merged.
Third, we understand that significant design changes for new features or cross-SIG scope are required to enter the KEP governance process, rather than being handled only through ordinary PR review.
Fourth, we understand that Kubernetes has publicly documented executable verification paths for official release artifacts on the user side. Public documentation appears to support independent verification of binaries, images, and SPDX SBOM artifacts through signatures, certificates, and checksum-related validation, so that the statement “users can independently verify official release artifacts” can be made with confidence.
Fifth, we understand that Kubernetes has already introduced formal requirements for AI-assisted contributions in the PR context. Public rules require authors to disclose AI use, understand the changes they submit, and personally respond to review comments, while also restricting certain practices that would weaken accountability. We therefore currently understand this as meaning that AI-related requirements have entered the contribution gate, but remain mainly stable within the PR context.
If any of the above is inaccurate, we would greatly appreciate your correction. In particular, if any of these statements goes beyond what public materials themselves can support, we would be grateful if you could indicate whether we should downgrade the wording to “insufficient public evidence” or otherwise restate it more cautiously.
On that basis, we would also like to ask about several areas where public evidence remains relatively weak or where we have not yet formed strong conclusions, so that we can more fully answer research questions concerning “how requirements are implemented, measured, continuously operated, and improved,” “third-party dependency security,” “build process security,” “release integrity,” and “AI risk governance.”
Regarding the boundary of responsibilities among PSC, SRC, SIG/WG, and release engineering, we can currently confirm the SRC response chain, the OWNERS permission chain, and the release verification chain, but we still find it difficult to accurately describe higher-level governance and authorization boundaries. Is there any official governance documentation, role map, or public wording that would better explain the division of responsibilities and applicable scope among these roles?
Regarding the security admission of third-party dependencies or external components before they enter an upstream PR, we can currently confirm only that once such changes enter a PR, they are subject to the existing mainline gates. However, we have not found public rules for a unified allowlist, unified dependency risk classification, unified SCA thresholds, or a unified exception approval chain. From the perspective of public institutional wording, should this continue to be described as “public materials are insufficient to confirm a unified pre-PR admission regime”?
Regarding build isolation, artifact generation paths, signing credential governance, full provenance / attestation coverage, and the internal release approval chain, we can currently confirm only that the user-side verification chain is public, but we cannot confirm the internal supply-chain process with the same level of strength. Are there public official materials suitable for citation on these points? If not, should we continue to keep them as public evidence gaps?
Regarding “how requirements are measured, continuously operated, and improved,” we can currently observe public operational signals mainly through Testgrid, required status checks, kubernetes-security-announce, and the official CVE Feed, but we cannot infer from those signals the existence of a unified internal warning-burn-down platform, unified risk thresholds, or unified cross-repository security operations metrics. Would you consider that understanding to be closer to the real boundary of Kubernetes’ public world?
Regarding AI risk governance, we currently understand that Kubernetes has formalized AI usage requirements in the PR context, but that we have not yet seen publicly documented rules of the same level for design, dependency introduction, build, or release approval stages. Under the community’s current public rules, would you consider that statement accurate? If there are public materials covering these stages, we would be grateful if you could point us to them.
For security-sensitive paths or release-related paths, we have not yet confirmed whether there are additional approval requirements or stronger gates beyond ordinary OWNERS + CI. If there is no public rule on this, should we continue to interpret such paths using the ordinary mainline gate model?
If any of these questions touches on processes that are not suitable for public explanation, we are only seeking confirmation as to whether we should continue to treat them as public evidence gaps; we are not requesting disclosure of non-public details.
If any of the above questions has already been answered in another public page, mailing list explanation, governance document, or rule file, we would also greatly appreciate direct links or titles so that we can return to the public source and revise our report accordingly.
If this mailbox or mailing list is not the most appropriate entry point for this type of research clarification request, we would also appreciate your help in redirecting us to a more appropriate public contact for questions concerning Kubernetes governance rules, contribution gates, release engineering, or security response boundaries.
Thank you for taking the time to read this message, and thank you to the community for making these institutional and engineering materials publicly available over the long term.
Sincerely,
N05ec
n05ec...@gmail.com
Hello.
As the N05ec Security Team, we have continuously observed over the past six months that vulnerability reports generated through AI-driven automated vulnerability discovery are exerting a significant impact on the open source community ecosystem. We are therefore conducting a systematic study of security engineering practices in the Kubernetes community, with the goal of clarifying the deeper impact of AI-based vulnerability discovery and AI-assisted code development on open source security processes, and of providing reliable reference material for improving the security resilience of the open source ecosystem. Based on publicly available Kubernetes materials, we have completed an initial round of analysis. To avoid overstating the boundary of publicly documented rules, and to avoid mischaracterizing non-public internal processes as formal community practices, we would like to seek clarification on several points concerning publicly visible facts and current evidence gaps.
Based on kubernetes.io, kubernetes.dev, official repository rule files, and official security and release documentation, our current understanding is as follows.
First, we understand that Kubernetes has formalized its private vulnerability reporting and disclosure path as an explicit institutional chain. Public materials appear to support the statement that security vulnerabilities affecting upstream Kubernetes are first handled privately through secu...@kubernetes.io and the SRC, and are then disclosed externally through the official CVE Feed and related security announcement channels.
Second, we understand that Kubernetes has publicly documented the mainline code acceptance path as a continuous gated chain. Public rules appear to support the description that external contributors first pass through CLA and /ok-to-test to enter central testing resources, then receive /lgtm from a reviewer based on OWNERS, /approve from an approver, and then proceed through presubmit, Prow, Tide, and related status checks before code enters the merge pool and is ultimately merged.
Third, we understand that significant design changes for new features or cross-SIG scope are required to enter the KEP governance process, rather than being handled only through ordinary PR review.
Fourth, we understand that Kubernetes has publicly documented executable verification paths for official release artifacts on the user side. Public documentation appears to support independent verification of binaries, images, and SPDX SBOM artifacts through signatures, certificates, and checksum-related validation, so that the statement “users can independently verify official release artifacts” can be made with confidence.
Fifth, we understand that Kubernetes has already introduced formal requirements for AI-assisted contributions in the PR context. Public rules require authors to disclose AI use, understand the changes they submit, and personally respond to review comments, while also restricting certain practices that would weaken accountability. We therefore currently understand this as meaning that AI-related requirements have entered the contribution gate, but remain mainly stable within the PR context.
If any of the above is inaccurate, we would greatly appreciate your correction. In particular, if any of these statements goes beyond what public materials themselves can support, we would be grateful if you could indicate whether we should downgrade the wording to “insufficient public evidence” or otherwise restate it more cautiously.
On that basis, we would also like to ask about several areas where public evidence remains relatively weak or where we have not yet formed strong conclusions, so that we can more fully answer research questions concerning “how requirements are implemented, measured, continuously operated, and improved,” “third-party dependency security,” “build process security,” “release integrity,” and “AI risk governance.”
Regarding the boundary of responsibilities among PSC, SRC, SIG/WG, and release engineering, we can currently confirm the SRC response chain, the OWNERS permission chain, and the release verification chain, but we still find it difficult to accurately describe higher-level governance and authorization boundaries. Is there any official governance documentation, role map, or public wording that would better explain the division of responsibilities and applicable scope among these roles?
Regarding the security admission of third-party dependencies or external components before they enter an upstream PR, we can currently confirm only that once such changes enter a PR, they are subject to the existing mainline gates. However, we have not found public rules for a unified allowlist, unified dependency risk classification, unified SCA thresholds, or a unified exception approval chain. From the perspective of public institutional wording, should this continue to be described as “public materials are insufficient to confirm a unified pre-PR admission regime”?
Regarding build isolation, artifact generation paths, signing credential governance, full provenance / attestation coverage, and the internal release approval chain, we can currently confirm only that the user-side verification chain is public, but we cannot confirm the internal supply-chain process with the same level of strength. Are there public official materials suitable for citation on these points? If not, should we continue to keep them as public evidence gaps?
Regarding “how requirements are measured, continuously operated, and improved,” we can currently observe public operational signals mainly through Testgrid, required status checks, kubernetes-security-announce, and the official CVE Feed, but we cannot infer from those signals the existence of a unified internal warning-burn-down platform, unified risk thresholds, or unified cross-repository security operations metrics. Would you consider that understanding to be closer to the real boundary of Kubernetes’ public world?
Regarding AI risk governance, we currently understand that Kubernetes has formalized AI usage requirements in the PR context, but that we have not yet seen publicly documented rules of the same level for design, dependency introduction, build, or release approval stages. Under the community’s current public rules, would you consider that statement accurate? If there are public materials covering these stages, we would be grateful if you could point us to them.
For security-sensitive paths or release-related paths, we have not yet confirmed whether there are additional approval requirements or stronger gates beyond ordinary OWNERS + CI. If there is no public rule on this, should we continue to interpret such paths using the ordinary mainline gate model?
If any of these questions touches on processes that are not suitable for public explanation, we are only seeking confirmation as to whether we should continue to treat them as public evidence gaps; we are not requesting disclosure of non-public details.
If any of the above questions has already been answered in another public page, mailing list explanation, governance document, or rule file, we would also greatly appreciate direct links or titles so that we can return to the public source and revise our report accordingly.
If this mailbox or mailing list is not the most appropriate entry point for this type of research clarification request, we would also appreciate your help in redirecting us to a more appropriate public contact for questions concerning Kubernetes governance rules, contribution gates, release engineering, or security response boundaries.
Thank you for taking the time to read this message, and thank you to the community for making these institutional and engineering materials publicly available over the long term.
Sincerely,
N05ec
n05ec...@gmail.com
Davanum Srinivas
Jun 8, 2026, 6:39:59 AM (12 days ago) Jun 8
to n05ec, contri...@kubernetes.io, comm...@kubernetes.io, stee...@kubernetes.io, release-...@kubernetes.io
Hi,
Can you please explain why this is a useful exercise for the community to respond to you? (It takes a lot of time and effort and spans multiple governance structures as you pointed out)
-- Dims
--
You received this message because you are subscribed to the Google Groups "steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to steering+u...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/CA%2BmzHbXH8SGurgWM1dGGBmjS1hzq_sNE%3DihnEMc_CkEP9gqhkw%40mail.gmail.com.
Davanum Srinivas :: https://twitter.com/dims
n05ec
Jun 9, 2026, 2:02:57 AM (11 days ago) Jun 9
to Davanum Srinivas, contri...@kubernetes.io, comm...@kubernetes.io, stee...@kubernetes.io, release-...@kubernetes.io
Hi Dims,
Thank you for asking. I understand your concern, since my previous email did touch several areas of Kubernetes governance and release/security work.
I think the practical value for the community is this: our team has been doing vulnerability discovery and vulnerability-reporting work, and we want to make sure that we, and people reading our write-up, use the correct public Kubernetes process. If we misunderstand the process, that could lead to security reports being routed to the wrong place, sensitive issues being discussed in the wrong venue, AI-assisted reports not meeting the expected quality bar, or inaccurate external descriptions of how Kubernetes handles security issues.
We are not asking the community to review a full external report. We are trying to check whether our understanding of Kubernetes public documentation is accurate, and where we should avoid going beyond what the public documentation supports. That is why the previous email mentioned the SRC/security reporting path, PR gates, dependency-related cases, release artifacts, SBOM/signing/provenance, and AI-assisted submissions. These are areas that a vulnerability report or security fix may touch in the normal Kubernetes process, and we want to know whether public documentation is sufficient or whether we should mark the relevant items as public evidence gaps.
A complete response would of course be very helpful, but we understand that may take too much time. If you could instead point us to one or two public documents that external vulnerability researchers should rely on, or let us know that some areas in my previous email should simply be treated as not publicly documented, that would already be enough for us to revise the statements in our write-up.
If the community still feels that this is not worth spending time on, I understand. We will rely only on the existing public documentation and keep the unclear parts marked as public evidence gaps.
Best regards,
N05ec
Thank you for asking. I understand your concern, since my previous email did touch several areas of Kubernetes governance and release/security work.
I think the practical value for the community is this: our team has been doing vulnerability discovery and vulnerability-reporting work, and we want to make sure that we, and people reading our write-up, use the correct public Kubernetes process. If we misunderstand the process, that could lead to security reports being routed to the wrong place, sensitive issues being discussed in the wrong venue, AI-assisted reports not meeting the expected quality bar, or inaccurate external descriptions of how Kubernetes handles security issues.
We are not asking the community to review a full external report. We are trying to check whether our understanding of Kubernetes public documentation is accurate, and where we should avoid going beyond what the public documentation supports. That is why the previous email mentioned the SRC/security reporting path, PR gates, dependency-related cases, release artifacts, SBOM/signing/provenance, and AI-assisted submissions. These are areas that a vulnerability report or security fix may touch in the normal Kubernetes process, and we want to know whether public documentation is sufficient or whether we should mark the relevant items as public evidence gaps.
A complete response would of course be very helpful, but we understand that may take too much time. If you could instead point us to one or two public documents that external vulnerability researchers should rely on, or let us know that some areas in my previous email should simply be treated as not publicly documented, that would already be enough for us to revise the statements in our write-up.
If the community still feels that this is not worth spending time on, I understand. We will rely only on the existing public documentation and keep the unclear parts marked as public evidence gaps.
Best regards,
N05ec
Davanum Srinivas <dav...@gmail.com> 于2026年6月8日周一 18:39写道：
Davanum Srinivas
Jun 9, 2026, 6:22:57 AM (11 days ago) Jun 9
to n05ec, contri...@kubernetes.io, comm...@kubernetes.io, stee...@kubernetes.io, release-...@kubernetes.io
Reply all
Reply to author
Forward
0 new messages