CISA：发布《开源软件安全原则与实践》，给出 OSS 全生命周期风险治理框架

CISA 发布《Open Source Software: Security Principles and Practices》，覆盖 OSS 全生命周期风险治理，引入 C4 信任评估框架，并就漏洞管理、SBOM、安全开发与开源 AI 系统给出具体建议，呼应行政令 EO 14144/14306。

📖 原文翻译与解读。原文：Open Source Software: Security Principles and Practices（CISA，2026-07-09）

一、指南定位

CISA 发布《Open Source Software: Security Principles and Practices》，为联邦机构提供使用、评估与生产开源软件（OSS）的考量与最佳实践，并延伸至开源人工智能（AI）模型的评估。指南呼应行政令 EO 14144（强调 OSS 对联邦机构的收益）与 EO 14306（要求联邦网络更安全地管理 OSS 使用）。Log4Shell、xz-utils 等事件凸显了理解软件内部依赖的必要性——OSS 是几乎每个现代系统与关键基础设施的基础构件。

二、C4 信任评估框架

指南引入 C4 框架用于开源组件的信任评估，帮助机构在采纳前对组件的可信度与自身风险承受度做结构化判断。C4 从多个维度（社区活跃度、维护健康度、历史漏洞响应、供应链完整性等）刻画「这个 OSS 值不值得用、用到什么程度」，使采购与采纳决策从凭感觉转为可审计的流程。

三、关键实践

指南覆盖 OSS 全生命周期的关键实践：漏洞管理——建立成熟且演练过的补丁与披露响应流程；SBOM（软件物料清单）——对所用组件做组成、来源与分发追踪，使漏洞公开时能快速定位受影响资产；安全开发——遵循安全设计（secure-by-design）与 NIST SSDF 等实践，关注第三方组件的嵌入方式。指南还强调建立「审查—批准」流程，在赋能员工使用合适方案的同时管好风险。

四、开源 AI 系统的特殊要求

对开源 AI 系统，指南要求机构在将其视为 OSS 用于风险管理前，必须获得对训练数据、模型权重与相关组件的充分透明度——唯有可访问、可研究，才能分析漏洞并修复。这与供应链安全一脉相承：缺乏透明度的「开源」AI 无法被真正审计。邮件与协作系统厂商在采用 OSS 组件或开源模型时，应将 C4 评估、SBOM 与漏洞披露响应纳入供应商与自研治理。参见 SANDWORM_MODE：AI 工具链供应链攻击。

参考来源

  1. CISA：Open Source Software Security Principles and Practices
  2. CISA 新闻：指南帮助联邦机构安全有效使用 OSS

了解更多行业资讯，请访问 行业资讯首页 或致电 021-69753778 获取安全咨询服务。

相关文章


—— ztpop.net 编辑团队 译