《奇安信：2024中国软件供应链安全分析报告（56页）.pdf》由会员分享，可在线阅读，更多相关《奇安信：2024中国软件供应链安全分析报告（56页）.pdf（56页珍藏版）》请在本站上搜索。 1、II目录一、概述.1一、概述.11、软件供应链安全攻击手段依然花样百出.12、国内企业软件供应链安全状况有所改善.4二、国内企业自主开发源代码安全状况.6二、国内企业自主开发源代码安全状况.61、编程语言分布情况.62、典型安全缺陷检出情况.7三、开源软件生态发展与安全状况.8三、开源软件生态发展与安全状况.81、开源软件生态发展状况分析.92、开源软件源代码安全状况分析.11（1）编程语言分布情况.11（2）典型安全缺陷检出情况.123、开源软件公开报告漏洞状况分析.13（1）大型开源项目漏洞总数及年度增长 TOP20.13（2）主流开源软件包生态系统漏洞总数及年度增长 TOP20.164、2、开源软件活跃度状况分析.19（1）68.7%的开源软件项目处于不活跃状态，比例下降.19II（2）版本频繁更新的项目较去年增长 21.6%.205、关键基础开源软件分析.21（1）主流开源生态关键基础开源软件 TOP50.21（2）关键基础开源软件的漏洞披露情况未见改善.24（3）关键基础开源软件的整体运维风险有所改观.256、NPM 生态中恶意开源软件分析.26（1）超 95%的恶意开源组件以窃取敏感信息为目标.26（2）典型恶意开源组件及恶意行为剖析.27四、国内企业软件开发中开源软件应用状况.29四、国内企业软件开发中开源软件应用状况.291、开源软件总体使用情况分析.30（1）平均每个3、软件项目使用 166 个开源软件，再创新高.30（2）最流行的开源软件被 37.2%的软件项目使用.312、开源软件漏洞风险分析.32（1）存在容易利用的开源软件漏洞的项目占比大幅下降.32（2）平均每个项目包含的已知开源软件漏洞数明显回落.33（3）影响最广的开源软件漏洞的影响范围有所减小.35（4）20 多年前的开源软件漏洞仍然存在于多个软件项目中.363、开源软件许可协议风险分析.37（1）最流行的开源许可协议在 46.9%的项目中使用.37III（2）超 1/5 的项目使用了含有超、高危许可协议的开源软件.384、开源软件运维风险分析.40（1）多个二三十年前的老旧开源软件版本仍在使用4、.40（2）开源软件各版本使用依然混乱.41五、典型软件供应链安全风险实例分析.42五、典型软件供应链安全风险实例分析.421、多款主流操作系统供应链攻击实例分析.422、PHP 软件供应链攻击实例分析.433、某国产数据库供应链攻击实例分析.45六、总结及建议.47附录：奇安信代码安全实验室简介.51六、总结及建议.47附录：奇安信代码安全实验室简介.511一、概述一、概述当前，软件供应链安全依然是网络安全中备受关注的方向，基于自研产品的技术能力和第一手实测数据，奇安信代码安全实验室继续推出2024 中国软件供应链安全分析报告，即本系列年度分析报告的第四期。软件由自主开发的代码与开源代码等第5、三方代码集成后，形成混源代码，然后通过编译、连接等构建过程形成软件产品，交付给用户使用。在这一软件供应链模型中，每个阶段中的代码或工件都可能引入安全问题，从而导致最终软件供应链安全事件的爆发。本期报告仍以此模型为基础，分析各阶段的代码安全问题对软件供应链安全性的潜在威胁，分析内容分别在后续的国内企业自主开发的源代码安全状况、开源软件生态发展与安全状况、国内企业软件开发中开源软件应用状况、典型软件供应链安全风险实例分析等章节中呈现。在此基础上，本报告还总结了趋势和变化。与往年报告相比，本期报告在开源软件生态发展与安全部分新增了对 NPM 生态中恶意开源软件分析的内容；在典型软件供应链安全风险实例6、部分，通过实例再次验证了因软件供应链的复杂性，“外来”组件的“老漏洞”发挥“0day 漏洞”攻击作用的状况。感兴趣的读者可重点关注。1、软件供应链安全攻击手段依然花样百出1、软件供应链安全攻击手段依然花样百出过去的一年中，软件供应链安全攻击事件没有丝毫减少的趋势，2攻击手段依然花样百出。2023 年 10 月，安全人员分析发现了一种新型供应链攻击。整个9 月，某黑客组织都在使用域名仿冒（Typosquatting）和星标劫持（Starjacking）技术向开源包管理器 PyPi 植入一系列恶意包，并引诱开发人员使用，而这些恶意包与 Telegram、AWS 和阿里云等热门通信和电子商务平台所使7、用的流行软件包高度对应，被认为是故意攻击这些平台的特定用户。攻击者可以攻陷平台用户设备，窃取金融和个人信息、登录凭据等敏感数据，可能影响数百万人。2023 年 12 月，AI 安全公司 Lasso Security 的研究人员，在 GitHub和 Hugging Face 平台上发现了 1500 多个不安全的 API 访问令牌，可用来访问 772 个组织机构的仓库，包括谷歌、微软、VMware 等公司。其中部分令牌可帮助攻击者获得 Meta 公司 Bloom、Meta-Liama、Pythia 等大语言模型（LLM）仓库的完全读写权限，攻击者可利用该漏洞实施 LLM 训练数据投毒、模型和数据集8、窃取等恶意行为，从而将使用这些仓库把 LLM 能力集成到应用和运营中的组织置于供应链风险中，危及数百万下游用户的安全。2024 年 2 月，Cycode 研究团队披露了谷歌重要的开源构建和测试工具 Bazel 的一个供应链安全漏洞的详细信息。Bazel 所依赖的CICD 平台 GitHub Actions 的工作流程中存在命令注入漏洞，可导致攻击者将恶意代码植入 Bazel 代码库、创建后门并影响 Bazel 用户的生产环境。该漏洞可能影响数百万个依赖于 Bazel 的项目和平台，包括 Kubernetes、Angular、Uber、LinkedIn、Dababricks、Dropbox、Nv9、idia3和谷歌自身等。2024 年 3 月初，安全研究人员发现，机器人平台 Top.gg Discord托管在 GitHub 上的源代码遭受到大规模严重供应链投毒攻击，该平台拥有超 17 万成员。分析发现，攻击者劫持了 Top.gg 的 GitHub 账户，上传了至少 14 个伪造的恶意 Python 流行软件包，并通过这些恶意软件窃取用户 Chrome、Edge 等浏览器中的敏感数据，包括浏览历史记录、信用卡详细信息等，并通过出售信息实现盈利。攻击者还试图窃取 Telegram 会话数据以侵犯用户隐私。这些攻击同时也影响到了大量与平台相关的开发人员。2024 年 3 月底，某开发人员在调查10、 SSH 性能问题时发现了涉及XZ Util工具库的供应链攻击，溯源发现 SSH 使用的上游 liblzma 库被植入了恶意后门漏洞（CVE-2024-3094），满足一定条件时会解密流量里的 C2 命令并执行，从而使攻击者能够破坏 SSHD 身份验证并远程获得对整个系统的未经授权访问。XZ 是一种由 Tukaani 项目开发的高压缩比数据压缩格式，几乎应用于每个 Linux 发行版中，包括社区项目和商业产品发行版，liblzma 是一个用于处理 XZ 压缩格式的开源软件库。庆幸的是，该漏洞主要影响的 XZ 5.6.0 和 5.6.1 版本尚未被Linux 发行版广泛集成，而且大部分是在预发行11、版本中。2024 年 5 月，攻击者通过与英国国防部核心网络链接的一个外部系统，即由英国国防部的一家提供薪资处理服务的外部承包商维护的薪资处理系统，访问了部分军队支付网络，造成严重的信息泄露。据统计，攻击者访问了超过 22.5 万名英国陆军、海军和皇家空军现4役军人、退役军人和预备役军人的姓名、银行账号详情等个人信息。第三方承包商未能充分的保护系统是这次事件的主要诱因，而这一事件是在不到一年的时间内发生的第二起因外部承包商而导致的英国军队数据遭泄露事件。OpenSSH 可以在 CS 架构中提供网络安全信道，被众多企业用于远程服务器管理和数据安全通信。2024 年 7 月初，网络安全公司Qual12、ys 发 现，OpenSSH 服 务 器 进 程 存 在“regreSSHion”漏 洞（CVE-2024-6387），攻击者可利用其以 root 权限在基于 glibc 的Linux 系统上实现未认证的远程代码执行，从而实施系统完全接管、恶意程序安装和后门创建等攻击行为，严重程度堪比 Log4Shell。具不完全统计，互联网上有 1400 多万台易受攻击的 OpenSSH 实例，仅Qualys 公司自身的客户中就有约 70 万个暴露在互联网上的系统可能易受攻击。2、国内企业软件供应链安全状况有所改善2、国内企业软件供应链安全状况有所改善奇安信代码安全实验室通过数据分析发现，与以往历年相比，213、023 年，国内企业自主开发软件的源代码高危缺陷密度明显下降，并且因使用开源软件而引入安全风险的状况有所改善。尽管如此，软件供应链安全风险的管控依然值得持续关注，需要更多的投入。1）国内企业自主开发软件的源代码高危缺陷密度明显下降1）国内企业自主开发软件的源代码高危缺陷密度明显下降通过对 2023 年国内企业自主开发源代码的分析发现，虽然整体缺陷密度达到 12.76 个/千行，高于以往各年，但高危缺陷的密度为50.52 个/千行，比之前三年有明显的下降；此外，NULL 引用类缺陷的检出率为 25.7%，较往年也有较大降低。上述趋势的出现，应该在很大程度上得益于以下措施的采取：软件开发过程中，研14、发企业对重点缺陷逐渐重视，针对重点问题的安全编码规范进一步普及，并且代码审计工具的使用持续推广。2）国内企业因使用开源软件而引入安全风险的状况有所改善2）国内企业因使用开源软件而引入安全风险的状况有所改善2023 年，奇安信代码安全实验室对 1763 个国内企业软件项目中使用开源软件的情况进行分析发现，平均每个项目使用了 166 个开源软件，数量再创新高。但另一方面，平均每个项目存在 83 个已知开源软件漏洞，含有容易利用的开源软件漏洞的项目占比为 68.1%，以上两项指标与去年相比降幅较大；此外，存在已知开源软件漏洞、高危漏洞、超危漏洞的项目占比分别为 88.0%、81.0%和 71.9%，15、与去年相比均有所下降。其他方面，如项目中存在古老开源软件漏洞、老旧开源软件版本使用、同一开源软件各版本使用混乱等方面的状况基本与之前历年持平。总体而言，国内企业使用开源软件的安全状况有所好转。虽然从趋势来看，上述的软件供应链安全问题有一定程度的缓解，但另一方面，这些指标数据仍处于高位，软件供应链的安全问题并没有得到根本性的改变。值得高兴的是，越来越多的机构和企业开始关注并实施软件供应链的安全，一些机构和企业基于规范的流程和实践，落地了相应的解决方案和检测平台。但就目前的形势而言，这些经验、方法和工具还需要进一步的持续完善、推广和应用。6二、国内企业自主开发源代码安全状况二、国内企业自主开发源代16、码安全状况源代码的安全是软件供应链安全的基础。2023 年全年，奇安信代码安全实验室对 1858 个国内企业自主开发的软件项目的源代码进行了安全缺陷检测，检测的代码总量为 408909802 行，共发现安全缺陷 5216473 个，其中高危缺陷 211355 个，整体缺陷密度为 12.76 个/千行，高危缺陷密度为 0.52 个/千行。与以往历年相比，整体缺陷密度升高较快，但高危缺陷密度有较大幅度的降低。这应该与开发者对高危缺陷类型的重点防范及相应安全编码规范的使用有关。1、编程语言分布情况1、编程语言分布情况在 1858 个国内企业自主开发的软件项目中，共使用了 17 种编程语言，使用项目数17、排名前 3 的分别为 Java、C/C+和 Python，对应的软件项目数量分别为 1258 个、246 个和 118 个，Python 取代 NodeJS7再次回到第三的位置。Java 语言项目占比达 67.7%，但低于去年的76.1%。国内企业在进行软件开发时，Java 语言仍然最受欢迎。编程语言的分布情况如下图所示。2、典型安全缺陷检出情况2、典型安全缺陷检出情况对 1858 个软件项目的源代码缺陷检测结果进行分析和统计发现，注入、密码管理、日志伪造、跨站脚本、NULL 引用、配置管理、输入验证、资源管理、路径遍历、API 误用等十类典型安全缺陷的总体检出率（即含有某类缺陷的软件项目数占18、项目总数的比例）为 71.1%，与去年的 74.1%基本持平。每类典型缺陷历年的检出率及对比情况如下图所示。8可以看出，输入验证类和跨站脚本类缺陷的检出率较高，依然排在前两位，特别是输入验证类缺陷，检出率依旧高达 49%；同时，配置管理类和日志伪造类缺陷的检出率依然排在最后两位；与过去历年相比，NULL 引用类缺陷的检出率有较大下降，这可能与研发人员对此类问题的特别关注有关；其他类型缺陷的检出率在正常的波动范围内。国内企业在自主开发软件时，应继续关注针对这些缺陷类型的代码修复问题。三、开源软件生态发展与安全状况三、开源软件生态发展与安全状况开源软件在现代软件开发中持续发挥着基础支持的作用。本期19、报告除了延续开源软件生态发展状况、开源软件源代码安全状况、开源软件公开报告漏洞状况、开源软件活跃度状况、关键基础开源软件分析五部分内容外，在对 2023 年开源软件生态发展与安全状况进行综合分析时，还增加了针对 NPM 生态中恶意开源软件的分析。91、开源软件生态发展状况分析1、开源软件生态发展状况分析根据奇安信代码安全实验室的监测和统计，2022 年底和 2023 年底，主流开源软件包生态系统中开源项目总量分别为 5499977 和7959049，一年间增长了 44.7%，增速迅猛；截至 2023 年底，主流开源软件包生态系统中平均每个开源项目有 11.3 个版本，与前几年基本持平。202320、 年开源软件生态持续繁荣。对 Maven、NPM、Packagist、Pypi、Godoc、Nuget、Rubygems、Swift 等八个典型开源软件包生态系统的具体分析如下：NPM 包生态开源项目数量和增速均位列第一。NPM 包生态开源项目数量和增速均位列第一。与前三年相比，NPM超越 Godoc，成为开源项目数增速最快的包生态系统。八个典型的开源软件包生态系统中开源项目数量和增长率情况如下图所示，其中开源项目数量最多的是 NPM 包生态系统，截至 2023 年底，其开源项目数量达到了 4170641，依然远高于其他生态；开源项目数量增速最快的也是 NPM，2023 年一年间的项目总量增速21、高达 79.1%，Godoc 的项目数增长也很快，达 58.1%。10Maven 包生态系统的开源项目开发者依然“最勤奋”，开源项目的平均版本数超过 23 个。Maven 包生态系统的开源项目开发者依然“最勤奋”，开源项目的平均版本数超过 23 个。截至 2023 年底，八个典型的开源软件包生态系统的开源项目数量和版本数量如下表所示。其中，Maven 包生态系统平均每个开源项目有高达 23.6 个版本，比去年的 21.9 又有增加；NPM 和 Godoc 的开源项目平均版本数有所降低，分别从 13.4 和 9.4 降至 10.2 和 8.8。序号包生态系统2023 年项目数2023 年版本数平22、均版本数1Maven7272281719158223.62NPM41706414269280610.23Packagist421935538080912.84Pypi536523554033010.35Godoc80906171078328.86Nuget640966809115112.67Rubygems17869314236318.08Swift948866665247.0112、开源软件源代码安全状况分析2、开源软件源代码安全状况分析2023 年全年,“奇安信开源项目检测计划”对 2248 个开源软件项目的源代码进行了安全检测，代码总量为 309522947 行，共发现安全缺陷 510823、161 个，其中高危缺陷 355721 个，整体缺陷密度为 16.50个/千行，高危缺陷密度为 1.15 个/千行。两项缺陷密度指标较去年均有所下降。（1）编程语言分布情况（1）编程语言分布情况2023 年检测的 2248 个开源项目中，共涉及 10 种编程语言，分别是 Java、C/C+、JavaScript、Python、Groovy、C#、Lua、Kotlin、Ruby 和 Go，编程语言的分布情况如下图所示。被测项目中，使用 Java、C/C+、JavaScript 和 Python 四种语言开发的开源软件约占 3/4。12（2）典型安全缺陷检出情况（2）典型安全缺陷检出情况对 22424、8 个开源软件项目的缺陷检测结果分析发现，注入、密码管理、日志伪造、跨站脚本、NULL 引用、配置管理、输入验证、资源管理、路径遍历、API 误用等十类典型安全缺陷的总体检出率为76.7%，与前两年相比，有小幅升高。每类典型缺陷历年的检出率及对比情况如下图所示。13可以看出，除了密码管理类缺陷的检出率较往年，特别是去年有较大幅度的提升外，其他均在正常的波动范围内。从历年数据来看，输入验证、路径遍历和资源管理三类缺陷的检出率较高，均在 30%左右或以上；日志伪造、跨站脚本和配置管理三类缺陷检出率较低，均在 20%左右或以下。3、开源软件公开报告漏洞状况分析3、开源软件公开报告漏洞状况分析根据奇安25、信代码安全实验室监测与统计，截至 2023 年底，CVE/NVD、CNNVD、CNVD 等公开漏洞库中共收录开源软件相关漏洞 64938 个，其中有 7107 个漏洞为 2023 年新增。（1）大型开源项目漏洞总数及年度增长 TOP20（1）大型开源项目漏洞总数及年度增长 TOP20截至 2023 年底，历史漏洞总数排名前 20 的大型开源项目信息如下表所示。Linux Kernel、Chromium(Google Chrome)和 Mozilla Firefox14一如既往，依然排名前 3。序号大型开源项目主页地址历史漏洞总数1Linux Kernelhttps:/www.kernel.or26、g/59832Chromium(Google Chrome)http:/www.chromium.org/33693Mozilla Firefoxhttps:/www.mozilla.org/en-US/firefox/26374Thunderbirdhttps:/ ESRhttps:/www.mozilla.org/en-US/firefox/enterprise/109710Adobe Flash Playerpluginhttps:/ 年一年间，公开报告漏洞数量增长排名前 20 的大型开源项目信息如下表所示，Linux Kernel 依然是一年来增加漏洞最多的项目，达到 607 个。序号27、大型开源项目主页地址2023年漏洞增量1Linux Kernelhttps:/www.kernel.org/6072Chromium(GoogleChrome)http:/www.chromium.org/2753Mozilla Firefoxhttps:/www.mozilla.org/en-US/firefox/1864GitLabhttps:/ ESRhttps:/www.mozilla.org/en-US/firefox/enterprise/1209Thunderbirdhttps:/ shell5819pimcorehttp:/ TOP20（2）主流开源软件包生态系统漏洞总数及年度28、增长 TOP20截至 2023 年底，主流开源软件包生态系统中历史漏洞总数排名前 20 的开源软件信息如下表所示。排名前两位的依然是 TensorFlow和 Chakra Core。序号开源软件所属包生态系统历史漏洞总数1TensorFlowPypi4302Chakra CoreNuget347173Electron-Cross-platformdesktop application shellNPM3144Electron-Cross-platformdesktop application shellMaven2525JenkinsMaven2466Apache TomcatMaven20029、7XWikiMaven1698TYPO3 CMSPackagist1639OpenSSLConan15910Ruby on RailsRuby12811Magento CorePackagist12212FFmpeg-iOSSwift12113phpMyAdminPackagist12014OpenSSLSwift11315DjangoPypi10716Dolibarr ERP&CRMPackagist10617keycloakMaven10218Drupal(core)Packagist9819phpMyFAQPackagist9420PlonePypi932023 年一年间，主流开源软件包30、生态系统中公开报告漏洞数量增长排名前 20 的开源软件信息如下表所示。18序号开源软件所属包生态系统2023 年漏洞增量1XWikiMaven1112MattermostGodoc693phpMyFAQPackagist624Electron-Cross-platformdesktop application shellNPM585pimcorePackagist576jfinalMaven297incubator-airflowPypi288Go programming languageGodoc289.NET RuntimeNuget2710libTIFFConan2311mlflowCo31、nda2212Electron-Cross-platformdesktop application shellMaven2213mlflowPypi2214XWiki PlatformMaven2215TensorFlowPypi2116keycloakMaven1817JenkinsMaven1718PrestaShopPackagist161919cryptographyConda1520aheinze/cockpitPackagist154、开源软件活跃度状况分析4、开源软件活跃度状况分析本年度报告依然把活跃度作为衡量开源软件安全性的一个维度。太过活跃的开源软件，其版本更新发布频率过高，32、会增加使用者运维的成本和安全风险；不活跃的开源软件，一旦出现安全漏洞，难以得到及时的修复。因此，两者都会给运维带来一些风险。（1）68.7%的开源软件项目处于不活跃状态，比例下降（1）68.7%的开源软件项目处于不活跃状态，比例下降报告中依然将超过一年未更新发布版本的开源软件项目定义为不活跃项目。2023 年全年，主流开源软件包生态系统中不活跃的开源软件项目数量为 5469685 个，占比为 68.7%，低于去年的 72.1%，与前年的 69.9%基本持平。对八个典型的开源软件包生态系统进行分析和比较发现，NPM 从去年的 72.7%大幅度下降为 60.4%，Nuget 从去年的 54.3%迅33、速上升至79.0%。除此之外，其他包生态系统中不活跃项目的占比均与去年持平。NPM 的不活跃项目数量依然最多，达 2520717 个，Rubygems 的不活跃项目占比依然最高，达 90.7%。具体数据见下表。序号包生态系统项目总数不活跃项目数不活跃项目比例1Maven72722850436269.4%2NPM4170641252071760.4%203Packagist42193532291576.5%4Pypi53652335848866.8%5Godoc80906160926475.3%6Nuget64096650621379.0%7Rubygems17869316214490.7%8S34、wift948868375588.3%（2）版本频繁更新的项目较去年增长 21.6%（2）版本频繁更新的项目较去年增长 21.6%2023 年全年，主流开源软件包生态系统中，更新发布 100 个以上版本的开源项目有 27234 个，较去年增长 21.6%。八个典型的开源软件包生态系统中，一年内更新发布超过 100 个版本的项目数量见下表。排名包生态系统对应的开发语言一年内发布超过 100 个版本的项目数量1NPMJavascript162292MavenJava31923Nuget.NET27464GodocGo21565PypiPython14956PackagistPHP9527Rubyg35、emsRuby2758SwiftSwift18215、关键基础开源软件分析5、关键基础开源软件分析一般而言，如果开源软件出现漏洞后，造成的放大效应越大，影响范围越广，那么这个软件就应当越重要。因此，本期报告继续分析“关键基础开源软件”（被多于 1000 个其他开源软件直接依赖的一类开源软件）的安全状况。这类开源软件一旦出现漏洞，影响范围巨大且消除困难，其安全性应得到更多关注。Apache Log4j2 就是一款关键基础开源软件，截止 2023 年底，其直接依赖数为 7919。（1）主流开源生态关键基础开源软件 TOP50（1）主流开源生态关键基础开源软件 TOP50分析发现，截止 2023 年36、底，Maven、NPM、Nuget、Pypi、Packagist、Rubygems 等主流开源生态中的关键基础开源软件共有 1709 款，较2022 年底上涨 36.3%，直接依赖数排名 TOP50 的软件如下表所示。开源软件junit:junit的直接依赖数已连续三年位居榜首。ApacheLog4j2 仅排在第 139 名，未进入 TOP50，也就是说，如果 TOP50 表中的任何一款开源软件曝出严重漏洞，其影响都可能会大过“Log4Shell”漏洞。排名开源软件所属包生态系统直接依赖数1junit:junitMaven997642rakeRubygems812123org.scala-la37、ng:scala-libraryMaven758934bundlerRubygems70327225tiktokapi-srcNPM640216tiktok-srcNPM634567Newtonsoft.JsonNuget629808tslibNPM614269rspecRubygems6058910numpyPypi5948011requestsPypi5664012org.slf4j:slf4j-apiMaven5549613chalkNPM4472014commanderNPM4233715lodashNPM4147116pandasPypi3989417org.jetbrains.ko38、tlin:kotlin-stdlibMaven3883818illuminate/supportPackagist3776919pytestPypi3671720guzzlehttp/guzzlePackagist3538221org.jetbrains.kotlin:kotlin-stdlib-commonMaven3450722axiosNPM3413823expressNPM3349424reactNPM304752325inquirerNPM2890126com.google.guava:guavaMaven2729327ch.qos.logback:logback-classicMa39、ven2709628matplotlibPypi2650129requestNPM2583130org.jetbrains.kotlin:kotlin-stdlib-jdk8Maven2582631org.mockito:mockito-coreMaven2439732fs-extraNPM2413333scipyPypi2399434com.fasterxml.jackson.core:jackson-databindMmons:commons-lang3Maven2181736typescriptNPM2093937commons-io:commons-ioMaven2084938reac40、t-domNPM2031439org.projectlombok:lombokMaven2030640laravel/frameworkPackagist1867041org.clojure:clojureMaven1806442clickPypi1798743tqdmPypi172022444pytest-covPypi1654345momentNPM1579646com.google.code.gson:gsonMaven1539147Microsoft.Extensions.DependencyInjection.AbstractionsNuget1501548pryRubygems1441、97849odooPypi1458850org.assertj:assertj-coreMaven14556（2）关键基础开源软件的漏洞披露情况未见改善（2）关键基础开源软件的漏洞披露情况未见改善分析发现，历年来，有较大比例的关键基础开源软件从未公开披露过漏洞，造成这种现象的原因主要有两个，一方面，有的关键基础开源软件，特别是有的开源社区中的软件，漏洞虽然已被修复了，但没有记录和公开；另一方面，维护和安全研究等相关人员对一些关键基础开源软件安全性的关注程度不够，对它们漏洞挖掘的研究还不多。2023 年，对 1709 款关键基础开源软件分析发现，有 1313 款从未公开披露过漏洞，占比达 76.42、8%，呈现出逐年升高的趋势，如下图所示。但另一方面，关键基础开源软件中也不乏漏洞披露流程非常正规的优秀开源项目。25（3）关键基础开源软件的整体运维风险有所改观（3）关键基础开源软件的整体运维风险有所改观本期报告依然从“版本更新时间”和“周提交频率”两个维度来分析判断关键基础开源软件的运维状况。首先，关键基础开源软件新版本发布的活跃度有较大提升。截止2023 年底，半年内没有发布过新版本的关键基础开源软件有 453 款，占比为 26.5%，较去年的 41.5%有较大的下降。其次，关键基础开源软件提交的积极性有所降低。去年一年内，周平均提交次数小于5和小于1的关键基础开源软件数量分别为1245和43、 916，占比分别为 72.8%、53.6%，两项指标较前两年持续升高。此外，在 TOP50 的关键基础开源软件中，有 34 款软件明确已获得大厂或者基金会支持，比前两年的 23 和 24 款有明显增加；Github贡献者数量小于 100 的有 8 款,比去年和前年减少 1 款。266、NPM 生态中恶意开源软件分析6、NPM 生态中恶意开源软件分析分析发现，NPM 包生态系统较容易受到恶意代码投毒攻击。2023年，奇安信代码安全实验室通过开源仓库监控平台，共检测出该包生态系统中的 381 个恶意开源组件。（1）超 95%的恶意开源组件以窃取敏感信息为目标（1）超 95%的恶意开源组件以窃取敏44、感信息为目标其中，大部分恶意组件的攻击集中在下载安装阶段，恶意行为包括用户敏感信息窃取、主机敏感信息窃取、Git 账户信息窃取、主机失陷攻击、恶意域名访问，各类恶意开源组件的数量和占比如下图所示。可以看出，95.3%的恶意组件以窃取敏感信息为最终目标，这些敏感信息包括用户名、密码、DNS、服务器 IP、Github 配置等。27（2）典型恶意开源组件及恶意行为剖析（2）典型恶意开源组件及恶意行为剖析针对各种恶意行为的典型恶意开源组件如下表所示。恶意行为组件版本主机敏感信息窃取slotbooking-ui2.18.0sber-ufs-sbert/icons4.45.0banca-movil-io45、nic-v41.1.2dlw.scbase.staticsite9999.10.9fio-registrations2.0.0用户敏感信息窃取npm_package_devdependencies_sass2.69.5update-material-outline-gap3.7.14lifi-contracts1.0.0testvijaysimha/gd-util1.0.0unit-testing-controllers1.0.3主机失陷攻击qr-emvco1.1.2vader-pack1.0.3doneida1.0.7deuna-lib-tl-react-native-biocatch1.146、.2capacitor-selphi-plugin1.5.5恶意域名访问zscaler/ec-domain5.0.0backbone.picky1.0.0testepocdep1.1.1Git 账户信息窃取gusmano/reext0.0.249本节以恶意开源组件 slotbooking-ui 2.18.0 为例，介绍其进行主机敏感信息窃取的过程。使用者在安装该组件时，它会运行脚本来窃取服务器信息，具体步骤如下：281）安装过程中，该恶意组件通过 package.json 里定义的命令，执行预先编写好的 index.js 脚本；2）脚 本 获 取 服 务 器 内 环 境 变 量，以 及/etc47、/hosts 和/etc/resolv.conf 的文件内容，如下图所示；3）文件内容通过 get_file()函数进行 base64 编码，以便于进行传输；4）该恶意组件将收集到的信息通过 post 请求发送给攻击者，如下图所示。29四、国内企业软件开发中开源软件应用状况四、国内企业软件开发中开源软件应用状况2023 年，奇安信代码安全实验室对 1763 个国内企业软件项目中使用开源软件的情况进行了分析，包括其中开源软件的使用，以及由此所带来的漏洞和许可证风险等安全问题的情况。301、开源软件总体使用情况分析（1）平均每个软件项目使用 166 个开源软件，再创新高1、开源软件总体使用情况分析48、（1）平均每个软件项目使用 166 个开源软件，再创新高与往年一样，在被分析的 1763 个国内企业软件项目中，全部使用了开源软件，使用率为 100%。平均每个项目使用了 166 个开源软件，此项数据再创新高。本次分析的软件项目中使用开源软件最多的数量为 6168 个，使用开源软件排名前 10 的项目的情况如下图所示。31（2）最流行的开源软件被 37.2%的软件项目使用（2）最流行的开源软件被 37.2%的软件项目使用在被分析的 1763 个国内企业软件项目中，使用最多的开源软件为 SLF4J API Module，被 656 个项目所使用，占比为 37.2%，低于去年 43.6%的水平。被49、使用最多的前 10 名开源软件如下表所示。开源软件名称使用的项目数被使用率SLF4J API Module65637.2%Commons Io:Commons Io62735.6%Apache Commons Codec62535.5%Fasterxml Jackson Core:Jackson Databind59133.5%Fasterxml Jackson Core:Jackson Core57932.8%Fasterxml Jackson Core:Jackson Annotations57132.4%Google Guava:Guava55331.4%Apache Commons:C50、ommons Lang354530.9%32fastjson1-compatible53230.2%Apache Commons Logging51829.4%2、开源软件漏洞风险分析（1）存在容易利用的开源软件漏洞的项目占比大幅下降2、开源软件漏洞风险分析（1）存在容易利用的开源软件漏洞的项目占比大幅下降统计发现，在被分析的 1763 个国内企业软件项目中，存在已知开源软件漏洞的项目有 1551 个，占比为 88.0%；存在已知高危开源软件漏洞的项目有 1428 个，占比为 81.0%；存在已知超危开源软件漏洞的项目有 1268 个，占比为 71.9%。这三个比例均略低于去年水平，与202151、 和 2020 年基本持平。综合漏洞的 POC/EXP 情况以及 CVSS 可利用性指标等因素，我们将漏洞的利用难度分为容易、一般、困难，容易利用的漏洞风险极高。在被分析的 1763 个项目中，存在容易利用的漏洞的项目有 1200 个，占比为 68.1%，较前两年降幅较大。历年存在各类开源软件漏洞的软件项目的占比情况如下图所示。33（2）平均每个项目包含的已知开源软件漏洞数明显回落（2）平均每个项目包含的已知开源软件漏洞数明显回落在 1763 个国内企业软件项目中，共检出 146568 个已知开源软件漏洞（涉及到 13135 个唯一 CVE 漏洞编号），平均每个软件项目存在83 个已知开源软件52、漏洞，与去年的 110 个相比，降幅明显，但仍高于之前两年的水平。34本次分析的软件项目中，引入已知开源软件漏洞最多的数量为1929 个。存在已知开源软件漏洞数量排名前 10 的项目的情况如下图所示。35（3）影响最广的开源软件漏洞的影响范围有所减小（3）影响最广的开源软件漏洞的影响范围有所减小从漏洞的影响度来分析，影响范围最大的开源软件漏洞为CVE-2023-35116，存在于 33.4%的软件项目中，比去年最高的 41.9%有较大减小，说明本年度检测出的开源软件漏洞的影响范围较为分散。2023 年影响度排名前 10 的开源软件漏洞如下表所示。漏洞名称CVE 编号影响项目数量影响度Faste53、rXML jackson-databind 代码问题漏洞CVE-2023-3511658833.4%Google Guava 安全漏洞CVE-2023-297650528.6%Spring Framework 安全漏洞CVE-2024-2224347026.7%Spring Framework 安全漏洞CVE-2024-2226247026.7%Spring Framework 安全漏洞CVE-2024-2225947026.7%FasterXML jackson-databind 代码问题漏洞CVE-2022-4200346026.1%Apache HTTP/2 资源管理错误漏洞CVE-2054、23-4448746026.1%Vmware Spring Framework 代码问题漏洞CVE-2016-100002746026.1%Spring Framework 安全漏洞CVE-2023-2086145826.0%FasterXML jackson-databind 代码问题漏洞CVE-2022-4200445625.9%容易利用的漏洞更易被用来发起攻击，风险极高。影响度排名前10 的容易利用的开源软件漏洞情况如下表所示。36容易利用的漏洞名称CVE 编号影响项目数量影响度Vmware Spring Framework 代码问题漏洞CVE-2016-100002746026.1%j55、Query 跨站脚本漏洞CVE-2020-1102241223.4%jQuery 跨站脚本漏洞CVE-2020-1102341223.4%jQuery 跨站脚本漏洞CVE-2019-1135840122.7%Spring Framework 代码注入漏洞CVE-2022-2296538421.8%jQuery 跨站脚本漏洞CVE-2015-925137821.4%Vmware Spring Framework 安全漏洞CVE-2021-2209634519.6%Vmware Spring Framework 安全漏洞CVE-2021-2206034419.5%OpenSSL 缓冲区错误漏洞CV56、E-2021-371132918.7%Apache HttpClient 安全漏洞CVE-2020-1395630217.1%（4）20 多年前的开源软件漏洞仍然存在于多个软件项目中（4）20 多年前的开源软件漏洞仍然存在于多个软件项目中分析发现，与往年报告结果一样，部分软件项目中仍然存在很久之前公开的古老开源软件漏洞，其中，最古老的漏洞是 2001 年 7 月12 日公开的 CVE-2001-1267，距今已 23 年，这一时间比去年报告中的最古老开源软件漏洞的发布时间还早一年。部分古老开源软件漏洞的影响情况如下表所示，它们的发布时间距今都已超过 20 年。漏洞名称CVE 编号发布日期影响项57、目数量GNU Tar 敌对目标路径漏洞CVE-2001-12672001-07-121GZip 超长文件名缓冲区溢出漏洞CVE-2001-12282001-11-11378zlib 安全漏洞CVE-2002-00592002-03-158GNU tar 任意文件覆盖漏洞CVE-2002-12162002-10-281Portable Network Graphics 任意脚本远程执行漏洞CVE-2002-13632002-12-262zlib 安全漏洞CVE-2003-01072003-02-235GNU Gzip 输入验证错误漏洞CVE-2003-03672003-07-021LibPNG 58、不合法 PNG 越界访问拒绝服务漏洞CVE-2004-04212004-04-302GNU gzexe 临时文件命令执行漏洞CVE-2004-06032004-06-241Microsoft MSN Messenger PNG 图片解析远程代码执行漏洞CVE-2004-05972004-07-1223、开源软件许可协议风险分析（1）最流行的开源许可协议在 46.9%的项目中使用3、开源软件许可协议风险分析（1）最流行的开源许可协议在 46.9%的项目中使用在 1763 个被分析的国内企业软件项目中，共发现 545 个开源许38可协议。涉及项目数最多的协议与前两年一样，依然是 Apache Li59、cense2.0，在 827 个项目中使用，占比为 46.9%。涉及软件项目数排名前 10的许可协议如下表所示。开源许可协议涉及项目数所占比例Apache License 2.082746.9%MIT License68839.0%BSD 3-Clause New or Revised License23313.2%BSD 2-Clause Simplified License1327.5%GNU General Public License v2.0 only1317.4%GNU General Public License v1.0 or later1066.0%Public Domain60、985.6%GNU General Public License v3.0 only915.2%ISC License844.8%GNU General Public License v2.0 or later814.6%（2）超 1/5 的项目使用了含有超、高危许可协议的开源软件（2）超 1/5 的项目使用了含有超、高危许可协议的开源软件有些类型的开源许可协议中包含了一些限制性条款，在使用过程中一旦违反这些条款，可能对企业的商业利益和声誉造成严重的损害。这些限制性条款包括如：“禁止本软件及其衍生品用于商业目的”、“禁止在未支付费用和版税的情况下将该软件用于非公开、非商业用途”、“软件发布时必61、须公开软件的源代码”等。奇安信代码安全实验室将限制性较为苛刻的一类协议定义为超39危许可协议，将限制性较大而未达到超危水平的一类协议定义为高危许可协议。在 2023 年分析的 1763 个国内企业软件项目中，存在超危许可协议的项目 124 个，占比 7.0%；存在高危许可协议的项目 256 个，占比 14.5%。含超危和高危许可协议的项目合计占比约为 21.5%，超过1/5,高于去年约 1/6 的占比。本次分析的软件项目中使用到的超危许可协议如下表所示。超危开源许可协议简称涉及项目数GNU General Public License v3.0 onlyGPL-3.0-only91GNU Ge62、neral Public License v3.0 or laterGPL-3.0-or-later44GNU Affero General Public License v3.0 onlyAGPL-3.0-only37GNU Lesser General Public License v3.0 onlyLGPL-3.0-only20GNU Lesser General Public License v3.0 or laterLGPL-3.0-or-later11Creative Commons Attribution Non CommercialShare Alike 2.5 Generic63、CC-BY-NC-SA-2.58GNU Free Documentation License v1.2 onlyGFDL-1.2-only7涉及软件项目数排名前 10 的高危许可协议如下表所示。高危开源许可协议简称涉及项目数GNU General Public License v2.0 onlyGPL-2.0-only131GNU General Public License v2.0 or laterGPL-2.0-or-later81GNU Lesser General Public License v2.1 onlyLGPL-2.1-only76GNU Library General P64、ublic License v2 or laterLGPL-2.0-or-later6540GNU Lesser General Public License v2.1 or laterLGPL-2.1-or-later59Mozilla Public License 1.1MPL-1.158Eclipse Public License 1.0EPL-1.056GNU Library General Public License v2 onlyLGPL-2.0-only31Creative Commons Attribution Share Alike 3.0UnportedCC-BY-SA-65、3.023Creative Commons Attribution Non CommercialShare Alike 3.0 UnportedCC-BY-NC-SA-3.0104、开源软件运维风险分析4、开源软件运维风险分析开源软件运维风险复杂多样，本期报告依然从老旧开源软件的使用和开源软件多个版本混乱使用的角度进行分析。（1）多个二三十年前的老旧开源软件版本仍在使用（1）多个二三十年前的老旧开源软件版本仍在使用分析发现，与前几年报告数据一致，许多软件项目中仍然在使用老旧的开源软件版本，有的版本已经超过 30 年，存在极大的运维风险。被使用的老旧开源软件版本中，最早的一款是 1993 年 366、 月 3 日发布的 byacc 1.9，已经发布 31 年。按老旧程度排名前 10 的开源软件如下表所示。开源软件名称版本号版本发布日期涉及项目的数量byacc1.91993-03-031checker0.8-211999-03-09141journal1-41999-03-091GNU tar1.131999-09-051sdc1.0.8beta-82000-08-182Getopt-Long2.242000-08-281GNU bc1.062000-11-154URI1.102001-01-111zlib1.1.32001-02-053libpng1.0.92001-03-261（2）开源67、软件各版本使用依然混乱（2）开源软件各版本使用依然混乱分析发现，与往年一样，开源软件版本使用混乱的状况依然非常严重，并非使用的都是最新版本。Spring Framework:Spring Core 是被使用版本最多的开源软件，有 169 个版本在被使用。按照被使用版本的数量排序，排名前 10 的开源软件情况如下表所示。开源软件名称被使用的版本数量Springframework:Spring Core169Springframework:Spring Beans165Springframework:Spring Context163Spring AOP161Springframework:Spr68、ing Web159Spring Expression Language(SpEL)154Spring Web MVC14942Spring Transaction147Spring JDBC146Springframework:Spring Context Support136五、典型软件供应链安全风险实例分析五、典型软件供应链安全风险实例分析1、多款主流操作系统供应链攻击实例分析1、多款主流操作系统供应链攻击实例分析Ubuntu 是一款被广泛使用的 Linux 操作系统发行版，具有多种用途，可用作个人计算机的操作系统，提供办公、媒体播放、游戏等的图形用户界面；同时它也是开发人员的首选操作系69、统之一，因为它支持 Python、Java、C+等多种编程语言，还提供了 GCC 编译器和版本控制系统等开发库和工具。使用者通常使用 apt install 命令在Ubuntu 上安装 MiniDLNA，以获得媒体播放服务。MiniDLNA 是一款兼容 DLNA/UPnP-AV 客户端的开源媒体服务软件，支持音乐、图片、视频等媒体文件的播放，可帮助用户通过 DLNA 兼容的智能电视、音响等设备，访问和播放存储在计算机上的多媒体文件。MiniDLNA 被广泛部署在 Linux 服务器上，同时也广泛应用于路由器、NAS 等嵌入式设备上。CVE-2023-33476 是 MiniDLNA 的一个越界70、写类型的超危历史漏洞,由于MiniDLNA在处理采用分块传输编码的HTTP请求时存在逻辑缺陷，攻击者可通过伪造较大的分块长度，触发后续拷贝时出现越界写问题。利用该漏洞，远程未授权的攻击者可实现任意代码执行攻击。该漏洞43影响 MiniDLNA 的 1.1.15-1.3.2 版本。以 Ubuntu 20.04 为例，可通过 apt install 命令安装 MiniDLNA1.2.1。运行该软件后，会监听 8200 端口。利用上述历史漏洞，未认证的攻击者可通过发送伪造的数据包，实现任意代码执行，如下图所示，可以看到成功获取反弹 shell，表示攻击成功。除此之外，Debian11、多个型号的路由71、器等也有类似问题。本实例中，软件供应链风险传播链条为：多款主流操作系统的某些版本，在通过常规方式安装开源媒体服务软件 MiniDLNA 后，远程未授权的攻击者可能会利用MiniDLNA的历史漏洞CVE-2023-33476对这些操作系统版本发起任意代码执行的软件供应链攻击。2、PHP 软件供应链攻击实例分析2、PHP 软件供应链攻击实例分析PHP 是一种被广泛使用的开源脚本语言，可以嵌入到 HTML 中，特别适用于 Web 开发。PHP 在运行时会依赖于底层的系统库 Linux44glibc（GNU C 库）来进行文件读写、网络通信等操作，可以认为 PHP利用 Linux glibc 来支持其72、程序的运行及与操作系统的交互。Linux glibc 是 GNU 按照 LGPL 许可协议发布的开源 libc 库，即 C运行库，是 Linux 系统中最底层的 API，几乎其他任何运行库都会依赖于 glibc。glibc 被广泛应用于各种应用和设备中，包括大部分 Linux发行版以及路由器等。glibc 除了封装 Linux 操作系统所提供的系统服务外，它自身也提供了许多必要功能服务的实现，为各种应用程序提供了基础的接口和功能。CVE-2024-2961 是 Linux glibc 库的一个中危历史漏洞，该漏洞源于 iconv()函数存在缓冲区溢出问题，可导致应用程序崩溃或覆盖相邻变量。如果73、某 PHP 应用程序中存在任意文件读取漏洞，攻击者便可以利用其实施文件读取操作，在读取过程中，会调用到glibc的iconv()函数，攻击者可进一步利用 CVE-2024-2961 对 PHP 开发的应用实施远程命令执行攻击，从而提升了漏洞的危害程度。该漏洞影响 Linuxglibc 2.39 及更早版本。下图展示了该漏洞对 PHP 8.1 的影响验证结果。PHP 8.1 中使用了 glibc 2.35，利用上述历史漏洞后，可以看到执行了给定的命令“whoami/tmp/16666.txt”，对应权限为“www”，成功实现了远程命令执行攻击。45本实例中，软件供应链风险传播链条为：PHP 程序74、运行时使用Linux glibc 库，如果某 PHP 应用程序存在任意文件读取问题，攻击者便可以基于 glibc 的历史漏洞 CVE-2024-2961 对该 PHP 程序发起远程命令执行的软件供应链攻击。3、某国产数据库供应链攻击实例分析3、某国产数据库供应链攻击实例分析某国产数据库是一款自主研发的数据库，可用作数据仓库系统、BI 系统和决策支持系统的承载数据库，具有高性能、高可用性、跨平台支持、兼容性和可扩展性等特点，被规模化应用于金融、电信、能源、政企等行业。分析发现，为方便用户进行数据迁移，实现与开源数据库 MySQL 的适配，该国产数据库的最新版本基于 MySQL JDBC5.1.175、1 实现了建立到数据库服务端连接的功能。JDBC（Java Database Connectivity）是 Java 提供的一套用于连接数据库的标准 API，它定义了一套标准的接口，使得开发者可以使用相同的代码来连接不同类型的数据库。而 MySQL JDBC（或 MySQLConnector/J 组件）是一种用于连接 MySQL 数据库的 JDBC 驱动，允许Java 程序通过 JDBC API 访问 MySQL 数据库中的数据。46CVE-2021-2471 是 MySQL JDBC 的一个 XML 外部实体注入类型的中危历史漏洞。由于 MySQL JDBC 中的 getSource()方法76、对传入的 XML数据校验不足，导致攻击者可以通过构造恶意的 XML 数据，实现远程特权用户读取敏感数据或使应用程序崩溃等攻击。该漏洞影响 MySQLJDBC 8.0.27 以下版本。MySQL JDBC 的另一个代表性的高危历史漏洞是 2019 年爆出的某反序列化漏洞。攻击者向 MySQL 服务器发送恶意数据，然后通过控制JDBC 连接设置项，将其配置指向该服务器。MySQL 客户端处理结果集时会调用 ObjectInputStream.readObject()方法，从而执行恶意的反序列化操作，从而引发远程命令执行等攻击。该漏洞影响 MySQL JDBC8.0.21 以下版本。分析发现，上述两77、个历史漏洞依然能够影响本例中的国产数据库的最新版本。以下展示了在其上利用两个漏洞的效果，可以实现远程命令执行等攻击，具体效果如下所示：成功利用 CVE-2021-2471 漏洞的效果HTTP 服务收到 PoC 中 XML 外部实体解析发起的 HTTP 请求，成功实现服务端请求伪造攻击，如下图所示。成功利用 2019 年某 MySQL JDBC 反序列化漏洞的效果客户端触发了该反序列化漏洞，成功实现远程命令执行攻击，如47下图所示。本实例中，软件供应链风险传播链条为：某国产数据库的最新版本基于 MySQL JDBC 5.1.11 实现连接数据库服务端的特定功能，MySQLJDBC 的 XML 外78、部实体注入、反序列化等历史漏洞依然可以影响该国产数据库，实现远程命令执行等软件供应链攻击。六、总结及建议六、总结及建议过去的一年，软件供应链安全依然是网络安全领域的热点，但各方的态度更加趋于理性和谨慎，各项工作也正处于循序渐进向深水区探索的阶段。欧美国家在前两年密集完成了一系列政策、框架、指南、最佳实践等的制定和修订后，转入了基于这些文件的监管执行阶段，例如根48据美国 OMB 备忘录 M-22-18、M-23-16 的要求和 SSDF 1.1 框架，CISA于 2024 年 3 月发布了安全软件开发证明表格，美联邦政府的软件生产供应商需基于该表格证明自己实施特定安全实践的情况；同时，CISA79、 还建立了软件证明和工件存储库，以促使美联邦政府的软件生产供应商上传软件证明表格和相关工件，其中也包括“关键软件”。国内在软件供应链安全保护方面的工作也在扎实推进中，一是顶层规范不断完善，国家标准中软件供应链安全要求和软件产品开源代码安全评价方法已发布，软件物料清单数据格式也已完成公开征求意见；二是行业建设如火如荼，多个行业的机构开展了面向软件供应链安全、开源软件治理、软件物料清单（SBOM）生成和应用等方面的能力建设、能力评估、工具评价等工作；三是解决方案持续落地，国内一些头部网络安全公司和大型企业组织陆续推出或落地了较为全面的软件供应链安全解决方案，并在持续的完善。但另一方面我们也看到，目80、前国内缺少软件供应链安全管理领域权威的实施指南；此外，对于数量巨大的中小型软件研发企业来说，制定和实施系统的软件供应链安全解决方案面临着成本、精力、人员等诸多难题，当前能够采取的防护措施相对有限。因此，应加强软件供应链安全保障的顶层设计，建立健全软件供应链安全的指导监督机制和基础服务设施，并尽量覆盖所有类型的软件生产和供应商。具体建议如下：1）建立国家层面统一的软件供应链安全保护基础设施1）建立国家层面统一的软件供应链安全保护基础设施一是组织编制基于国标的实施指南，明确达到保护要求所需的机49制方法、具体措施和推荐工具等内容，为软件供应商，特别是中小型研发企业提供专业指导和操作手册；二是建立软81、件供应链安全检测服务平台，满足软件供应商对代码安全审计、漏洞扫描、开源软件成分及风险分析等方面的在线检测需求，降低中小型研发企业的检测成本；三是完善开源软件的安全处置机制，包括开展针对关键基础开源软件的安全漏洞分析、恶意代码检测、安全加固、集中维护、漏洞信息定向通报和补丁定向分发等工作。2）完善国家和行业级的软件供应链安全测评认证体系2）完善国家和行业级的软件供应链安全测评认证体系二十届三中全会通过的中共中央关于进一步全面深化改革、推进中国式现代化的决定强调，要建立产业链供应链安全风险评估和应对机制。第三方权威测评机构，依据全面的指标、规范的流程和专业的工具，可以更加系统的发现软件供应链的安全82、问题，弥补供应商自测的不足。监管部门应鼓励相关测评机构基于现行标准和实践，积极开展软件供应链安全测评指标的研究，建立并完善相应的测评能力和平台，形成针对各类重要系统、各个行业的软件供应链安全测评体系，并在此基础上，开展软件供应商及其产品的安全认证工作。3）健全关基软件供应商安全实践证明材料的备案机制3）健全关基软件供应商安全实践证明材料的备案机制鉴于关键基础设施的重要性，应要求向关键基础设施和重要信息系统用户销售软件产品、提供软件定制开发的厂商和供应商，在交付软件系统前，除了进行安全性自测和第三方测试外，还应向特定机构和关基运营者备案研发过程中所采取的安全措施的情况，包括安全开发流程的执行、安83、全编码的制定和采用、引入的第三方组件的安全性50分析和修补措施等情况。同时，应提供软件物料清单（SBOM）。这些内容可作为供应商管理和安全责任追溯的重要依据。51附录：奇安信代码安全实验室简介附录：奇安信代码安全实验室简介奇安信代码安全实验室是奇安信集团旗下，专注于软件源代码安全分析技术、二进制漏洞挖掘技术研究与开发的团队。实验室支撑国家级漏洞平台的技术工作，多次向国家信息安全漏洞库（CNNVD）和国家信息安全漏洞共享平台（CNVD）报送原创通用型漏洞信息并获得表彰；帮助微软、谷歌、苹果、Cisco、Juniper、Red Hat、Ubuntu、Oracle、Adobe、VMware、阿里云、84、飞塔、华为、施耐德、Mikrotik、Netgear、D-Link、Netis、ThinkPHP、以太坊、Facebook、亚马逊、IBM、SAP、NetFlix、Kubernetes、Apache 基金会、腾讯、滴滴等大型厂商和机构的商用产品或开源项目发现了数百个安全缺陷和漏洞，并获得公开致谢。目前，实验室拥有国家信息安全漏洞库（CNNVD）特聘专家一名，多名成员入选微软全球 TOP 安全研究者、Oracle 安全纵深防御计划贡献者等精英榜单。在 Pwn2Own 2017 世界黑客大赛上，实验室成员还曾获得 Master of Pwn 破解大师冠军称号。基于奇安信代码安全实验室多年的技术积累85、，奇安信集团在国内率先推出了自主可控的软件代码安全分析系统奇安信代码卫士和奇安信开源卫士。奇安信代码卫士是一款高度可扩展的静态应用程序安全测试系统，该系统提供了一套企业级源代码缺陷分析、源代码合规分析、IaC安全分析的解决方案，在不改变企业现有开发测试流程的前提下，与软件版本管理、持续集成、缺陷跟踪等系统进行集成，将源代码安全52分析融入企业开发测试流程中，实现软件源代码安全目标的统一管理、自动化检测、差距分析、缺陷修复追踪等功能，帮助企业以最小代价建立代码安全保障体系并落地实施，构筑信息系统的“内建安全”。奇安信代码卫士目前支持 C、C+、C#、Objective-C、Swift、Java、86、PHP、Python、Cobol、Go 等 32 种编程语言，可检测 3500 多种源代码安全缺陷，支持多个国际、国内主流标准和规范的检测。奇安信开源卫士是一款集开源软件识别与安全管控于一体的软件成分分析系统，该系统通过智能化数据收集引擎在全球范围内获取开源软件基础信息、协议信息及其相关漏洞信息，利用自主研发的开源软件分析引擎为企业提供开源软件资产识别、开源软件漏洞风险分析、开源软件协议风险分析、开源软件运维风险分析、开源软件漏洞情报预警及开源软件安全管理等功能，帮助企业掌握开源软件资产信息及相关风险，及时获取最新开源软件漏洞情报，降低由开源软件给企业带来的风险，保障企业交付更安全的软件。奇安信开源卫士目前可识别超过 1.8 亿开源软件版本的识别，支持源代码、二进制、容器镜像、操作系统的开源软件成分分析，兼容 NVD、CNNVD、CNVD 等多种漏洞情报来源。奇安信代码卫士和奇安信开源卫士已经在近千家大型机构和企业中应用，入选国家发改委数字化转型伙伴行动、工信部中小企业数字化赋能专项行动，为中小企业提供软件代码安全检测平台和服务。