开源软件成为企业安全的“双刃剑”
近期，美国网络安全与基础设施安全局（CISA）发布了《开源软件：安全原则与实践》指南。在数字化转型背景下，开源软件（OSS）因其透明度高、成本低及灵活性强等优势，已成为现代企业软件架构的基石。然而，从我们的应急响应经验来看，开源组件的广泛应用也为供应链攻击打开了方便之门。许多企业在享受开源红利的同时，往往忽视了对其全生命周期的管控，导致系统暴露在未知的漏洞风险之中。
全生命周期的安全治理思维
CISA在指南中强调，开源软件应被视为企业核心资产的一部分，而非“外来品”。这意味着企业不能仅在引入时做一次性评估，而需建立常态化的监控机制。
这一环节是很多企业容易忽视的。很多组织在开发初期引入开源组件后，便将其置于“黑盒”状态，缺乏有效的版本审计。我们建议企业采取以下策略：首先，必须建立详尽的开源组件清单，这是安全治理的前提；其次，应优先选择有活跃维护社区的项目，并定期评估其可信度。当项目出现生命周期结束（EOL）或长期未修复的关键漏洞时，必须果断采取替换策略。
SBOM：供应链透明度的关键钥匙
针对开源软件的依赖管理，CISA特别推崇使用软件物料清单（SBOM）。在Solar处理的多次供应链溯源案件中，我们发现攻击者往往利用深层次的依赖库漏洞进行“隐蔽渗透”。
SBOM的作用在于，当全球范围内爆发如Log4j级别的重大漏洞时，企业能通过清单快速定位受影响的组件，从而将应急响应时间从“天”缩短至“小时”。此外，自动化工具在依赖管理和补丁部署中的应用已成必然，企业应尽可能实现补丁管理的自动化，以应对日益复杂的威胁环境。
关于开源贡献与安全红线
CISA鼓励政府机构参与开源社区并反哺代码，这对于提升整体行业安全水平具有积极意义。但作为安全专家，我们必须提醒：在贡献代码前，务必进行严格的敏感信息审查。
从以往的应急响应案例来看，开发者因失误在代码或配置文件中泄露API密钥、加密凭证或内部网络拓扑的情况屡见不鲜。企业应建立自动化的代码扫描流程，在提交前拦截潜在的敏感信息泄露，确保开源贡献过程不会成为内部机密的“泄洪口”。
警惕开源AI系统的“透明度陷阱”
此次指南中一个值得关注的重点是对“开源AI系统”的评估建议。CISA指出，开源AI系统与传统开源软件有本质区别——即便模型代码开源，若其训练数据不可见，企业也难以评估其是否存在数据投毒或逻辑缺陷。
对于此类系统，建议企业采取“零信任”评估策略。如果无法获得训练数据和完整开发过程的可见性，应将其视为具有不完整来源的专有软件，并实施比普通开源软件更为严苛的风险管控措施。
Solar安全专家建议
开源安全不是一次性的任务，而是一场持久战。针对当前的安全形势，我们建议企业：
第一，构建闭环的资产管理，确保所有开源组件“可见、可控、可追溯”； 第二，将安全左移，在开发阶段引入SBOM扫描，降低后期修复成本； 第三，建立完善的漏洞披露与应急响应机制，确保在威胁发生时能够迅速响应。
类似攻击近年来明显增加，企业必须从单纯的“使用开源”转向“治理开源”。如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816 官网：www.solarsecurity.cn / www.sierting.com