2024 年全球軟件供應(yīng)鏈發(fā)展報(bào)告

從創(chuàng)新到發(fā)展：2024JFrogLtd.保留所有權(quán)利。2024JFrogLtd.保留所有權(quán)利。2024JFrogLtd 2 3 4 5 6 7 8 9 10 11 13 15 15 16 18 20 22 24 26 30 31 32 32 2024JFrog安全、開發(fā)和運(yùn)維人員的數(shù)據(jù)，為保障企業(yè)軟件供應(yīng)鏈安全提供了上下文分析，揭示了安全風(fēng)險(xiǎn)所在，并展示了如何在保2024JFrogLtd現(xiàn)如今，每家企業(yè)的軟件供應(yīng)鏈集成應(yīng)用的軟件工具錯(cuò)綜復(fù)雜，企業(yè)組織面臨著比以往更大的安全風(fēng)險(xiǎn)。如果企業(yè)領(lǐng)導(dǎo)者選擇合競爭優(yōu)勢。企業(yè)的軟件供應(yīng)鏈正在快速擴(kuò)展保護(hù)軟件供應(yīng)鏈安全應(yīng)該聚焦何處（藏身之地可能出乎您的意料）2024JFrogLtd.如今企業(yè)建立的軟件供應(yīng)鏈采用多種技術(shù)、集可用于開發(fā)應(yīng)用程序的開源軟件包和庫越來越多，2024JFrog軟件開發(fā)團(tuán)隊(duì)使用的編程語言的數(shù)量1-3種語言所有企業(yè)組織4-9種語言10+多種語言企業(yè)組織規(guī)模不到2,000名員工2,000-4,999名員工超過5,000名員工圖1.您的軟件開發(fā)團(tuán)隊(duì)使用了多少種編程語言？<5,000名員工>5,000<5,000名員工4-9種語言10多種語言10多種語言10多種語言超過半數(shù)的受訪者(53%)表示，他們的軟件開發(fā)團(tuán)隊(duì)使用4到9種編程語言。近三分之一(31%)的受訪者表示，他們使用10種或以上的編程語言。規(guī)模超過5,000名員工的企業(yè)組織更有可能使用10種以上的編程語言（39%對23%）。2024JFrog按照年份和類型劃分的新軟件包數(shù)量包管理器DockerHubnpmPyPIMavenCentralPHPPackagistRubyGems202320222021新軟件包數(shù)量3月）中有近一半是SEO垃圾信息。這進(jìn)一圖2.每年新軟件包的數(shù)量，按包類型劃分（Artifactory數(shù)據(jù)庫，2023年）2024JFrogLtd.軟件包類型npmMavenDockerPyPI軟件包類型npmMavenDockerPyPIConanHelmGradleGemsDebianYUMComposer操作次數(shù)（上傳/下載）倉庫的數(shù)量制品數(shù)量如圖所示，JFrog為30多種軟件包類型提供原生支持，但在生產(chǎn)發(fā)布軟件中最常用的編程語言到上傳/下載次數(shù)、倉庫數(shù)量和存儲(chǔ)的制品總數(shù)，軟件開發(fā)團(tuán)隊(duì)顯然優(yōu)先考慮使用這些編程語有趣的是，特定的垂直行業(yè)往往使用常用的編程語言來解決類似的用例，例如：Docker和PyPI（用于AI/ML并經(jīng)常將其中的許多技術(shù)捆綁成通用軟件包TerraformCondaAlpineCocoapodsChefCondaAlpineCocoapodsChef提取自HuggingFace和Tensorflow等公共網(wǎng)站的ML模型，同時(shí)也將這些模型存儲(chǔ)在容器或通用軟件包(tar/zip)中，但他們現(xiàn)在也開始為其ML模型采用HuggingFace這樣的原生倉庫。SwiftCargoBowerCranPuppetHuggingfacemlVagrantCargoBowerCranPuppetHuggingfacemlVagrant些公司也開始利用PyPI和ML模型來提供更好的產(chǎn)品。圖3.所使用的軟件編程語言，以及各種軟件包類型的操作次數(shù)、倉庫數(shù)量和存儲(chǔ)的制品總數(shù)（Artifactory數(shù)據(jù)2024JFrog關(guān)鍵要點(diǎn)雖然HuggingFace在JFrog中的使用還處于早期階段，但這標(biāo)志著企業(yè)組織邁出了重要的一步，他們在JFrogPlatform中管理ML模型和其它所有軟件制品，將ML模型開發(fā)引入其安全軟件供應(yīng)鏈。我們的數(shù)據(jù)顯示，在構(gòu)建ML新模型時(shí)廣泛使用的PyPI和Conan等主流軟件包的采用率穩(wěn)步增長。盡管Rust等新型軟件技術(shù)引起了人們的濃厚興趣，但在開發(fā)發(fā)布軟件方面，最受歡迎的軟件技術(shù)并沒有發(fā)生明顯變動(dòng)。Java、Python、JavaScript等生態(tài)系統(tǒng)的勢頭依舊強(qiáng)勁，很多企業(yè)組織選擇繼續(xù)使用他們知道行之有效的技術(shù)。這些新型的編程語言可能還需要一段時(shí)間才能在大企業(yè)中真正站穩(wěn)腳跟。軟件開發(fā)團(tuán)隊(duì)?wèi)?yīng)該使用最適合其項(xiàng)目需求的編程語言。然而，從DevOps和安全的角度來看，每多一種編程語言或包類型，就會(huì)帶來額外的安全風(fēng)險(xiǎn)，增加企業(yè)管理的難度。特別是對大公司來說，如果沒有適當(dāng)?shù)能浖ぞ吆捅O(jiān)控流程，確保安全地使用10多種編程語言可以說是難于登天?；呀?jīng)在生產(chǎn)軟件資產(chǎn)中得到廣泛采用。現(xiàn)在，企業(yè)組織對容器習(xí)以為常，開始轉(zhuǎn)向動(dòng)態(tài)運(yùn)行時(shí)（如Kubernetes一些有遠(yuǎn)見的技術(shù)人員開始部署WebAssembly(WASM)應(yīng)用。相比容器，WebAssembly在特定用例中具有獨(dú)特的優(yōu)勢。2024JFrogLtd.在管理軟件供應(yīng)鏈風(fēng)險(xiǎn)方面，企業(yè)組織面臨著2024JFrogLtd.在特定技術(shù)或軟件包類型中發(fā)現(xiàn)的漏洞高危CVE%（數(shù)量）嚴(yán)重CVE高危CVE%（數(shù)量）嚴(yán)重CVE（數(shù)量）%軟件包類型CVE總數(shù)（數(shù)量）圖4.各種軟件包中發(fā)現(xiàn)的CVE數(shù)量2024JFrogLtd.79：網(wǎng)頁生成時(shí)輸入內(nèi)容未正確中和89：SQL命令中使用的特殊元素未正確中和787：越界寫入352：跨站請求偽造125：越界讀取862：授權(quán)機(jī)制缺失22：對路徑名的限制不恰當(dāng)416：釋放后重引用120：不檢查輸入數(shù)據(jù)大小就復(fù)制緩沖區(qū)78：OS命令中使用的特殊元素未正確中和434：無限制上傳危險(xiǎn)類型的文件77：命令中使用的特殊元素未正確中和20：輸入驗(yàn)證不當(dāng)287：身份驗(yàn)證不當(dāng)863：身份驗(yàn)證錯(cuò)誤476：空指針解引用400：不受控制的資源消耗94：對代碼生成的控制不當(dāng)918：服務(wù)器端請求偽造190：整數(shù)溢出或環(huán)繞圖5.與2022年和2021年相比，2023年發(fā)現(xiàn)的常見漏洞在2023年發(fā)現(xiàn)的漏洞中，到目前為止最常見的通用缺陷(CWE)是那些影響前端的漏洞：跨站腳本、SQL注入和越界寫入。自2021年以來，這三個(gè)漏洞始終躋身前五大最常見的潛在漏洞之列。其中，跨站腳本在CVE中的發(fā)生率繼續(xù)上升，常見漏洞中的排名從2021年的第9位升至2023年的第4回顧過去幾年，我們可以發(fā)現(xiàn)，CWE類型漏洞的同比增長趨勢很容易受到隨機(jī)因素和其它噪音的影響。例如，通過分析過去20年的情況，我們會(huì)發(fā)現(xiàn)更有意義的趨勢：低級(jí)編程語言和高級(jí)編程語言的流行度會(huì)影響內(nèi)存損壞漏洞和高級(jí)web漏洞的數(shù)量。特定相關(guān)軟件技術(shù)的興起也會(huì)產(chǎn)生一定的2024JFrog未指明6.4%原型鏈污染1.4%任意文件覆蓋4.3%腳本代碼注入1.8%本地權(quán)限提升身份驗(yàn)證繞過過濾器繞過數(shù)據(jù)泄露未指明3.7%原型鏈污染1.6%腳本代碼注入4.2%本地權(quán)限提升4.2%身份驗(yàn)證繞過2.6%過濾器繞過數(shù)據(jù)泄露過濾器繞過、數(shù)據(jù)泄漏和腳本代碼注入等漏洞。在對企業(yè)組織的影響方面，遠(yuǎn)程代碼執(zhí)行是攻擊者夢寐以求的漏洞，這個(gè)漏洞比DoS更嚴(yán)重，因?yàn)樗赡芴峁蠖讼到y(tǒng)的完全訪問權(quán)限。與2022年相比，熱門CVE中的主要漏洞排名變化不大，拒絕服務(wù)和遠(yuǎn)程代碼執(zhí)行位居前兩位。相比之下，身份驗(yàn)證繞過漏洞在2023年的流行度大幅降低。如果采用適當(dāng)?shù)膽?yīng)用程序和安全框架，某些漏洞本身并不那么危險(xiǎn)，但是像本地權(quán)限提升和身份驗(yàn)證繞過這樣的漏洞，如果與遠(yuǎn)程代碼執(zhí)行等其他漏洞root權(quán)限的用戶。因此，對系統(tǒng)架構(gòu)的設(shè)計(jì)應(yīng)經(jīng)過深思熟慮，防止越界訪問事件的發(fā)生。圖6.2022和2023年熱門CVE中的常見漏洞類型2024JFrogLtd.軟件供應(yīng)鏈中漏洞的嚴(yán)重程度高危嚴(yán)重低危高危嚴(yán)重高危嚴(yán)重低危月份圖7-1.近兩年內(nèi)按月份和嚴(yán)重程度劃分的CVE（美國國家漏洞數(shù)據(jù)庫，由JFrog安全研究團(tuán)隊(duì)進(jìn)行分析）美國國家漏洞數(shù)據(jù)庫的CVE數(shù)據(jù)顯示，在2022年1月至2023年11月，嚴(yán)重和低危CVE相對來說變化不大，但中危和高危CVE有所增加。圖7-2.近兩年內(nèi)按月份和嚴(yán)重程度劃分的CVE（美國國家漏洞數(shù)據(jù)庫，由JFrog安全研究團(tuán)隊(duì)進(jìn)行分析）2024JFrogCVSS嚴(yán)重程度評(píng)級(jí)嚴(yán)重高危JFrog嚴(yán)重程度嚴(yán)重高危低危不過，并非所有的CVE評(píng)級(jí)都名副其實(shí)。JFrog安全研究團(tuán)隊(duì)定期評(píng)估CVE，以確定其實(shí)際影響并進(jìn)行JFrogJFrog的DevSecOps專家制定，將可利用漏洞的配置要求納入考量。CVSS評(píng)級(jí)只是著眼于漏洞被利用后的嚴(yán)重程度，沒有考慮漏洞的可利用程度。有時(shí)，可利用漏洞的配置要求或利用方法是針對特定軟件包或依賴項(xiàng)的非標(biāo)準(zhǔn)設(shè)置，有可能降低漏洞被利用的可能性。低危圖8.2023年212個(gè)CVE的CVSS評(píng)級(jí)與JFrog嚴(yán)重程度評(píng)級(jí)對比此外，并不是所有的已知漏洞都能被利用。例如，JFrog安全研究團(tuán)隊(duì)發(fā)現(xiàn)，在DockerHub社區(qū)最受歡迎的100個(gè)鏡像，CVSS評(píng)分，（可利用不可利用圖9.在DockerHub社區(qū)最受歡迎的200個(gè)鏡像上嚴(yán)重和高危CVE的可利用性2024JFrogLtd.最危險(xiǎn)的惡意軟件包意外造成的CVE是開源軟件供應(yīng)鏈潛在風(fēng)險(xiǎn)的最大來源，可以采取適當(dāng)?shù)念A(yù)防措施來降低這不一定意味著該軟件包不能使用。也許更為重要的是監(jiān)控和防止惡意軟件包進(jìn)入您的軟件供應(yīng)鏈，因?yàn)榧词怪皇窍螺d這些軟件包也可能使2020上半年2020下半年2021上半年2021下半年2022上半年2022下半年2020上半年2020下半年2021上半年2021下半年2022上半年2022下半年2023上半年有余（從3134增加到6561）。圖10.Npm惡意軟件包數(shù)量同比增長有些惡意軟件包比其它軟件包更危險(xiǎn)JFrog安全研究團(tuán)隊(duì)根據(jù)惡意軟件包對企業(yè)組織的潛在影響及其進(jìn)入軟件供應(yīng)鏈的方式，評(píng)選出了他們認(rèn)為近期值得注意的惡意軟件包。其中各個(gè)惡意軟件包的簡介如下：2023年最危險(xiǎn)的Python惡意最危險(xiǎn)的npm軟件包，部署名為JFrog報(bào)告了有史以來第一個(gè)軟件包，在受害者的設(shè)備上安裝r77的rootkit后門，讓攻擊者可以來源>來源>Infostealer。來源>2024JFrog隱藏在代碼中的其它安全風(fēng)險(xiǎn)首席信息安全官及其團(tuán)隊(duì)知道，您從開源社區(qū)引入的軟件包需要加以重點(diǎn)關(guān)注。JFrog在與首席信息安全官、安全團(tuán)隊(duì)和DevSecOps團(tuán)隊(duì)進(jìn)行交流時(shí)，我們也提醒他們，就應(yīng)用程序的整體安全性而言，開源軟件包并不是唯一一個(gè)需要注意的方面。配置不當(dāng)和錯(cuò)誤——人為失誤的影響2023年，敏感數(shù)據(jù)因?yàn)榉?wù)器不安全、云配置錯(cuò)誤、包含敏感數(shù)據(jù)的文件泄露等原因而在互聯(lián)網(wǎng)上曝光的事件層出不窮。以下總結(jié)了2023年影響最大的配置錯(cuò)誤事件。航空公司CommuteAir的涉恐禁飛名單因?yàn)橐粋€(gè)不安全的服務(wù)器而泄露，這份名單包含150萬條禁飛人員信息。來源>2023年3月證信息泄露。來源>2023年5月Capita發(fā)現(xiàn)存放議會(huì)歷史數(shù)據(jù)（包括福利信息）的服務(wù)器并不安全。來源>2023年7月微軟披露，中國黑客組織Storm-0558利用一系列安全配置錯(cuò)誤，入侵了包括美國政府機(jī)構(gòu)在內(nèi)來源>2023年2月美國特種作戰(zhàn)司令部的內(nèi)部電子郵件因?yàn)榉?wù)器配置錯(cuò)誤而在網(wǎng)上公開曝光，泄露了近兩周的未分類數(shù)據(jù)。來源>2023年4月可公開訪問的DigitalOcean存儲(chǔ)庫而泄露了360萬客戶的敏感數(shù)據(jù)。來源>2023年6月日本汽車制造商豐田汽車公司發(fā)現(xiàn)，豐田互聯(lián)(ToyotaConnected)云配置錯(cuò)誤導(dǎo)致日本26萬名車主的信息泄露。來源>2023年8月旅游業(yè)巨頭Mondee發(fā)現(xiàn)，由于Oracle云服務(wù)器配置錯(cuò)誤，敏感的客戶信息被泄露，包括詳細(xì)的來源>2024JFrogLtd.2023年9月微軟的Xbox文件因?yàn)椤奥?lián)邦貿(mào)易委員會(huì)訴微軟2023年10月微軟因AzureBlobStorage配置錯(cuò)誤致使2.4TB客戶敏感信息泄露，其中包括2017年至2022年8月的文件。來源>2023年9月微軟38TB數(shù)據(jù)的訪問權(quán)限因?yàn)橐粋€(gè)配置錯(cuò)誤的鏈接而意外泄露，使攻擊者可以向微軟人工智來源>2023年11月IT公司Appscook因?yàn)橐粋€(gè)DigitalOcean存儲(chǔ)庫而泄露了未成年人的家庭住址和照片等數(shù)據(jù)。該公司開發(fā)的應(yīng)用程序被印度和斯里蘭卡的600多所學(xué)校使用。來源>泄密情況百萬個(gè)制品：npm、PyPI、RubyGems、crates.io和DockerHub（包括Dockerfiles和小型Docker層）。到目前為止，令牌泄露最多的是AWS、Telegram、GitHub和OpenAI，與2022年的結(jié)果相比新增了OpenAI，這是因?yàn)锳I/ML模型的采用率開始提高。同樣值得注意的是，已泄露機(jī)密的總數(shù)同比有所減少。理想情況下，這個(gè)數(shù)字應(yīng)該更接近于零，因?yàn)閺陌踩慕嵌葋砜矗@是相對容易實(shí)現(xiàn)的目標(biāo)，而且市場上有大量的機(jī)密檢測工具。aws_accesstelegramtokengithubopenaisendgridtwiliogoogle_authnpmgitlabv2digitaloceanspacesalibaba_ossslackgithub_oldshopifyPyPIplanetscale_passwordsendinbluev2mailchimpflutterwavejenkins_token圖11.2023年最常見的公開泄露訪問令牌2024JFrog關(guān)鍵要點(diǎn)每年應(yīng)對26,000多個(gè)新CVE，可能會(huì)拖慢開發(fā)進(jìn)度，導(dǎo)致開發(fā)人員和安全人員不堪重負(fù)。軟件中有CVE并不一定意味著存在安全問題。開發(fā)和安全團(tuán)隊(duì)在確定需要優(yōu)先解決哪些CVE時(shí)，CVE評(píng)級(jí)可能不是最佳指標(biāo)。在上下文分析中理解CVE的作用機(jī)制和運(yùn)行原理，能夠令開發(fā)人員專注于更有價(jià)值的事情而不是修補(bǔ)漏洞。每年都能在公共注冊表中發(fā)現(xiàn)數(shù)以千計(jì)的公司令牌。在工作之余或個(gè)人開發(fā)項(xiàng)目期間，從事開源項(xiàng)目的開發(fā)人員可能會(huì)泄露公司機(jī)密。即使是簡單的錯(cuò)誤也可能導(dǎo)致公司令牌出現(xiàn)在公共倉庫中（例如使用您的企業(yè)Slack認(rèn)證密鑰而不是您軟件工具和監(jiān)控流程可以為企業(yè)組織解決這個(gè)問題。有關(guān)更多信息，請參見我們前端漏洞有很多，但后端漏洞才是真正令人在2023年的所有CVE中，“前端漏洞”仍然是最常見的CWE（即跨站腳本、SQL注入、越界寫入、跨站請求偽造等但也是最容易發(fā)現(xiàn)和修復(fù)的漏洞。盡管人們越來越意識(shí)到與內(nèi)存安全問題相關(guān)的風(fēng)險(xiǎn)，美國政府甚至就此發(fā)出警告，但緩沖區(qū)溢出漏洞仍在繼續(xù)增加。這可能表明，企業(yè)組織在移植和更新遺留代碼（通常是C、Go和Python）以使用Rust、Java、JavaScript等內(nèi)存安全語言時(shí)遇到了困難。2024JFrogLtd.安全防范意識(shí)已經(jīng)達(dá)成共識(shí)：89%的受訪者表示，他們的企業(yè)組織采用了OpenSSF或SLSA等安全框架。關(guān)于企業(yè)組織如何應(yīng)用安全措施以及將其用于何處的問題，調(diào)查結(jié)果千差萬2024JFrogLtd.企業(yè)組織需要在哪個(gè)階段進(jìn)行安全掃描隨著軟件供應(yīng)鏈的日益成熟，新的漏洞會(huì)逐漸被發(fā)現(xiàn)。在編碼階段看起來安全，并不意味著在運(yùn)行時(shí)也是安全的。因此，大多數(shù)企業(yè)組織都在其軟件開發(fā)生命周期(SDLC)的各個(gè)階段進(jìn)行您覺得在軟件開發(fā)生命周期中，最好是在哪個(gè)階段采取安全措施？最希望最不希望最希望2024JFrogLtd.您的企業(yè)組織通常在開發(fā)的哪個(gè)階段進(jìn)行安全掃描選擇所有適用項(xiàng)）編碼時(shí)和構(gòu)建時(shí)構(gòu)建時(shí)和運(yùn)行時(shí)構(gòu)建時(shí)和發(fā)布前編碼時(shí)和發(fā)布前編碼時(shí)和運(yùn)行時(shí)發(fā)布前和運(yùn)行時(shí)企業(yè)組織通常進(jìn)行安全掃描的開發(fā)階段是編碼時(shí)(59%)、的行業(yè)趨勢，但數(shù)據(jù)顯示，企業(yè)組織也認(rèn)識(shí)到需要向軟件生命周期的右側(cè)掃描。您的企業(yè)組織是否在源代碼或二進(jìn)制文件層面進(jìn)行安全掃描？源代碼和二進(jìn)制文件掃描超過半數(shù)的受訪者(56%)表示，他件層面進(jìn)行安全掃描。僅代碼掃描超過四分之一的受訪者(27%)表僅二進(jìn)制文件掃描2024JFrogLtd.掃描的類型和所用的工具大多數(shù)企業(yè)組織都有適當(dāng)?shù)陌踩鉀Q方案，但由于自動(dòng)化代碼掃描的缺位以及使用多種安全掃描工具所帶來的混亂，開發(fā)人員的生產(chǎn)力和效率顯然會(huì)受到影響。在一個(gè)月里，修復(fù)漏洞的工作會(huì)占用開發(fā)供應(yīng)鏈，在安全解決方案覆蓋面或最佳修復(fù)操作可見性方面留下了嚴(yán)重的缺口。您的企業(yè)組織是否有適當(dāng)?shù)陌踩鉀Q方案來檢測惡意開源軟件包？的專業(yè)人員表示，他們的企業(yè)組織有適當(dāng)?shù)陌踩鉀Q方案來檢測惡意開源軟件包。使用的單點(diǎn)式應(yīng)用程序安全解決方案數(shù)量近半數(shù)的受訪者(47%)表示，他們的企業(yè)組織正在使用4到9種單點(diǎn)式應(yīng)用程序安全解決方案。三分之一的受訪者(33%)表示，他們的企業(yè)組織正在使用10種或更多的單點(diǎn)式應(yīng)用程序安全解決方案。2024JFrogLtd.您的企業(yè)組織正在使用什么類型的單點(diǎn)式應(yīng)用程序安全解決方案？進(jìn)一步分析顯示，單點(diǎn)式應(yīng)用程序安全解決方案的受歡迎程度因受訪者的工作職責(zé)而異：2024JFrog手動(dòng)代碼審查和自動(dòng)代碼掃描在軟件開發(fā)流程中的占比分別是多少？0%手動(dòng)/25%手動(dòng)/25%手動(dòng)/75%手動(dòng)/50%手動(dòng)/75%不到1%的受訪者表示，他們在軟件開發(fā)流程中，已完全實(shí)現(xiàn)自動(dòng)化代碼掃描。只有19%的受訪者表示，他們的代碼審查75%是自動(dòng)，另外25%是手動(dòng)。修復(fù)安全漏洞耗時(shí)多久到2026年，全球軟件供應(yīng)鏈安全風(fēng)險(xiǎn)預(yù)計(jì)將造成806億美元的損失。企業(yè)組織花費(fèi)時(shí)間和資金來提前采取安全防范措施顯然是合理的。雖然將新功能快速推向市場是有效的競爭優(yōu)勢，但企業(yè)組織必須權(quán)衡采取安全防范措施對企業(yè)生產(chǎn)力和新功能發(fā)布的作用。在一個(gè)月內(nèi)，您的開發(fā)人員或安全團(tuán)隊(duì)通常需要花費(fèi)多少時(shí)間來修復(fù)應(yīng)用程序漏洞？這意味著四分之一的工作時(shí)間被用于修復(fù)漏洞，而不是從事能夠提高商業(yè)價(jià)值的任務(wù)。天這意味著四分之一的工作時(shí)間被用于修復(fù)漏洞，而不是從事能夠提高商業(yè)價(jià)值的任務(wù)。天的時(shí)間來修復(fù)應(yīng)用程序漏洞。2024JFrogLtd.由誰來管理最新版的軟件包、庫和框架的獲取過程，是安全人員還是開發(fā)人員？（選擇所有適用項(xiàng)）安全團(tuán)隊(duì)開發(fā)團(tuán)隊(duì)DevOps團(tuán)隊(duì)安全團(tuán)隊(duì)開發(fā)團(tuán)隊(duì)進(jìn)一步的分析顯示，在管理最新版的軟件包、庫和框架的獲取過程方面，IT、IS和其他技術(shù)部門中沒有哪一個(gè)團(tuán)隊(duì)處于主導(dǎo)地位。平均而言，受訪者確定了2個(gè)團(tuán)隊(duì)(M=1.95)負(fù)責(zé)管理調(diào)取過程。認(rèn)為安全團(tuán)隊(duì)、開發(fā)團(tuán)隊(duì)和DevOps團(tuán)隊(duì)負(fù)責(zé)管理此過程的受訪者比例相差不大。通常需要多長時(shí)間才能獲得批準(zhǔn)使用最新的軟件包/庫？超過半數(shù)的受訪者(58%)表示，獲得批準(zhǔn)使用最新的軟件包/庫通常需要6天或更短時(shí)間。另一方面，一些受訪者給出了更長的批準(zhǔn)等待時(shí)間。五分之二(40%)的受訪者表示，通常需要一周或更長時(shí)間才能獲得批準(zhǔn)使用最新的軟件包/庫。2024JFrogLtd.關(guān)鍵要點(diǎn)超過四分之一的受訪者(27%)表示，他們的企業(yè)組織僅在代碼層面進(jìn)行安全掃描。然而，如果認(rèn)為在編寫代碼到將其投入到生產(chǎn)環(huán)境之間，代碼情況不會(huì)發(fā)生任何變化，這將帶來災(zāi)難性的后果。就“采取安全措施的最佳階段”而言，排名最后的是在跨SDLC階段（從質(zhì)量保證到試運(yùn)行）晉級(jí)軟件時(shí)進(jìn)行安全掃描。隨著軟件在SDLC的各個(gè)階段日趨成熟，如果不能自動(dòng)地逐步掃描軟件，就難以盡早發(fā)現(xiàn)新的漏洞和問題。大多數(shù)受訪者都是結(jié)合使用手動(dòng)代碼審查和自動(dòng)掃描代碼。隨著新技術(shù)的出不是手動(dòng)代碼審查的替代品，但如果沒有它，您幾乎肯定會(huì)錯(cuò)過某些漏洞。此外，純手動(dòng)代碼審查是難以擴(kuò)大監(jiān)控規(guī)模的。您需要保護(hù)您的SDLC，但這必須以一種無縫的方式進(jìn)行。在安全任務(wù)上花費(fèi)不必要的時(shí)間，篩選來自多種掃描器的結(jié)果，等待數(shù)天或數(shù)周時(shí)間才能獲準(zhǔn)使用新的軟件包或庫，這些都是在浪費(fèi)重要的開發(fā)時(shí)間。想要在不影響生產(chǎn)力的情況下保護(hù)軟件供應(yīng)鏈，關(guān)鍵點(diǎn)是簡化使用新軟件包和修復(fù)漏洞的審批流程，實(shí)現(xiàn)監(jiān)控管理策略自動(dòng)化、將安全掃描置于上下文分析中，以及將安全洞察直接引入到開發(fā)環(huán)境。這進(jìn)一步促進(jìn)了整合軟件工具、遠(yuǎn)離單點(diǎn)式解決方案的市場大趨勢。2024JFrogLtd.容、代碼的編寫方式以及軟件應(yīng)用程序的保護(hù)方式產(chǎn)生深遠(yuǎn)影響。根據(jù)2024JFrogLtd.您的企業(yè)組織是否采取了安全措施/解決方案來檢查開源ML模型的安全性和合規(guī)性？的受訪者表示，他們的企業(yè)組織正在采取安全措施/解決方案來檢查開源ML機(jī)器學(xué)習(xí)模型的安全性和如今，能夠在這方面提供幫助的軟件工具非常少，但是企業(yè)組織可以采取一些手動(dòng)防范措施，例如根據(jù)發(fā)行商、評(píng)級(jí)等指標(biāo)來評(píng)估ML模型。您的企業(yè)組織是否使用AI/ML應(yīng)用來協(xié)助進(jìn)行安全掃描或漏洞修復(fù)？沒有是的，用于掃描用于修復(fù)沒有是的，用于掃描用于修復(fù)用于掃描和修復(fù)在某種程度上使用用于掃描和修復(fù)十分之九的受訪者(90%)表示，他們的企業(yè)組織在某種程度上使用AI/ML應(yīng)用來協(xié)助進(jìn)行安全掃描或漏洞修復(fù)。略超半數(shù)的受訪者(51%)表示，他們的企業(yè)組織使用機(jī)器學(xué)習(xí)來協(xié)助進(jìn)行掃描和修復(fù)。然而，如果根據(jù)受訪者的角色類型對這些數(shù)據(jù)進(jìn)行細(xì)分，情況就會(huì)大為不同。2024JFrogLtd.角色角色是（凈值）否（凈值）是的，用于掃描是的，用于修復(fù)是的，同時(shí)用于掃描和修復(fù)沒有沒有，但我覺得以后會(huì)與C級(jí)高管(4%；n=272)相比，更多的個(gè)人貢獻(xiàn)者(22%；n=115)表示，他們的企業(yè)組織沒有使用AI/ML應(yīng)用來協(xié)助進(jìn)行安全掃描或漏洞修復(fù)，但認(rèn)為他們的企業(yè)組織應(yīng)該這樣做。這表明，C級(jí)領(lǐng)導(dǎo)者認(rèn)為正在使用的工具與日常工作中實(shí)際使用的工具存在明顯偏差。您的企業(yè)組織是否允許開發(fā)人員使用AI/ML應(yīng)用來協(xié)助編寫代碼？僅限研究目的僅限研究目的用于編寫代碼出于安全和合規(guī)考慮大約六分之一的受訪者(17%)表示，大約六分之一的受訪者(17%)表示，織不允許開發(fā)人員使用AI/ML應(yīng)用來編寫代碼。的受訪者(32%)表示，他們的企業(yè)組織允許使用AI/ML應(yīng)用來編寫代碼。2024JFrogLtd.關(guān)鍵要點(diǎn)如今的企業(yè)組織更多地將AI工具用于安全工作，而不是用于生成全新代碼。也許他們覺得，將AI工具用于安全工作能夠提升效率，即使不是100%準(zhǔn)確，但也是值得的，而AI應(yīng)用引入新漏洞、惡意軟件包或非許可代碼/包的風(fēng)險(xiǎn)太大了。在為了幫助保護(hù)您的軟件供應(yīng)鏈，JFrog安全研究團(tuán)隊(duì)建議從SDLC的初始階段就將安全融入到您的流程中，方法包括手動(dòng)審查AI工具生成的代碼，以及使用自動(dòng)化安全解決方案，比如SAST就能夠可靠地發(fā)現(xiàn)漏洞。想要確保軟件的安全性并負(fù)責(zé)任地使用AI技術(shù)，這種主動(dòng)的監(jiān)測方法非常重要。正如本報(bào)告的上一章節(jié)所述，企業(yè)組織使用了許多安全工具?？紤]到AI/ML安全工具可能只占到所用安全工具的十分之一，不妨在工具箱中再添加一個(gè)AI/ML安全際影響，而不是聽信天花亂墜的宣傳，喪失警惕性。企業(yè)對AI/ML嵌入式軟件的需求不斷增長，您的開發(fā)人員可能已經(jīng)把ML模型作為新版應(yīng)用程序的一部分。ML模型的開發(fā)和使用現(xiàn)在可能感覺有點(diǎn)像“狂野取ML模型使用的安全最佳實(shí)踐，例如掃描開源ML模2024JFrogLtd.析結(jié)果以及第三方委托調(diào)查數(shù)據(jù)。以下是對本報(bào)告中強(qiáng)調(diào)的技術(shù)使用趨勢來自