2026/9/17 1:32:39
FEATURED · 精选文章 
SIG Security 2024 年度报告深度解读Kubernetes 安全审计、安全文档与 CVE 工具链的年度全景【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/communityKubernetes 社区仓库com/community中的 SIG Security 2024 年度报告 记录了安全特别兴趣小组在 2024 年度的核心工作推进 Kubernetes 项目第三次全面第三方安全审计、发布面向应用开发者的 Application Security Checklist、正式接管 cve-feed-osv 工具链并完成 SecurityContextDeny 特性的移除。本文以该年度报告为主体结合仓库内的 SIG Security Charter、sigs.yaml 配置、README 与 年度报告生成模板 等源码级资料逐项拆解 2024 年安全工作的进展、子项目架构与治理机制。读完本文你将清晰掌握 SIG Security 的组织分工、年度报告的结构逻辑以及每项安全举措对 Kubernetes 用户的实际影响。一、年度报告背景SIG Security 的定位与职责在深入 2024 年报告内容之前有必要先明确 SIG Security 在整个 Kubernetes 项目中的位置。根据仓库根目录 sigs.yaml 中的注册信息SIG Security 的使命声明为SIG Security takes a community-building approach to improving security for end users, project maintainers, and the Kubernetes project itself.即通过社区共建的方式为最终用户、项目维护者以及 Kubernetes 项目本身改善安全性跨 SIG 协作推进安全相关特性、编写和更新文档、维护安全流程与工具。SIG Security Charter 进一步明确了其定位与边界核心职责覆盖 Kubernetes 项目的横向安全倡议包括周期性安全审计regular security audits、漏洞管理流程vulnerability management process、跨领域的横切安全文档cross-cutting security documentation以及安全社区管理过程型 SIG 定位作为一个以流程为导向的 SIG它不直接拥有 Kubernetes 组件代码这一点与拥有集群组件代码的 SIG Auth 形成对比明确不在范围内的事项Kubernetes 的认证、授权、审计与安全策略特性归属 SIG Auth私有漏洞响应归属 PSC即 Product Security CommitteeAPI 数据机密性/完整性保护机制其他 CNCF 项目etcd、CoreDNS、CRI-O、containerd 等的安全审计。在治理上SIG Security 的 Chair 由 Ian Coldwater、Cailyn Edwards、Tabitha Sable 三人担任见 sig-security/README.mdSIG 采用双周例会制度太平洋时间每周五 8:00并遵循 SIG 治理文档 规定的年度报告要求——即每个 SIG 必须记录活动并完成年度报告这正是本篇所解读文档的诞生背景。二、2024 年度核心成果总览2024 年度报告的第一部分What work did the SIG do this year that should be highlighted?集中列举了本年度值得突出的工作。概括起来SIG Security 在 2024 年围绕人、流程、工具、文档四个维度取得了如下进展维度2024 年关键事件涉及子项目组织与人才Cailyn Edwards 加入担任联合 Chair多位新领导上任sig-securitySIG 本体审计启动最新一轮第三方全面安全审计RFP 发布、供应商选定security-audit文档发布 Application Security Checklistsecurity-docs工具接管 cve-feed-osv 工具链提升 CVE 扫描准确性security-tooling特性清理移除 SecurityContextDeny 旧特性sig-securityKEP 协作以下各节将逐项展开。三、领导层迭代2024 年的新人培养与传承年度报告明确将培养新一代贡献者cultivating new generations of contributors列为 2024 年的首要亮点。具体的人事变动包括Cailyn Edwards 加入成为 SIG 联合 Chairco-chairIain Smart与 Rey Lejano 共同领导第三方审计工作Third-Party AuditRory McCune与 Savitha Raghunathan 共同领导 SIG Security Docs 子项目Mahé Tardy 与 Eric Smalling加入成为 SIG Security Tooling 的新 shadow leads影子负责人即培养中的负责人。这一系列人事变动体现了 SIG Security 的梯队建设策略通过 shadow lead 机制让新人逐步接手子项目领导职责同时保持每个子项目有多名活跃负责人。对照 sigs.yaml 中的 subprojects 注册信息可以看出SIG Security 下辖的每个子项目均配置了独立的 OWNERS 与 Slack 频道例如security-audit第三方安全审计OWNERS 指向 sig-security-external-auditsecurity-docs安全文档与文档化工作联系频道#sig-security-docssecurity-tooling安全工具的开发与增强OWNERS 同时指向 kubernetes-sigs/cve-feed-osv 与 sig-security-toolingsig-securitySIG 讨论、文档、流程与制品。这种一子项目一负责人组 独立频道的结构为 2024 年新领导的平滑交接提供了制度保障。四、security-audit启动 Kubernetes 最新一轮第三方全面安全审计4.1 2024 年审计推进节点年度报告指出2024 年 security-audit 子项目完成了新一轮全面第三方安全审计comprehensive third-party security audit的启动阶段工作发布 RFPRequest for Proposal招标书→ 选定审计供应商 → 正式启动审计。新审计已于 2024 年内进入执行阶段并预计于 2025 年完成。这一工作延续了 SIG Security 的历史使命。根据 SIG Security CharterSIG 脱胎于第三方安全审计工作组Third-Party Security Audit Working Group该工作组曾负责管理历次循环进行的第三方安全审计的生命周期——创建 RFP、选择供应商、并管理供应商与其他 SIG 及领域专家的协作。SIG Security 成立后继续承担这一职责并将其扩展为包含漏洞管理、加固指南、安全文档等更广泛的使命。4.2 审计子项目的职责边界Charter 中明确了安全审计职责的完整闭环管理周期性安全审计并跟进问题协调供应商执行审计并发布发现findings跟进受影响 SIG 的问题解决协助排定修复优先级可招募 SIG Security 成员参与但最终是否修复、如何修复的决定权归属责任 SIG记录缓解措施当责任 SIG 决定不修复某个问题时负责记录缓解方案、临时规避措施或注意事项。从源码结构看这一分工确保了审计子项目发现问题 协调推动而不越权修复的定位是 Kubernetes 多 SIG 协作治理的典型体现。五、security-docs面向应用开发者的 Application Security Checklist5.1 为什么需要这份清单2024 年 security-docs 子项目发布了Application Security Checklist应用安全清单。年度报告点明了其价值定位大多数 Kubernetes 安全建议是为集群管理员而非应用开发者编写的这导致应用开发者难以找到贴合自身角色的安全实践指导。这份清单正是为了填补这一空白让 Kubernetes 安全更易获得more accessible。5.2 清单与 SIG 文档职责的关系对照 Chartersecurity-docs 的职责属于横向安全文档Horizontal Security Documentation范畴包括加固指南与最佳实践Hardening guides and best practices安全基准Security benchmarks改善文档以消除常见误解或疑问威胁模型Threat models。其中特别值得注意的是Charter 规定安全文档与技术文档技术负责人将负责维护官方 Kubernetes 项目安全加固指南Security Hardening Guide。Application Security Checklist 正是这条职责线在 2024 年的具体产出。Rory McCune 与 Savitha Raghunathan 作为 2024 年新接手的 security-docs 负责人主导了这份文档的发布。六、security-tooling接管 cve-feed-osv提升漏洞扫描准确率6.1 cve-feed-osv 是什么2024 年 SIG Security Tooling 正式接管adopted了 cve-feed-osv——一组用于为 Kubernetes 发布的 CVE 生成OSV 格式Open Source Vulnerability format文档的工具。年度报告阐述了其核心价值These tools help end-users get fewer false-positive vulnerability scanner results, by ensuring higher quality detections in their scanning tools.即通过生成更高质量的漏洞描述帮助最终用户在扫描工具中获得更少的误报false-positive结果。6.2 未来的演进方向报告指出这些工具未来可能成为官方 CVE Feedofficial CVE feed的一部分。结合 2025 年年度报告sig-security/annual-report-2025.md的后续进展可以印证这一方向2025 年 SIG Security Tooling 持续维护并改进 Official CVE Feed对应 enhancements 仓库 issue #3203迁移漏洞扫描工具到新集群、为 CVE Feed 增加自动化测试、并改善了格式不规则的处理逻辑。6.3 工具链与漏洞管理流程的关联从 sig-security/charter.md 的 In Scope 章节可知SIG Security 负责非保密public漏洞流程的管理并与 Security Response CommitteeSRC 协作定义漏洞修复与披露流程。cve-feed-osv 工具链正是这一流程中的关键一环——它将 Kubernetes 安全公告转化为机器可读的 OSV 结构化数据供下游扫描器消费从而桥接漏洞披露与终端用户检测两个环节。七、KEP 工作移除 SecurityContextDeny减轻合规负担7.1 SecurityContextDeny 的来龙去脉2024 年 SIG Security 完成了一项极具代表性的特性清理工作移除了 SecurityContextDeny对应 enhancements 仓库 issue #3785。年度报告对此特性的描述颇具历史感a feature that was so old it predated the KEP process!即该特性古老到早于 KEP 流程本身KEP 即 Kubernetes Enhancement ProposalKubernetes 增强提案机制2018 年前后才系统化。SecurityContextDeny 是一个准入控制器admission controller用于拒绝 Pod 中过高的安全上下文设置但多年来已被标记为废弃deprecated。7.2 移除的现实意义年度报告指出了移除该特性的两个直接收益减轻合规负担尽管该特性已废弃多年但只要它仍存在于代码中就会出现在 CIS Benchmarks 等合规框架的检查项中。移除后受监管行业的用户regulated industries将减少提交偏差请求deviation request的文书工作量提升项目整体安全性移除陈旧废弃代码降低了误用和维护成本。从 KEP 治理的角度看这一工作也展示了 Kubernetes 社区的技术债清理能力——即便一个特性早于 KEP 机制存在社区仍能通过规范的提案流程将其彻底移除。2024 年度报告覆盖的 KEP 工作对应 v1.30、v1.31、v1.32 三个版本周期。八、子项目状态盘点security-assessments 的归档Sunset8.1 2024 年子项目最终状态年度报告的子项目部分列出了最终分类Continuing持续运行security-audit第三方安全审计security-docs安全文档security-tooling安全工具sig-securitySIG 本体Sunset已归档security-assessments安全自评估8.2 自评估子项目的历史与贡献2024 年SIG Security归档了 Security Self-Assessments 子项目即 security-assessments该项目此前由Ala Dewberry领导。年度报告对 Ala 的贡献给予了高度评价她以专业、热情与好奇心skill, warmth, and curiosity领导自评估工作通过工作坊workshops、文档与自评估流程的引导帮助众多贡献者了解自己项目的安全性。报告同时致谢了Pushkar Joglekar他主导了第一次自评估、创建了该子项目并指导 Ala 成长为领导者。自评估子项目的文档与制品将继续保留在 kubernetes/sig-security 仓库中供未来参考。8.3 归档机制与仓库佐证对照 sig-wg-lifecycle.md 中的 SIG/子项目退休流程可知归档sunset是一个正式的治理动作通常包含决策沟通、Slack 频道归档、将 SIG 目录移入archive/、GitHub 仓库转移或归档等步骤。本仓库的 archive/ 目录即存放了已归档的 SIG/WG 文档如 sig-cluster-ops、wg-policy 等印证了这一机制的存在。一个值得注意的对比在 sigs.yaml 中security-self-assessments 仍被列为 sig-security 的子项目含#sig-security-assessments频道而 2025 年度报告显示该子项目在 2025 年又退役并复活Retired and Resurrected。这体现了 Kubernetes 社区子项目治理的动态性——归档不等于永久终止可以根据社区需要重启。九、社区外联KubeCon 演讲与立场选择9.1 2024 年社区级更新年度报告记录了两次社区层面的关键事件KubeCon EU 2024SIG Security 在 KubeCon EU 2024 做了维护者专场演讲maintainer track talk主题为SIG Security Update: Growing Together共同成长KubeCon NA 2024经负责人共识SIG Security未在盐湖城Salt Lake City举办的 KubeCon NA 2024 上设置官方代表原因是犹他州的反跨性别法律anti-transgender laws使该地点对 SIG 领导层及其所关爱的人群不安全。报告表达了失望并期待 2025 年在欧洲与大家相见。这一选择体现了 SIG Security 将社区成员的安全与包容性置于会议曝光之上的价值取向也是年度报告中颇具人文色彩的立场声明。十、运营自查清单年度治理的标准化收尾年度报告末尾的 Operational 部分是一份标准化的运营自查清单所有条目在 2024 年均已勾选完成[x]包括审阅 README.md 并确认/更新其准确性审阅 CONTRIBUTING.md 并确认/更新其准确性审阅其他贡献文档如 devel 目录或贡献者指南审阅 sigs.yaml 中的子项目列表与关联的 OWNERS 文件确认 sigs.yaml 中的 SIG 负责人chairs、tech leads、subproject leads准确且活跃确认 2024 年的会议纪要与会话录制已从 README.md 链接并可访问。从模板理解这份清单的来源对照仓库中的 年度报告生成模板 可以发现这份运营清单并非手工撰写而是由模板自动生成的固定结构。模板中的 KEP 工作部分第 4 节设计为从 kubernetes/enhancements 仓库的 KEP 元数据自动生成 Alpha/Beta/Stable 清单通过getReleases、filterKEPs等 Go 模板函数子项目与工作组部分则由getCategorizedSubprojects、getCategorizedWorkingGroups函数按 New/Retired/Continuing 自动分类。在模板生成流程上generator/README.md 说明所有 SIG 信息的权威来源是仓库根目录的 sigs.yaml 文件任何更新都必须先修改 sigs.yaml再通过make generate或容器化方式make generate-containerized重新生成各 SIG 的 README 文档。这也是 sig-security 的 README.md 顶部标注本文件为自动生成请勿直接编辑应修改 sigs.yaml的原因。年度报告虽然由 SIG 成员撰写正文但其骨架标题、章节、检查项、KEP 清单占位同样遵循模板约定保证了各 SIG 年度报告格式的一致性便于横向对比与自动处理。十一、总结与展望回顾 2024 年度报告SIG Security 呈现出一条清晰的工作主线审计层面启动最新一轮第三方全面安全审计延续项目级安全基线保障文档层面通过 Application Security Checklist 将安全知识下沉到应用开发者群体扩大安全实践覆盖面工具层面接管 cve-feed-osv用 OSV 标准格式提升 CVE 数据的机器可读性与扫描准确性治理层面完成 SecurityContextDeny 的移除与 security-assessments 子项目的归档同时通过新人培养与 shadow lead 机制确保组织活力。对读者而言这份年度报告的价值不仅在于了解2024 年发生了什么更在于透过其结构理解 Kubernetes 社区的安全治理范式以流程型 SIG 统筹横向安全议题、以子项目制分解长期职责、以年度报告 模板 sigs.yaml 实现可审计的治理闭环。对于希望参与 Kubernetes 安全工作的贡献者年度报告也释放了明确信号——security-docs 子项目持续欢迎各经验水平的贡献者是进入 Kubernetes 安全领域的友好入口。如果想继续深入可以进一步阅读SIG Security CharterSIG 的完整职责边界与治理约定sig-security/README.md子项目、负责人与会议信息SIG 治理文档SIG 运营的标准要求年度报告生成模板理解报告结构的自动化来源sigs.yamlSIG 信息的权威数据源。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
SIG Security 2024 年度报告深度解读：Kubernetes 安全审计、安全文档与 CVE 工具链的年度全景
SIG Security 2024 年度报告深度解读Kubernetes 安全审计、安全文档与 CVE 工具链的年度全景【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/communityKubernetes 社区仓库com/community中的 SIG Security 2024 年度报告 记录了安全特别兴趣小组在 2024 年度的核心工作推进 Kubernetes 项目第三次全面第三方安全审计、发布面向应用开发者的 Application Security Checklist、正式接管 cve-feed-osv 工具链并完成 SecurityContextDeny 特性的移除。本文以该年度报告为主体结合仓库内的 SIG Security Charter、sigs.yaml 配置、README 与 年度报告生成模板 等源码级资料逐项拆解 2024 年安全工作的进展、子项目架构与治理机制。读完本文你将清晰掌握 SIG Security 的组织分工、年度报告的结构逻辑以及每项安全举措对 Kubernetes 用户的实际影响。一、年度报告背景SIG Security 的定位与职责在深入 2024 年报告内容之前有必要先明确 SIG Security 在整个 Kubernetes 项目中的位置。根据仓库根目录 sigs.yaml 中的注册信息SIG Security 的使命声明为SIG Security takes a community-building approach to improving security for end users, project maintainers, and the Kubernetes project itself.即通过社区共建的方式为最终用户、项目维护者以及 Kubernetes 项目本身改善安全性跨 SIG 协作推进安全相关特性、编写和更新文档、维护安全流程与工具。SIG Security Charter 进一步明确了其定位与边界核心职责覆盖 Kubernetes 项目的横向安全倡议包括周期性安全审计regular security audits、漏洞管理流程vulnerability management process、跨领域的横切安全文档cross-cutting security documentation以及安全社区管理过程型 SIG 定位作为一个以流程为导向的 SIG它不直接拥有 Kubernetes 组件代码这一点与拥有集群组件代码的 SIG Auth 形成对比明确不在范围内的事项Kubernetes 的认证、授权、审计与安全策略特性归属 SIG Auth私有漏洞响应归属 PSC即 Product Security CommitteeAPI 数据机密性/完整性保护机制其他 CNCF 项目etcd、CoreDNS、CRI-O、containerd 等的安全审计。在治理上SIG Security 的 Chair 由 Ian Coldwater、Cailyn Edwards、Tabitha Sable 三人担任见 sig-security/README.mdSIG 采用双周例会制度太平洋时间每周五 8:00并遵循 SIG 治理文档 规定的年度报告要求——即每个 SIG 必须记录活动并完成年度报告这正是本篇所解读文档的诞生背景。二、2024 年度核心成果总览2024 年度报告的第一部分What work did the SIG do this year that should be highlighted?集中列举了本年度值得突出的工作。概括起来SIG Security 在 2024 年围绕人、流程、工具、文档四个维度取得了如下进展维度2024 年关键事件涉及子项目组织与人才Cailyn Edwards 加入担任联合 Chair多位新领导上任sig-securitySIG 本体审计启动最新一轮第三方全面安全审计RFP 发布、供应商选定security-audit文档发布 Application Security Checklistsecurity-docs工具接管 cve-feed-osv 工具链提升 CVE 扫描准确性security-tooling特性清理移除 SecurityContextDeny 旧特性sig-securityKEP 协作以下各节将逐项展开。三、领导层迭代2024 年的新人培养与传承年度报告明确将培养新一代贡献者cultivating new generations of contributors列为 2024 年的首要亮点。具体的人事变动包括Cailyn Edwards 加入成为 SIG 联合 Chairco-chairIain Smart与 Rey Lejano 共同领导第三方审计工作Third-Party AuditRory McCune与 Savitha Raghunathan 共同领导 SIG Security Docs 子项目Mahé Tardy 与 Eric Smalling加入成为 SIG Security Tooling 的新 shadow leads影子负责人即培养中的负责人。这一系列人事变动体现了 SIG Security 的梯队建设策略通过 shadow lead 机制让新人逐步接手子项目领导职责同时保持每个子项目有多名活跃负责人。对照 sigs.yaml 中的 subprojects 注册信息可以看出SIG Security 下辖的每个子项目均配置了独立的 OWNERS 与 Slack 频道例如security-audit第三方安全审计OWNERS 指向 sig-security-external-auditsecurity-docs安全文档与文档化工作联系频道#sig-security-docssecurity-tooling安全工具的开发与增强OWNERS 同时指向 kubernetes-sigs/cve-feed-osv 与 sig-security-toolingsig-securitySIG 讨论、文档、流程与制品。这种一子项目一负责人组 独立频道的结构为 2024 年新领导的平滑交接提供了制度保障。四、security-audit启动 Kubernetes 最新一轮第三方全面安全审计4.1 2024 年审计推进节点年度报告指出2024 年 security-audit 子项目完成了新一轮全面第三方安全审计comprehensive third-party security audit的启动阶段工作发布 RFPRequest for Proposal招标书→ 选定审计供应商 → 正式启动审计。新审计已于 2024 年内进入执行阶段并预计于 2025 年完成。这一工作延续了 SIG Security 的历史使命。根据 SIG Security CharterSIG 脱胎于第三方安全审计工作组Third-Party Security Audit Working Group该工作组曾负责管理历次循环进行的第三方安全审计的生命周期——创建 RFP、选择供应商、并管理供应商与其他 SIG 及领域专家的协作。SIG Security 成立后继续承担这一职责并将其扩展为包含漏洞管理、加固指南、安全文档等更广泛的使命。4.2 审计子项目的职责边界Charter 中明确了安全审计职责的完整闭环管理周期性安全审计并跟进问题协调供应商执行审计并发布发现findings跟进受影响 SIG 的问题解决协助排定修复优先级可招募 SIG Security 成员参与但最终是否修复、如何修复的决定权归属责任 SIG记录缓解措施当责任 SIG 决定不修复某个问题时负责记录缓解方案、临时规避措施或注意事项。从源码结构看这一分工确保了审计子项目发现问题 协调推动而不越权修复的定位是 Kubernetes 多 SIG 协作治理的典型体现。五、security-docs面向应用开发者的 Application Security Checklist5.1 为什么需要这份清单2024 年 security-docs 子项目发布了Application Security Checklist应用安全清单。年度报告点明了其价值定位大多数 Kubernetes 安全建议是为集群管理员而非应用开发者编写的这导致应用开发者难以找到贴合自身角色的安全实践指导。这份清单正是为了填补这一空白让 Kubernetes 安全更易获得more accessible。5.2 清单与 SIG 文档职责的关系对照 Chartersecurity-docs 的职责属于横向安全文档Horizontal Security Documentation范畴包括加固指南与最佳实践Hardening guides and best practices安全基准Security benchmarks改善文档以消除常见误解或疑问威胁模型Threat models。其中特别值得注意的是Charter 规定安全文档与技术文档技术负责人将负责维护官方 Kubernetes 项目安全加固指南Security Hardening Guide。Application Security Checklist 正是这条职责线在 2024 年的具体产出。Rory McCune 与 Savitha Raghunathan 作为 2024 年新接手的 security-docs 负责人主导了这份文档的发布。六、security-tooling接管 cve-feed-osv提升漏洞扫描准确率6.1 cve-feed-osv 是什么2024 年 SIG Security Tooling 正式接管adopted了 cve-feed-osv——一组用于为 Kubernetes 发布的 CVE 生成OSV 格式Open Source Vulnerability format文档的工具。年度报告阐述了其核心价值These tools help end-users get fewer false-positive vulnerability scanner results, by ensuring higher quality detections in their scanning tools.即通过生成更高质量的漏洞描述帮助最终用户在扫描工具中获得更少的误报false-positive结果。6.2 未来的演进方向报告指出这些工具未来可能成为官方 CVE Feedofficial CVE feed的一部分。结合 2025 年年度报告sig-security/annual-report-2025.md的后续进展可以印证这一方向2025 年 SIG Security Tooling 持续维护并改进 Official CVE Feed对应 enhancements 仓库 issue #3203迁移漏洞扫描工具到新集群、为 CVE Feed 增加自动化测试、并改善了格式不规则的处理逻辑。6.3 工具链与漏洞管理流程的关联从 sig-security/charter.md 的 In Scope 章节可知SIG Security 负责非保密public漏洞流程的管理并与 Security Response CommitteeSRC 协作定义漏洞修复与披露流程。cve-feed-osv 工具链正是这一流程中的关键一环——它将 Kubernetes 安全公告转化为机器可读的 OSV 结构化数据供下游扫描器消费从而桥接漏洞披露与终端用户检测两个环节。七、KEP 工作移除 SecurityContextDeny减轻合规负担7.1 SecurityContextDeny 的来龙去脉2024 年 SIG Security 完成了一项极具代表性的特性清理工作移除了 SecurityContextDeny对应 enhancements 仓库 issue #3785。年度报告对此特性的描述颇具历史感a feature that was so old it predated the KEP process!即该特性古老到早于 KEP 流程本身KEP 即 Kubernetes Enhancement ProposalKubernetes 增强提案机制2018 年前后才系统化。SecurityContextDeny 是一个准入控制器admission controller用于拒绝 Pod 中过高的安全上下文设置但多年来已被标记为废弃deprecated。7.2 移除的现实意义年度报告指出了移除该特性的两个直接收益减轻合规负担尽管该特性已废弃多年但只要它仍存在于代码中就会出现在 CIS Benchmarks 等合规框架的检查项中。移除后受监管行业的用户regulated industries将减少提交偏差请求deviation request的文书工作量提升项目整体安全性移除陈旧废弃代码降低了误用和维护成本。从 KEP 治理的角度看这一工作也展示了 Kubernetes 社区的技术债清理能力——即便一个特性早于 KEP 机制存在社区仍能通过规范的提案流程将其彻底移除。2024 年度报告覆盖的 KEP 工作对应 v1.30、v1.31、v1.32 三个版本周期。八、子项目状态盘点security-assessments 的归档Sunset8.1 2024 年子项目最终状态年度报告的子项目部分列出了最终分类Continuing持续运行security-audit第三方安全审计security-docs安全文档security-tooling安全工具sig-securitySIG 本体Sunset已归档security-assessments安全自评估8.2 自评估子项目的历史与贡献2024 年SIG Security归档了 Security Self-Assessments 子项目即 security-assessments该项目此前由Ala Dewberry领导。年度报告对 Ala 的贡献给予了高度评价她以专业、热情与好奇心skill, warmth, and curiosity领导自评估工作通过工作坊workshops、文档与自评估流程的引导帮助众多贡献者了解自己项目的安全性。报告同时致谢了Pushkar Joglekar他主导了第一次自评估、创建了该子项目并指导 Ala 成长为领导者。自评估子项目的文档与制品将继续保留在 kubernetes/sig-security 仓库中供未来参考。8.3 归档机制与仓库佐证对照 sig-wg-lifecycle.md 中的 SIG/子项目退休流程可知归档sunset是一个正式的治理动作通常包含决策沟通、Slack 频道归档、将 SIG 目录移入archive/、GitHub 仓库转移或归档等步骤。本仓库的 archive/ 目录即存放了已归档的 SIG/WG 文档如 sig-cluster-ops、wg-policy 等印证了这一机制的存在。一个值得注意的对比在 sigs.yaml 中security-self-assessments 仍被列为 sig-security 的子项目含#sig-security-assessments频道而 2025 年度报告显示该子项目在 2025 年又退役并复活Retired and Resurrected。这体现了 Kubernetes 社区子项目治理的动态性——归档不等于永久终止可以根据社区需要重启。九、社区外联KubeCon 演讲与立场选择9.1 2024 年社区级更新年度报告记录了两次社区层面的关键事件KubeCon EU 2024SIG Security 在 KubeCon EU 2024 做了维护者专场演讲maintainer track talk主题为SIG Security Update: Growing Together共同成长KubeCon NA 2024经负责人共识SIG Security未在盐湖城Salt Lake City举办的 KubeCon NA 2024 上设置官方代表原因是犹他州的反跨性别法律anti-transgender laws使该地点对 SIG 领导层及其所关爱的人群不安全。报告表达了失望并期待 2025 年在欧洲与大家相见。这一选择体现了 SIG Security 将社区成员的安全与包容性置于会议曝光之上的价值取向也是年度报告中颇具人文色彩的立场声明。十、运营自查清单年度治理的标准化收尾年度报告末尾的 Operational 部分是一份标准化的运营自查清单所有条目在 2024 年均已勾选完成[x]包括审阅 README.md 并确认/更新其准确性审阅 CONTRIBUTING.md 并确认/更新其准确性审阅其他贡献文档如 devel 目录或贡献者指南审阅 sigs.yaml 中的子项目列表与关联的 OWNERS 文件确认 sigs.yaml 中的 SIG 负责人chairs、tech leads、subproject leads准确且活跃确认 2024 年的会议纪要与会话录制已从 README.md 链接并可访问。从模板理解这份清单的来源对照仓库中的 年度报告生成模板 可以发现这份运营清单并非手工撰写而是由模板自动生成的固定结构。模板中的 KEP 工作部分第 4 节设计为从 kubernetes/enhancements 仓库的 KEP 元数据自动生成 Alpha/Beta/Stable 清单通过getReleases、filterKEPs等 Go 模板函数子项目与工作组部分则由getCategorizedSubprojects、getCategorizedWorkingGroups函数按 New/Retired/Continuing 自动分类。在模板生成流程上generator/README.md 说明所有 SIG 信息的权威来源是仓库根目录的 sigs.yaml 文件任何更新都必须先修改 sigs.yaml再通过make generate或容器化方式make generate-containerized重新生成各 SIG 的 README 文档。这也是 sig-security 的 README.md 顶部标注本文件为自动生成请勿直接编辑应修改 sigs.yaml的原因。年度报告虽然由 SIG 成员撰写正文但其骨架标题、章节、检查项、KEP 清单占位同样遵循模板约定保证了各 SIG 年度报告格式的一致性便于横向对比与自动处理。十一、总结与展望回顾 2024 年度报告SIG Security 呈现出一条清晰的工作主线审计层面启动最新一轮第三方全面安全审计延续项目级安全基线保障文档层面通过 Application Security Checklist 将安全知识下沉到应用开发者群体扩大安全实践覆盖面工具层面接管 cve-feed-osv用 OSV 标准格式提升 CVE 数据的机器可读性与扫描准确性治理层面完成 SecurityContextDeny 的移除与 security-assessments 子项目的归档同时通过新人培养与 shadow lead 机制确保组织活力。对读者而言这份年度报告的价值不仅在于了解2024 年发生了什么更在于透过其结构理解 Kubernetes 社区的安全治理范式以流程型 SIG 统筹横向安全议题、以子项目制分解长期职责、以年度报告 模板 sigs.yaml 实现可审计的治理闭环。对于希望参与 Kubernetes 安全工作的贡献者年度报告也释放了明确信号——security-docs 子项目持续欢迎各经验水平的贡献者是进入 Kubernetes 安全领域的友好入口。如果想继续深入可以进一步阅读SIG Security CharterSIG 的完整职责边界与治理约定sig-security/README.md子项目、负责人与会议信息SIG 治理文档SIG 运营的标准要求年度报告生成模板理解报告结构的自动化来源sigs.yamlSIG 信息的权威数据源。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
