2024年全球软件供应链发展报告：从创新到发展防范软件生态系统中的隐藏风险-JFrog

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