2024 年全球软件供应链发展报告

2 3 4 5 6 7 8 9 理和保护整个软件供应链是交付安全可信软件的安全、开发和运维人员的数据，为保障企业软件供应链安全提供了上下文分析，揭示了安全风险所在，并展示了如何在保护软件供应链安全的同时现如今，每家企业的软件供应链集成应用的软件工具错综复杂，企业组织面临着比以往更大的安全风险。如果企业领导者选择合适的软件工具、管理与监控工作流程和实践，便可借助多场景化管理软件供应链的实践，巩固企业的安竞争优势。企业的软件供应链正在快速扩展保护软件供应链安全应该聚焦何处如今企业建立的软件供应链采用多种技术、集跨越异国服务器，很多企业组织使用十几种编程语言。每年可用于开发应用程序的开源软件包和库越来越多，软件开发团队使用的编程语言的数量种语言所有企业组织种语言企业组织规模不到名员工超过图1.您的软件开发团队使用了多少种编程语言？超过半数的受访者(53%)表示，他们的软件开发团队使用4到9种编程语言。近三分之一(31%)的受访者表示，他们使用10种或以上的编程语言。规模超过5,000名员工的企业组织更有可能使用10种以上按照年份和类型划分的新软件包数量包管理器新软件包数量图2.每年新软件包的数量，按包类型划分最常用的软件编程语言操作次数（上传/下载）操作次数（上传/下载）制品数量如图所示，JFrog为30多种软件包类型提供原生支持，但在生产发布软件中最常用的编程语言到上传/下载次数、仓库数量和存储的制品总数，软件开发团队显然优先考虑使用这些编程语仓库的数量YUMComposer汽车和物联网公司使用Maven（后端应常将其中的许多技术捆绑成通用软件包AlpineCocoapods机器人和AI/MLOps公司使用PyPI和AlpineCocoapods等公共网站的ML模型，同时也将这些模型存储在容器或通用软件包(tar/zip)中，但他们现在也开始为其ML模型采用保险、金融和零售企业使用Maven、PuppetPuppetAI/ML的普及，为了保持竞争优势，这些公司也开始利用PyPI和ML模型来提供更好的产品。图3.所使用的软件编程语言，以及各种软件包类型的操作次数、仓库数量和存储的制品总数（Artifactory数据关键要点段，但这标志着企业组织迈出了重要的一步，他们在JFrogPlatform中管理ML模型和其它所有软件制品，将ML模型开发引入其安全软件供应链。我们的数据显示，在构建ML新模型时广泛使用的PyPI和Conan等主流软件包的采用率稳步增长。尽管Rust等新型软件技术引起了人们的浓厚兴趣，但在开发发布软件方面，最受欢迎的软件技术并没有发生明显变动。Java、Python、JavaScript等生态系统的势头依旧强劲，很多企业组织选择继续使用他们知道行之有效的技术。这些新型的编程语言可能还需要一段时间才能在大企业中真正站稳脚跟。软件开发团队应该使用最适合其项目需求的编程语言。然而，从DevOps和安全的角度来看，每多一种编程语言或包类型，就会带来额外的安全风险，增加企业管理的难度。特别是对大公司来说，如果没有适当的软件工具和监控流程，确保安全地使用10多种编程语言可以说是难于登天。Docker、OCI和Helm仓库大行其道，这表明，容器化已经在生产软件资产中得到广泛采用。现在，企业组织对容器习以为常，开始转向动态运行时（如Kubernetes一些有远见的技术人员开始部署Web在特定用例中具有独特的优势。在管理软件供应链风险方面，企业组织面临着在特定技术或软件包类型中发现的漏洞（数量）（数量）（数量）软件包类型图4.各种软件包中发现的CVE数量在通过开源生态系统引入漏洞方面，并非所79：网页生成时输入内容未正确中和89：SQL命令中使用的特殊元素未正确中和22：对路径名的限制不恰当120：不检查输入数据大小就复制缓冲区78：OS命令中使用的特殊元素未正确中和434：无限制上传危险类型的文件77：命令中使用的特殊元素未正确中和400：不受控制的资源消耗94：对代码生成的控制不当图5.与2022年和2021年相比，2023年发现的常见漏洞在2023年发现的漏洞中，到目前为止最常见的通用缺陷(CWE)是那些影响前端的漏洞：跨站脚本、SQL注入和越界写入。自2021年以来，这三个漏洞始终跻身前五大最常见的潜在漏洞之列。其中，跨站脚本在CVE中的发生率继续上升，常见漏洞中的排名从2021年的第9位升至2023年的第4回顾过去几年，我们可以发现，CWE类型漏洞的同比增长趋势很容易受到随机因素和其它噪音的影响。例如，通过分析过去20年的情况，我们会发现更有意义的趋势：低级编程语言和高级编程语言的流行度会影响内存损坏漏洞和高级web漏洞的数量。特定相关软件技术的兴起也会产生一定的%任意文件覆盖%本地权限提升%身份验证绕过%过滤器绕过数据泄露%%脚本代码注入%本地权限提升%身份验证绕过2.6%过滤器绕过%数据泄露%%过滤器绕过、数据泄漏和脚本代码注入等漏洞。在对企业组织的影响方面，远程代码执行是攻击者梦寐以求的漏洞，这个漏洞比DoS更严重，因为它可能提供对后端系统的完全访问权限。与2022年相比，热门CVE中的主要漏洞排名变化不大，拒绝服务和远程代码执行位居前两位。相比之下，身份验证绕过漏洞在2023年的流行度大幅降低。如果采用适当的应用程序和安全框架，某些漏洞本身并不那么危险，但是像本地权限提升和身份验证绕过这样的漏洞，如果与远程代码执行等其他漏洞root权限的用户。因此，对系统架构的设计应经过深思熟虑，防止越界访问事件的发生。图6.2022和2023年热门CVE中的常见漏洞类型软件供应链中漏洞的严重程度严重高危中危低危高危严重低危月份图7-1.近两年内按月份和严重程度划分的CVE（美国国家漏洞数据库，由JFrog安全研究团队进行分析）美国国家漏洞数据库的CVE数据显示，在2022年1月至2023年11月，严重和低危CVE相对来说变化不大，但中危和高危图7-2.近两年内按月份和严重程度划分的CVE（美国国家漏洞数据库，由JFrog安全研究团队进行分析）严重高危JFrog严重程度严重高危低危不过，并非所有的CVE评级都名副其实。JFrog安全研究团队定期评估CVE，以确定其实际影响并进行JFrog利用漏洞的配置要求纳入考量。CVSS评级只是着眼于漏洞被利用后的严重程度，没有考虑漏洞的可利用程度。有时，可利用漏洞的配置要求或利用方法是针对特定软件包或依赖项的非标准设置，有可能降低漏洞被利用的可能性。低危此外，并不是所有的已知漏洞都能被利用。例如，JFrog安全研究团队发现，在DockerHub社区最受欢迎的100个镜像，CVSS评分为“高危”和“严重”的已知常见CVE中，有74%实际上是不可利用的。从《2023年JFrog安全研究报告》中可以看出图9）这些可利用不可利用图9.在DockerHub社区最受欢迎的200个镜像上严重和高危CVE的可利用性最危险的恶意软件包上半年下半年上半年下半年上半年下半年上半年意外造成的CVE是开源软件供应链潜在风险的最大来源，可以采取适当的预防措施来降低这不一定意味着该软件包不能使用。也许更为重要的是监控和防止恶意软件包进入您的软件供应链，因为即使只是下载这些软件包也可能使企业遭受攻击。例如，对npm的分析显示，仅在2022年下半年到2023年上半年，引入开源生态系统的恶意软件包数量就增加了一倍图10.Npm恶意软件包数量同比增长有些恶意软件包比其它软件包更危险JFrog安全研究团队根据恶意软件包对企业组织的潜在影响及其进入软件供应链的方式，评选出了他们认为近期值得注意的恶意软件包。其中各个恶意软件包的简介如下：2023年最危险的Python恶意软件包，在受害者的设备上安装来源>最危险的npm软件包，部署名为r77的rootkit后门，让攻击者可以来源>JFrog报告了有史以来第一个NuGet恶意软件包，该软件包部来源>隐藏在代码中的其它安全风险首席信息安全官及其团队知道，您从开源社区引入的软件包需要加以重点关注。JFrog在与首席信息安全官、安全团队和DevSecOps团队进行交流时，我们也提醒他们，就应用程序的整体安全性而言，开源软件包并不是唯一一个需要注意的方面。配置不当和错误——人为失误的影响2023年，敏感数据因为服务器不安全、云配置错误、包含敏感数据的文件泄露等原因而在互联网上曝光的事件层出不穷。以下总结了2023年影响最大的配置错误事件。航空公司CommuteAir的涉恐禁飞名单因为一个不安全的服务器而泄露，这份名单包含150万条禁飞人员信息。来源>用“JitsiMeet”中的一个环境文件，导致敏感的凭证信息泄露。来源>Capita发现存放议会历史数据（包括福利信息）的服务器并不安全。来源>微软披露，中国黑客组织Storm-0558利用一系列安全配置错误，入侵了包括美国政府机构在内来源>美国特种作战司令部的内部电子邮件因为服务器配置错误而在网上公开曝光，泄露了近两周的未分类数据。来源>可公开访问的DigitalOcean存储库而泄露了360万客户的敏感数据。来源>日本汽车制造商丰田汽车公司发现，丰田互联名车主的信息泄露。来源>旅游业巨头Mondee发现，由于Oracle云服务器配置错误，敏感的客户信息被泄露，包括详细的来源>微软的Xbox文件因为“联邦贸易委员会诉微软案”中的一个不安全链接而泄露。微软因AzureBlobStorage配置错误致使TB客户敏感信息泄露，其中包括2017年至来源>微软38TB数据的访问权限因为一个配置错误的链接而意外泄露，使攻击者可以向微软人工智来源>储库而泄露了未成年人的家庭住址和照片等数据。该公司开发的应用程序被印度和斯里兰卡的来源>泄密情况到目前为止，令牌泄露最多的是AWS、Telegram、GitHub和OpenAI，与2022年的结果相比新增了OpenAI，这是因为AI/ML模型的采用率开始提高。同样值得注意的是，已泄露机密的总数同比有所减少。理想情况下，这个数字应该更接近于零，因为从安全的角度来看，这是相对容易实现的目标，而且市场上有大量的机密检测工具。telegramtokengithub openai sendgrid twilio npmdigitaloceanspaces github_oldshopify sendinbluev2 mailchimp flutterwave图11.2023年最常见的公开泄露访问令牌关键要点每年应对26,000多个新CVE，可能会拖慢开发进度，导致开发人员和安全人员不堪重负。软件中有CVE并不一定意味着存在安全问题。开发和安全团队在确定需要优先解决哪些CVE时，CVE评级可能不是最佳指标。在上下文分析中理解CVE的作用机制和运行原理，能够令开发人员专注于更有价值的事情而不是修补漏洞。每年都能在公共注册表中发现数以千计的公司令牌。在工作之余或个人开发项目期间，从事开源项目的开发人员可能会泄露公司机密。即使是简单的错误也可能导致公司令牌出现在公共仓库中（例如使用您的企业Slack认证密钥而不是您软件工具和监控流程可以为企业组织解决这个问题。有关更多信息，请参见我们的《最新发布的缓解解决方案》。前端漏洞有很多，但后端漏洞才是真正令人在2023年的所有CVE中，“前端漏洞”仍然是最常见的CWE（即跨站脚本、SQL注入、越界写入、跨站请求伪造等但也是最容易发现和修复的漏洞。尽管人们越来越意识到与内存安全问题相关的风险，美国政府甚至就此发出警告，但缓冲区溢出漏洞仍在继续增加。这可能表明，企业组织在移植和更新遗留代码时遇到了困难。安全防范意识已经达成共识：89%的受访者表示，他们的企业组织如何应用安全措施以及将其用于何处的问题，调查结果千差万企业组织需要在哪个阶段进行安全扫描随着软件供应链的日益成熟，新的漏洞会逐渐被发现。在编码阶段看起来安全，并不意味着在运行时也是安全的。因此，大多数企业组织都在其软件开发生命周期(SDLC)的各个阶段进行您觉得在软件开发生命周期中，最好是在哪个阶段采取安全措施？最不希望最希望最不希望您的企业组织通常在开发的哪个阶段进行安全扫描选择所有适用项）编码时和构建时构建时和运行时构建时和发布前编码时和发布前编码时和运行时发布前和运行时企业组织通常进行安全扫描的开发阶段是编码时(59%)、的行业趋势，但数据显示，企业组织也认识到需要向软件生命周期的右侧扫描。您的企业组织是否在源代码或二进制文件层面进行安全扫描？源代码和二进制文件扫描仅代码扫描仅二进制文件扫描超过半数的受访者(56%)表示，他件层面进行安全扫描。超过四分之一的受访者(27%)表扫描的类型和所用的工具大多数企业组织都有适当的安全解决方案，但由于自动化代码扫描的缺位以及使用多种安全扫描工具所带来的混乱，开发人员的生产力和效率显然会受到影响。在一个月里，修复漏洞的工作会占用开发供应链，在安全解决方案覆盖面或最佳修复操作可见性方面留下了严重的缺口。您的企业组织是否有适当的安全解决方案来检测恶意开源软件包？的专业人员表示，他们的企业组织有适当的安全解决方案来检测恶意开源软件包。使用的单点式应用程序安全解决方案数量近半数的受访者(47%)表示，他们的企业组织正在使用4到9种单点式应用程序安全解决方案。三分之一的受访者(33%)表示，他们的企业组织正在使用10种或更多的单点式应用程序安全解决方案。您的企业组织正在使用什么类型的单点式应用程序安全解决方案？进一步分析显示，单点式应用程序安全解决方案的受欢迎程度因受访者的工作职责而异：手动代码审查和自动代码扫描在软件开发流程中的占比分别是多少？不到1%的受访者表示，他们在软件开发流程中，已完全实现自动化代码扫描。只有19%的受访者表示，他们的修复安全漏洞耗时多久到2026年，全球软件供应链安全风险预计将造成806亿美元的损失。企业组织花费时间和资金来提前采取安全防范措施显然是合理的。虽然将新功能快速推向市场是有效的竞争优势，但企业组织必须权衡采取安全防范措施对企业生产力和新功能发布的作用。在一个月内，您的开发人员或安全团队通常需要花费多少时间来修复应用程序漏洞？这意味着四分之一的工作时间被用于修复漏洞，而不是从事能够提高商业价值的任务。天这意味着四分之一的工作时间被用于修复漏洞，而不是从事能够提高商业价值的任务。天由谁来管理最新版的软件包、库和框架的获取过程，是安全人员还是开发人员？（选择所有适用项）安全团队开发团队DevOps团队进一步的分析显示，在管理最新版的软件包、库和框架的获取过程方面，IT、IS和其他技术部门中没有哪一个团队处于主导地位。平均而言，受访者确定了2个团队(M=1.95)负责管理调取过程。认为安全团队、开发团队和DevOps团队负责管理此过程的受访者比例相差不大。通常需要多长时间才能获得批准使用最新的软件包/库？批准使用最新的软件包/库通常需要6天或更短时间。另一方面，一些受访者给出了更长的批准等待时间。五分之二(40%)的受访者表示，通常需要一周或更长时间才能获得批准使用最新的软件包/库。关键要点超过四分之一的受访者(27%)表示，他们的企业组织仅在代码层面进行安全扫描。然而，如果认为在编写代码到将其投入到生产环境之间，代码情况不会发生任何变化，这将带来灾难性的后果。就“采取安全措施的最佳阶段”而言，排名最后的是在跨SDLC阶段（从质量保证到试运行）晋级软件时进行安全扫描。随着软件在SDLC的各个阶段日趋成熟，如果不能自动地逐步扫描软件，就难以尽早发现新的漏洞和问题。大多数受访者都是结合使用手动代码审查和自动扫描代码。随着新技术的出现，这种平衡可能会出现波动，但最好是在两者之不是手动代码审查的替代品，但如果没有它，您几乎肯定会错过某些漏洞。此外，纯手动代码审查是难以扩大监控规模的。您需要保护您的SDLC，但这必须以一种无缝的方式进行。在安全任务上花费不必要的时间，筛选来自多种扫描器的结果，等待数天或数周时间才能获准使用新的软件包或库，这些都是在浪费重要的开发时间。想要在不影响生产力的情况下保护软件供应链，关键点是简化使用新软件包和修复漏洞的审批流程，实现监控管理策略自动化、将安全扫描置于上下文分析中，以及将安全洞察直接引入到开发环境。这进一步促进了整合软件工具、远离单点式解决方案的市场大趋势。容、代码的编写方式以及软件应用程序的保护方式产生深远影响。根据包含ML机器学习模型或服务。因此，即便您的企业组织现在您的企业组织是否采取了安全措施/解决方案来检查开源ML模型的安全性和合规性？的受访者表示，他们的企业组织正在采取安全措施/解决方案来检查开源ML机器学习模型的安全性和如今，能够在这方面提供帮助的软件工具非常少，但是企业组织可以采取一些手动防范措施，例如根据发行商、评级等指标来评估ML模型。您的企业组织是否使用AI/ML应用来协助进行安全扫描或漏洞修复？没有是的，同时用于扫描和修复是的，用于扫描是的，没有用于修复在某种程度上使用用于扫描和修复十分之九的受访者(90%)表示，他们的企