杜绝XZ后门！OWASP发布十大开源软件安全风险清单

近年来开源软件安全风险快速增长
，杜绝不久前曝光的后门XZ后门更是被称为“核弹级”的开源软件供应链漏洞。虽然XZ后门事件侥幸未酿成灾难性后果，发风险但为全球科技界敲响了警钟
：当今数字生态系统极其脆弱，开源亟需改进开源软件的软件使用和安全管控方式。

传统的安全漏洞管理侧重于已知漏洞，例如常见漏洞和披露列表(CVE)中的清单漏洞。然而，杜绝业界逐渐意识到
，后门已知漏洞是发风险滞后的服务器租用风险指标。

开放式Web应用安全项目(OWASP)指出，开源为了更安全地使用开源软件，软件人们需要转变思维方式，安全更加关注风险的清单前瞻性指标。这些指标可以帮助我们识别特定开源软件库、杜绝组件和项目存在的潜在风险 ，并通过综合考量这些风险，制定更安全的开源软件使用策略，降低漏洞被利用的可能性。

为应对包括XZ后门事件在内的诸多新兴开源软件安全风险  ，模板下载帮助用户更安全地使用和管理开源软件
，近日，OWASP发布了“十大开源软件风险”TOP10清单 ，并针对每种风险给出了安全建议 ，具体如下：

一、已知漏洞

此类风险指存在已知漏洞的开源软件组件，这些漏洞通常是由软件开发人员和维护人员在开发过程中无意引入，并随后由安全研究人员公开披露。

已知漏洞的可利用性取决于其在企业应用程序中的利用场景。虽然看似简单，但现实情况是，香港云服务器如果不向开发人员提供漏洞利用场景等信息
，将导致大量无意义的安全告警 ，从而增加开发人员的工作量，浪费时间并引发挫败感。

为了降低已知漏洞风险，企业可采取多种措施 ，例如  ：扫描所使用的开源软件组件查找漏洞;根据漏洞的可利用性、利用可能性、可达性分析(可将误报率降低80%以上)等因素
，对扫描结果进行优先级排序 。

此外  ，业界还开发了一系列平台方案提高已知漏洞的亿华云管理效率 ，例如CISA的已知被利用的漏洞(KEV)目录和利用预测评分系统(EPSS) 。

二
、合法软件包被入侵

攻击者已经认识到劫持合法开源软件包的巨大价值和杀伤力，通过这种方式可大面积影响下游软件用户(包括个人和企业)。

攻击者可以采用多种方法实施此类攻击，例如劫持开源项目维护人员的账户，或利用开源软件包仓库中的漏洞 。

他们还可以伪装成维护人员加入项目
，伺机植入恶意代码。例如，高防服务器最近的XZ后门事件正是如此，攻击者伪装成合法贡献者，经过长时间潜伏后在代码中植入后门 。

为了降低此类风险 ，企业可以参考微软发布的(现已捐赠给OpenSSF)安全供应链消费框架(S2C2F)等资源和指导方针(业界还有其他一些类似的框架)。

三、名称混淆攻击

在名称混淆攻击中，攻击者创建恶意组件，其名称与合法的开源软件包或组件相似
，希望受害者在不知情的情况下下载并使用这些恶意组件。免费模板此类攻击手法也出现在CNCF软件供应链攻击目录中，包括typosquatting(域名typosquatting)和brand-jacking(品牌劫持)等。

一旦这些被入侵的软件包被引入企业的IT环境 ，就会危及系统和数据的机密性
、完整性和可用性(CIA) 。

四 
、缺少维护

与专有软件不同 ，开源软件面临的一个严峻现实是没有“供应商”对代码安全负责。开源软件主要依靠无偿的志愿者进行维护 ，以“as is”(按原样)的方式提供软件  ，这意味着一些软件组件可能长期缺少积极的开发和维护，漏洞修复工作也可能无法及时完成 。(即使能够完成
，也可能无法满足软件用户对组件更新时间线的需求，也无法提供类似专有软件供应商的服务水平协议SLA承诺)

Synopsys发布的开源软件报告指出 ，在所评估的开源代码库中
，85%使用了距今超过四年且过去两年没有更新的开源软件组件。

考虑到软件更新换代速度飞快 ，根据美国国家漏洞数据库(NVD)的年度数据 ，新的漏洞正以创纪录的速度出现 ，这对于经常使用未及时更新的开源软件组件的现代应用程序来说，风险正不断累积。

造成开源软件维护风险另一大原因是贡献者和维护者太少。约25%的开源项目只有一个开发人员贡献代码 ，94%的项目由10名或更少的开发人员维护，正如研究人员ChinmayiSharma在其著作《数字公共产品的悲剧》中所指出的那样。对于那些希望全面了解挑战的人来说
 ，这是一本值得推荐的读物
。

维护者过少的风险也被成为“公交车司机因素”，如果一个项目只有一个主要维护者  ，风险显而易见。即如果掌舵项目的某个关键人物突然去世或离开项目，会造成什么可怕影响?

60-80%的现代代码库由开源软件组成，我们的数字生态系统中很大一部分
，甚至是最关键的系统 ，都运行在缺乏维护和支持的开源软件上，这构成了重大且亟待解决的系统性风险。

OWASP建议采取以下措施来降低此类风险 ：检查项目的活跃度和健康状况，例如维护者和贡献者的数量、发布频率和漏洞修复的平均时间(MTTR)。

五、组件/依赖项过时

开源软件的另一个风险是使用过时的组件版本(尽管这些组件可能存在更新的版本)。Synopsys的报告指出，这种情况实际上很普遍，发生在绝大多数代码库和存储库中。

今天，情况变得更加复杂，因为许多现代软件应用程序和项目都存在错综复杂且令人眼花缭乱的依赖关系  。Sonatype和Endor Labs发布报告也强调了这个问题。后者发布了“依赖管理现状”报告 ，显示95%的漏洞与传递依赖项有关。

六
、未跟踪依赖项

这种情况是指开发人员/企业根本没有意识到他们使用了特定的依赖项或组件。这可能是由于企业没有使用软件成分分析(SCA)等工具来了解其开源软件的成分和使用情况 ，或者没有使用软件物料清单(SBOM)等工具提高对所使用或分发的软件组件的可视性。

未跟踪依赖项风险正推动SBOM和软件供应链安全工具快速发展，正如业界通过SolarWinds和Log4j等事件所认识到的那样，SBOM能帮助企业掌握其组件库存 ，缓解相关风险。但是 ，尽管SBOM多年来一直是SANS/CIS的关键控制措施 ，但大多数企业仍然缺乏对组件/库级别的全面软件资产清单。

七
、许可和监管风险

开源许可证监管风险是指开源组件或项目可能缺少许可证 ，或者许可证可能妨碍下游用户的使用 。

OWASP指出，企业需要确保其使用的开源软件组件符合其适用许可条款 ，否则可能会导致许可或版权侵权，甚至导致法律诉讼。

随着越来越多的企业在其专有产品、服务和产品中更广泛地使用开源软件组件，开源许可证风险还可能会影响企业的业务目标 、并购活动等 。

企业可以通过以下措施来降低这些风险：识别其软件中使用的组件的适用许可证及其预期用途 。OWASP建议企业避免使用完全没有许可证的开源组件，并识别具有多个或冲突许可证的组件。

八、成熟度低

并非所有软件都是生而平等的，成熟度方面也存在差异
，部分原因是维护人员参与程度不同。

一些开源项目可能没有应用安全的软件开发实践(例如NIST安全软件开发框架SSDF)。具体示例可能包括缺乏文档、缺乏回归测试、缺乏审查指南以及许多其他最佳实践 。

还有一个令人不安的现实是，许多开发人员对安全不感兴趣 。Linux Foundation和哈佛大学创新科学实验室(LISH)的研究证实了这一点，他们发现开源软件开发人员只有2.3%的时间用于提高其代码的安全性。

业界正在努力提升开源软件的安全成熟度
，并提供了相关工具
，例如OpenSSF的Scorecard ，它为Github上的开源项目提供了一套强大的检查标准，例如分支保护的存在、贡献者/组织数量、CI测试、模糊测试、维护
、许可等 。另一个类似的标准是CISA和OpenSSF提出的“软件包存储库安全原则”。

九、未经批准的更改

OWASP将“未经批准的更改”定义为 ：组件在开发人员没有注意到 、审查或批准更改的情况下发生更改的情况。当下载链接发生更改或指向无版本控制的资源，甚至是被篡改的不安全数据传输时 ，可能会发生这种情况，这凸显了安全传输的作用。

建议的操作和缓解措施包括 ：使用资源标识符确保一致性并指向相同的不可变工件。用户还可以在实际安装和使用组件之前验证组件的签名和摘要。此外
 ，为了降低组件在传输过程中被篡改的风险，应使用安全传输协议。

十、代码膨胀和代码不足

最后，还有一类开源软件风险是“代码过于臃肿或简陋”。一些开源组件提供的功能太少
 ，有些则太多 ，而实际只使用了其中一部分。这通常被称为“代码膨胀”
。

在代码不足的依赖项案例中，由于代码量太少 ，组件变得更加依赖于上游项目的安全。另一方面，如果用户遇到代码膨胀或指数级代码行数，最终会带来更大的攻击面和潜在的可利用代码/依赖项，尽管这些代码/依赖项实际上不需要或未使用 。

OWASP建议在这种情况下，尽可能在内部重新开发所需的功能，以降低依赖体积过大或过小的风险  。在云原生容器化环境中 
，安全基础镜像正被积极推广 ，例如Chainguard等领导者所倡导的，这些镜像是经过最小化加固的基础镜像 ，漏洞数量极少甚至为零 。