近十年來，《開源安全和風(fēng)險(xiǎn)分析（OSSRA）報(bào)告》的主題一直是“你知道自己的代碼中有什么嗎？”在2024年，這個(gè)問題變得比以往任何時(shí)候都更加重要。隨著開源的流行和人工智能生成代碼的增加，越來越多的應(yīng)用程序現(xiàn)在使用第三方代碼構(gòu)建。

如果缺乏對(duì)代碼內(nèi)容的完整視圖，那么無論是企業(yè)、供應(yīng)商還是最終用戶都無法確定軟件中可能包含哪些風(fēng)險(xiǎn)。而確保軟件供應(yīng)鏈安全的先決條件是要知道代碼中有哪些開源組件，以及確定它們各自的許可證、代碼質(zhì)量和潛在漏洞。

Synopsys最新發(fā)布的《2024年開源安全和風(fēng)險(xiǎn)分析（OSSRA）報(bào)告》深入研究了商業(yè)軟件中開源安全、合規(guī)性、許可和代碼質(zhì)量風(fēng)險(xiǎn)的當(dāng)前狀態(tài)，強(qiáng)調(diào)了開源軟件的流行以及管理不當(dāng)?shù)臐撛谖ｋU(xiǎn)，旨在幫助安全、法律、風(fēng)險(xiǎn)和開發(fā)團(tuán)隊(duì)更好地理解開源安全和許可風(fēng)險(xiǎn)環(huán)境。

重點(diǎn)發(fā)現(xiàn)

96%的代碼庫涉及開源；53%的代碼庫包含許可沖突；31%的代碼庫包含沒有許可或自定義許可的開源代碼；2023年掃描了1067個(gè)代碼庫，并對(duì)936個(gè)代碼庫進(jìn)行了風(fēng)險(xiǎn)評(píng)估，結(jié)果顯示84%的代碼庫存在漏洞風(fēng)險(xiǎn)；且在這部分代碼庫中有高達(dá)74%包含高風(fēng)險(xiǎn)漏洞；14%的代碼庫存在超過10年的漏洞；代碼庫中漏洞的平均年齡為2.8年；在接受風(fēng)險(xiǎn)評(píng)估的代碼庫中，有49%的組件在過去24個(gè)月內(nèi)沒有開發(fā)活動(dòng)；有1%的組件落后于代碼維護(hù)者更新/補(bǔ)丁至少12個(gè)月；有91%的組件比當(dāng)前版本落后10個(gè)或更多版本。

開源漏洞和安全

在Synopsys公司Black Duck 審計(jì)服務(wù)團(tuán)隊(duì)分析的1067個(gè)代碼庫中，96%涉及開源，這些代碼庫被用作今年OSSRA報(bào)告的基礎(chǔ)數(shù)據(jù)。

分析結(jié)果顯示，在接受風(fēng)險(xiǎn)評(píng)估的936個(gè)代碼庫中，有高達(dá)84%的代碼庫至少包含一個(gè)已知的開源漏洞。更糟糕的是，在這部分代碼庫中有74%包含高風(fēng)險(xiǎn)漏洞。這一比例與2022年相比有顯著增長，當(dāng)時(shí)只有48%的代碼庫被發(fā)現(xiàn)包含高風(fēng)險(xiǎn)漏洞。這里的“高風(fēng)險(xiǎn)漏洞”指的是那些已被積極利用、已有文檔證明的概念驗(yàn)證（PoC）漏洞，或是被歸類為遠(yuǎn)程代碼執(zhí)行的漏洞。

數(shù)據(jù)顯示，2022年至2023年間，高風(fēng)險(xiǎn)漏洞增加了54%，而造成這種情況的原因暫無定論。一個(gè)可能的解釋是經(jīng)濟(jì)衰退和隨之而來的裁員，減少了可用于定位和修補(bǔ)漏洞的資源數(shù)量。此外，分析還發(fā)現(xiàn)91%的代碼庫所包含的組件比當(dāng)前可用版本落后10個(gè)或更多版本。簡單的結(jié)論是，絕大多數(shù)開源用戶根本不更新他們使用的組件。

這一推斷也得到了數(shù)據(jù)證實(shí)：49%的代碼庫組件在過去24個(gè)月內(nèi)沒有過開發(fā)活動(dòng)，1%的組件至少落后于代碼維護(hù)者更新/補(bǔ)丁12個(gè)月。

（廣義地說，術(shù)語“維護(hù)者”指的是那些領(lǐng)導(dǎo)開源項(xiàng)目的貢獻(xiàn)者。他們可能是構(gòu)建或發(fā)布源代碼的最終決策者；可能負(fù)責(zé)所有的代碼審查，并以他們的名義托管較小項(xiàng)目的代碼；也可能對(duì)項(xiàng)目的方向做出最終決定。他們的日常工作可能有所不同，但都包括審查拉取請(qǐng)求和其他貢獻(xiàn)，發(fā)布新版本的軟件，分類和處理安全修復(fù)，以及社區(qū)管理和審核。）

大多數(shù)維護(hù)者都很努力地讓他們參與的開源項(xiàng)目保持最新。事實(shí)上，許多公司專門雇人來維護(hù)公司軟件所依賴的開源項(xiàng)目。不過很顯然，同樣的努力并未體現(xiàn)在開源用戶身上。為此，開源用戶需要了解他們正在使用的版本，建立一個(gè)定期的更新節(jié)奏，并落實(shí)軟件衛(wèi)生實(shí)踐。

TOP 10漏洞中有8個(gè)與CWE-707有關(guān)

【Top 10 CVE大多與CWE-707有關(guān)】

如上圖所示，CWE-707是CWEs 20、79、80、97、937的支柱。CWE -707關(guān)注的是在從上游組件讀取數(shù)據(jù)或發(fā)送到下游組件之前未滿足的安全要求。如果不能正確中和輸入，可能會(huì)導(dǎo)致跨站點(diǎn)腳本（XSS）和SQL注入等漏洞利用。XSS是一種常見且危險(xiǎn)的漏洞利用，與本報(bào)告中突出顯示的十大漏洞中的大多數(shù)有關(guān)。

跨站腳本攻擊是指攻擊者利用網(wǎng)站的漏洞，發(fā)送惡意的、格式錯(cuò)誤的代碼（通常用JavaScript編寫）。由于該輸入沒有被正確中和或轉(zhuǎn)譯，因此攻擊者可以操縱原本值得信任的主機(jī)執(zhí)行惡意任務(wù)。不過，大多數(shù)XSS攻擊的最終目標(biāo)并不是主機(jī)本身，而是web應(yīng)用程序的其他用戶。一旦惡意腳本被注入，它就可以用來竊取敏感信息，比如會(huì)話cookie。

XSS不僅存在于此份十大漏洞列表中，它也是OWASP十大漏洞列表中的漏洞之一。在其列表中，OWASP將XSS稱為A03：2021 -注入。XSS漏洞流行的原因可以歸功于越來越依賴基于Web的應(yīng)用程序作為組織與客戶交互的方式。

同樣地，數(shù)據(jù)清楚地表明，開發(fā)團(tuán)隊(duì)需要在保持開源組件更新方面有所改進(jìn)，特別是在涉及流行的開源組件（如jQuery）時(shí)。使用舊的、更脆弱的開源版本的后果可能是嚴(yán)峻的。例如，在審計(jì)中發(fā)現(xiàn)的十大漏洞中排名第二的是CVE-2020-11022，這是jQuery 1.2到3.5.0版本中的XSS漏洞。該漏洞允許將受信任來源的HTML傳遞給jQuery的DOM操作方法，并且可能會(huì)執(zhí)行不受信任的代碼。

這個(gè)問題在jQuery 3.5.0中得到了修補(bǔ)，但正如研究數(shù)據(jù)所示，在評(píng)估代碼庫安全風(fēng)險(xiǎn)時(shí)，發(fā)現(xiàn)三分之一的代碼庫使用的仍然是易受攻擊的jQuery版本。

jQuery并非天生不安全。事實(shí)上，它是一個(gè)維護(hù)良好的開源庫，擁有大量的用戶、開發(fā)人員和維護(hù)人員社區(qū)。不過，這種流行度和廣泛的用戶基礎(chǔ)也帶來了安全問題。根據(jù)審計(jì)，jQuery是最有可能存在漏洞的組件，盡管本報(bào)告中列出的每個(gè)jQuery漏洞都有可用的補(bǔ)丁。對(duì)于jQuery用戶（實(shí)際上是所有開源的用戶）來說，重要的是要意識(shí)到與舊版本軟件相關(guān)的潛在安全風(fēng)險(xiǎn)，并采取措施緩解這些風(fēng)險(xiǎn)。

采取行動(dòng)防止漏洞進(jìn)入軟件供應(yīng)鏈

創(chuàng)建并維護(hù)軟件物料清單（SBOM）。在與軟件供應(yīng)鏈攻擊的斗爭中，擁有一個(gè)準(zhǔn)確的、最新的、列出開源組件的SBOM是評(píng)估暴露并確保代碼保持高質(zhì)量、兼容和安全的關(guān)鍵。全面的SBOM列出了應(yīng)用程序中的所有開源組件，以及這些組件的許可證、版本和補(bǔ)丁狀態(tài)——這是對(duì)供應(yīng)鏈攻擊（包括使用惡意包的攻擊）的有力防御。隨時(shí)了解情況。確保能夠及時(shí)了解新發(fā)現(xiàn)的惡意軟件包、惡意軟件和公開的開源漏洞。查找新聞提要或定期發(fā)布的建議，獲悉有關(guān)影響SBOM中開源組件的問題的可操作建議和詳細(xì)信息。執(zhí)行代碼審查。在將下載的軟件納入項(xiàng)目之前，先仔細(xì)檢查它的代碼以獲悉任何已知的漏洞。要了解更多信息，請(qǐng)考慮對(duì)源代碼進(jìn)行靜態(tài)分析，以檢查未知的安全弱點(diǎn)。使用自動(dòng)化軟件組合分析（SCA）工具。SCA工具自動(dòng)化了軟件安全問題的識(shí)別、管理和緩解過程，并允許開發(fā)人員將精力集中在編寫代碼上。這樣的工具可以評(píng)估開源代碼和第三方代碼。

行業(yè)漏洞風(fēng)險(xiǎn)

與計(jì)算機(jī)硬件和半導(dǎo)體行業(yè)相關(guān)的88%的代碼庫包含高風(fēng)險(xiǎn)漏洞（嚴(yán)重程度評(píng)分為7或更高），緊隨其后的是制造業(yè)、工業(yè)、機(jī)器人;零售和電子商務(wù)，分別為87%和84%。

每個(gè)行業(yè)都有類似的發(fā)現(xiàn)，即使是航天、航空、汽車、運(yùn)輸、物流等占比最低的行業(yè)同樣令人不安，因?yàn)檫@些行業(yè)仍有三分之一的代碼庫包含高風(fēng)險(xiǎn)漏洞。如下圖所示，接受評(píng)估的每個(gè)行業(yè)代碼庫中都涉及開源；它構(gòu)成了每個(gè)行業(yè)部門的大部分代碼庫。更糟糕的是，這些代碼庫還包含大量已知的開源漏洞，這些漏洞未得到及時(shí)修補(bǔ)，使其非常易被濫用。

【代碼庫中包含高危漏洞的行業(yè)比例】

開源許可

有效的軟件供應(yīng)鏈管理需要許可以及安全遵從性。企業(yè)正在使用開源組件和庫來構(gòu)建軟件，并且知道這些組件受開源許可證的管理，但是企業(yè)知道這些許可證的詳細(xì)信息嗎？要知道，即使軟件中有一個(gè)不兼容的許可證也會(huì)導(dǎo)致法律問題、知識(shí)產(chǎn)權(quán)損失、耗時(shí)的補(bǔ)救工作以及產(chǎn)品延遲上市等后果。Black Duck審計(jì)服務(wù)團(tuán)隊(duì)發(fā)現(xiàn)，在接受審計(jì)的代碼庫中，超過一半（53%）涉及許可沖突問題。

【代碼庫中發(fā)現(xiàn)的TOP10許可比例】

在Black Duck審計(jì)服務(wù)團(tuán)隊(duì)于2023年審計(jì)的開源軟件中，有92%的開源軟件使用了MIT許可證。作為一個(gè)允許在專有軟件中重用的寬松許可證，MIT許可證與其他軟件許可證具有高兼容性和低風(fēng)險(xiǎn)。

應(yīng)該注意的是，諸如“低風(fēng)險(xiǎn)”這樣的術(shù)語只是一個(gè)指導(dǎo)原則，不應(yīng)該用來決定是否使用每個(gè)許可證管理的開源軟件。例如，雖然Apache 2軟件（通常被認(rèn)為使用低風(fēng)險(xiǎn)許可證）可以包含在GNU通用公共許可證3.0（GPLv3）下的項(xiàng)目中，但GPLv3軟件不能包含在Apache項(xiàng)目中。在這種情況下，由于Apache軟件基金會(huì)的許可哲學(xué)和GPLv3作者對(duì)版權(quán)法的解釋，許可證是不兼容的。對(duì)于開發(fā)人員來說，最安全的策略是咨詢他們的公司政策和法律團(tuán)隊(duì)，以獲得有關(guān)許可證遵從性的具體指導(dǎo)。

調(diào)查發(fā)現(xiàn)，知識(shí)共享許可是導(dǎo)致許可沖突最普遍的原因。僅CC-SA 3.0就導(dǎo)致了17%的已確定的許可沖突。

“代碼片段”（Snippets）——被復(fù)制粘貼到源代碼中的代碼行到處可見。它們通常來自流行的博客網(wǎng)站Stack Overflow，該網(wǎng)站自動(dòng)將所有可公開訪問的用戶貢獻(xiàn)以知識(shí)共享方式分享。不幸的是，“一攬子許可”（blanket license）還包括發(fā)布在網(wǎng)站上的代碼片段。我們說“很遺憾”，因?yàn)檫@些許可協(xié)議不是針對(duì)軟件的，這一點(diǎn)在其常見問題中有明確的說明：“我們建議不要對(duì)軟件使用知識(shí)共享許可協(xié)議?！痹谀承┣闆r下，CC-SA許可證可以被理解為具有與GNU公共許可證類似的“病毒”效應(yīng)（即，從copyleft許可的作品派生的任何作品也必須在相同的copyleft條款下進(jìn)行許可），而且從法律角度來看，這可能會(huì)成為一個(gè)問題。

了解許可證風(fēng)險(xiǎn)

在美國和許多其他司法管轄區(qū)，創(chuàng)造性作品（包括軟件）默認(rèn)受獨(dú)家版權(quán)保護(hù)。沒有創(chuàng)作者/作者的明確許可，任何人都不能合法地使用、復(fù)制、分發(fā)或修改該軟件。

即使是最友好的開源許可證也包括用戶在使用該軟件時(shí)所承擔(dān)的義務(wù)。當(dāng)代碼庫所涉開源代碼的許可與代碼庫的整體許可發(fā)生沖突時(shí)，潛在的許可風(fēng)險(xiǎn)就會(huì)出現(xiàn)。GNU通用公共許可證（GPL）是應(yīng)用于開源項(xiàng)目的最常見的copyleft許可證。當(dāng)以GPL許可的代碼包含在商業(yè)閉源軟件中時(shí)，可能會(huì)出現(xiàn)沖突。

標(biāo)準(zhǔn)開源許可證的變體或定制版本可能對(duì)被許可方提出要求，并且需要對(duì)可能的知識(shí)產(chǎn)權(quán)問題或其他影響進(jìn)行法律評(píng)估。JSON許可證是自定義許可證的一個(gè)主要示例?；趯捤傻腗IT許可證，JSON許可證增加了“軟件應(yīng)用于善，而非惡”的限制。這一聲明的模糊性使其含義有待解釋，許多律師會(huì)建議不要使用如此許可的軟件，特別是在并購場景的背景下。

在接受審計(jì)的代碼庫中，有31%使用的代碼要么沒有可識(shí)別的許可，要么使用定制的許可，這與去年的調(diào)查結(jié)果幾乎相同。造成這種情況的一個(gè)常見原因是開發(fā)人員使用代碼片段，但卻沒有帶來代碼片段的相關(guān)許可。另一個(gè)原因是越來越多地使用AI輔助編碼工具。

【包含許可沖突的代碼庫比例（按行業(yè)劃分）】

如上所示，多個(gè)行業(yè)部門具有非常高比例的開源許可風(fēng)險(xiǎn)。造成這種情況的原因可能包括以下幾點(diǎn)：

許多存在大量沖突的行業(yè)傾向于將其軟件作為本地產(chǎn)品進(jìn)行許可和分發(fā)。許多限制性許可證專門適用于以這種方式分發(fā)的軟件。其他數(shù)量較少的行業(yè)可能會(huì)進(jìn)行基于訂閱或SaaS類型的部署，這些部署傳統(tǒng)上不被認(rèn)為是“分發(fā)”，也不受相同許可條款的約束。半導(dǎo)體和硬件公司嚴(yán)重依賴軟件和固件，其中大部分包含開源代碼。復(fù)雜的片上系統(tǒng)（system-on-a-chip）設(shè)計(jì)可能有來自不同來源的數(shù)百萬行代碼。在這種規(guī)模上跟蹤許可和義務(wù)可能是一項(xiàng)挑戰(zhàn)。開源在底層系統(tǒng)軟件、固件、驅(qū)動(dòng)程序中非常普遍，這些都是硬件產(chǎn)品不可或缺的一部分。其中大部分都是在GPL類型的“copyleft”許可下進(jìn)行的，如果發(fā)布，則有很強(qiáng)的共享要求。固件、驅(qū)動(dòng)程序和工具在公司之間以及硬件設(shè)計(jì)師和制造商之間的軟件供應(yīng)鏈共享導(dǎo)致了開源傳播，無需通過SBOM清單跟蹤來源或許可。

軟件供應(yīng)鏈治理中開源許可證管理的最佳實(shí)踐

對(duì)軟件中的所有第三方軟件組件（包括開源軟件和商業(yè)軟件）進(jìn)行徹底的盤點(diǎn)。人工智能輔助編碼工具可能會(huì)產(chǎn)生違反許可和侵犯知識(shí)產(chǎn)權(quán)的代碼。評(píng)估每個(gè)組件的許可條款和條件，并評(píng)估它們是否與產(chǎn)品的預(yù)期用途兼容。檢查不同組件的許可之間的兼容性，因?yàn)橛行┙M件的許可可能不兼容。使用自動(dòng)掃描工具來識(shí)別和跟蹤每個(gè)組件的許可義務(wù)和限制。實(shí)施一個(gè)流程，以確保持續(xù)的許可合規(guī)性，包括定期的許可證掃描和許可證合規(guī)程序的定期審查。為新的或不熟悉的許可證建立審查流程和工作流程。確保法律、技術(shù)和業(yè)務(wù)利益相關(guān)者之間的有效溝通，以適當(dāng)?shù)貎?yōu)先考慮和執(zhí)行許可清除。記錄所有許可證審批活動(dòng)，包括許可證評(píng)估和合規(guī)程序，以確保合規(guī)工作的記錄，并為未來的審核提供便利。

影響開源風(fēng)險(xiǎn)的操作因素

理想情況下，開源消費(fèi)者只使用安全的社區(qū)支持的組件。例如，來自數(shù)百個(gè)組織的數(shù)千名開發(fā)人員每天都在改進(jìn)Linux。然而，在Black Duck審計(jì)服務(wù)團(tuán)隊(duì)檢查的936個(gè)代碼庫中，49%的開源代碼在過去兩年中沒有過開發(fā)活動(dòng)。如果一個(gè)項(xiàng)目不再被維護(hù)——特別是在較小的項(xiàng)目中——就沒有功能升級(jí)，沒有代碼改進(jìn)，也無法修復(fù)發(fā)現(xiàn)的安全問題。

這在開源項(xiàng)目中并不少見。根據(jù)一些報(bào)告，在2022年維護(hù)的近20%的Java和javascript開源項(xiàng)目將在2023年不再維護(hù)，這使得這些項(xiàng)目易受漏洞影響。開源很大程度上是志愿者、貢獻(xiàn)者和維護(hù)者的產(chǎn)物。雖然像微軟、紅帽和谷歌這樣的一些組織有激勵(lì)計(jì)劃來激勵(lì)開源項(xiàng)目的維護(hù)和參與，但絕大多數(shù)公司都沒有。當(dāng)維護(hù)人員停止維護(hù)項(xiàng)目時(shí)，一個(gè)顯而易見的后果就是安全風(fēng)險(xiǎn)會(huì)隨之升高。

開源用戶需要改進(jìn)維護(hù)實(shí)踐

在Black Duck審計(jì)服務(wù)團(tuán)隊(duì)檢查的936個(gè)代碼庫中，91%的組件比最新版本落后10個(gè)或更多版本。

造成這種情況的原因可能是時(shí)間/資源的問題。由于許多團(tuán)隊(duì)都在把主要精力用于構(gòu)建和測(cè)試新代碼，因此更新現(xiàn)有軟件的優(yōu)先級(jí)可能會(huì)降低。Synopsys《2023年全球開發(fā)安全運(yùn)營狀況》報(bào)告發(fā)現(xiàn)，在對(duì)1000名IT安全專業(yè)人士的調(diào)查中，28%的人表示他們的組織需要長達(dá)三周的時(shí)間來修補(bǔ)已部署應(yīng)用程序中的關(guān)鍵安全風(fēng)險(xiǎn)/漏洞，另有20%的人表示可能需要長達(dá)一個(gè)月的時(shí)間。這些數(shù)字適用于所有的漏洞，包括專有的、商業(yè)的、第三方的軟件以及開源軟件。

正如OSSRA在近十年的報(bào)告中所指出的那樣，開源不同于商業(yè)軟件——不是更差，也不是更好，而是不同——而且它需要不同的技術(shù)來管理。例如，商業(yè)軟件和開源軟件的補(bǔ)丁處理方式就大不相同。作為供應(yīng)商管理計(jì)劃的一部分，購買商業(yè)軟件通常需要進(jìn)行一些審查。另一方面，開源代碼可能只是根據(jù)開發(fā)人員的判斷下載的，在此過程中可能會(huì)有一些組織防護(hù)措施——例如，只使用具有許可許可的代碼——但是在許多組織中，甚至不存在這樣的指導(dǎo)。

商業(yè)軟件會(huì)定期將補(bǔ)丁和更新“推送”到組織的軟件中，或者至少供應(yīng)商會(huì)發(fā)布更新（通常是緊急更新）可供下載的通知。但對(duì)開源代碼來說，這種情況很少發(fā)生。為此，企業(yè)需要一個(gè)準(zhǔn)確、全面的開源清單，以及自動(dòng)化的過程來監(jiān)控軟件中的漏洞、升級(jí)和開源的整體健康狀況。

結(jié)語與建議

無論是獨(dú)立開發(fā)人員還是大公司，為了降低風(fēng)險(xiǎn)，每個(gè)人都有責(zé)任維護(hù)軟件供應(yīng)鏈安全實(shí)踐。隨著軟件供應(yīng)鏈攻擊數(shù)量的增長，有效地管理開源代碼的使用、組件和依賴關(guān)系對(duì)于管理風(fēng)險(xiǎn)變得更加關(guān)鍵。所有組織都應(yīng)該主動(dòng)管理開源風(fēng)險(xiǎn)，并將其作為安全軟件開發(fā)實(shí)踐的一部分。

美國網(wǎng)絡(luò)安全和基礎(chǔ)設(shè)施安全局于2023年底發(fā)布的《保護(hù)軟件供應(yīng)鏈：管理開源軟件和軟件材料清單的推薦做法》為在軟件供應(yīng)鏈中使用開源提供了詳細(xì)的指導(dǎo)方針：

使用與內(nèi)部開發(fā)組件相同的策略和流程，將開源集成到產(chǎn)品的安全構(gòu)建過程中。安全團(tuán)隊(duì)通常定義有關(guān)開源代碼的安全策略、流程和工具。理想情況下，開發(fā)人員會(huì)從一個(gè)受保護(hù)的內(nèi)部存儲(chǔ)庫中選擇一個(gè)具有所需功能的組件，該存儲(chǔ)庫通過SCA安全分析工具進(jìn)行了初步的漏洞評(píng)估，然后在開發(fā)和/或構(gòu)建階段運(yùn)行進(jìn)一步的掃描，以盡早捕獲問題。跟蹤更新的開源和監(jiān)控的問題和漏洞。當(dāng)識(shí)別出漏洞時(shí)，應(yīng)評(píng)估受影響的軟件，以確定組件的流行程度及其在產(chǎn)品中的使用情況。組件應(yīng)該及時(shí)得到更新，或者，如果它不再被維護(hù)，應(yīng)該考慮尋找一個(gè)替代的解決方案。使用SBOM。了解軟件中包含哪些組件對(duì)于準(zhǔn)確和完整地管理代碼至關(guān)重要。SBOM是包含軟件中組件的細(xì)節(jié)和供應(yīng)鏈關(guān)系的正式記錄。在漏洞管理上下文中，SBOM支持漏洞的識(shí)別和修復(fù)。從代碼質(zhì)量的角度來看，SBOM的存在可能表明供應(yīng)商在整個(gè)軟件開發(fā)生命周期中使用了安全的軟件開發(fā)實(shí)踐。

原文鏈接：

https://www.synopsys.com/software-integrity/engage/ossra/ossra-report

相關(guān)知識(shí)

全面揭秘疫情下醫(yī)療網(wǎng)絡(luò)安全風(fēng)險(xiǎn)！超 80% 健康 App 有高危漏洞，暴力攻擊單日 80 萬次
健康安全風(fēng)險(xiǎn)評(píng)估報(bào)告
健康風(fēng)險(xiǎn)評(píng)估報(bào)告（28篇）
健康風(fēng)險(xiǎn)評(píng)價(jià)報(bào)告
易起聊.網(wǎng)絡(luò)安全│TPLC安全風(fēng)險(xiǎn)管理（上市后）
【網(wǎng)絡(luò)安全】健康碼數(shù)據(jù)存在風(fēng)險(xiǎn)！專家建議：要應(yīng)刪盡刪
健康風(fēng)險(xiǎn)評(píng)估報(bào)告健康風(fēng)險(xiǎn)評(píng)估報(bào)告八篇
第三方軟件安全測(cè)試報(bào)告 保障信息化系統(tǒng)安全 通過專家評(píng)估驗(yàn)收
中國網(wǎng)絡(luò)安全協(xié)會(huì)建議對(duì)英特爾展開全面審查，防范潛在安全風(fēng)險(xiǎn)
健康風(fēng)險(xiǎn)，和健康風(fēng)險(xiǎn)的更多相關(guān)內(nèi)容

網(wǎng)址: 《2024年開源安全和風(fēng)險(xiǎn)（OSSRA）報(bào)告》：84%的代碼庫存在漏洞風(fēng)險(xiǎn) http://www.u1s5d6.cn/newsview1816811.html