CVE（即公開的軟體漏洞）主導了有關開源軟體（open source software，簡稱：OSS）風險的討論。 2016 年統計共有 6,457 個 CVE 風險，此後，統計數字逐年增長，到 2023 年報告的 CVE 風險數量已經達到 28,961 個，在短短七年內增長了近 4.5 倍。 2024 年已經有望超越 2023 年，一旦人工智慧認真致力於發現漏洞（更不用說創造漏洞），我們可能會看到更快速的成長。
但 OSS 安全不僅僅是 CVE 問題。 實際上，一個由 CISO 和其他專家以及經過 OWASP 認可的組成團隊，思考除了CVE 之外的 OSS 風險。 他們新發表一個名為《2024 OWASP OSS 十大風險快速指南》清單，以下就讓我們來深入了解。
雖然前述提到 CVE 之外還有其他可能的風險，像是國家漏洞資料庫（NVD）列為已知的漏洞也是不可小覷的風險。 即使開發人員已經非常仔細在元件採用及編寫程式，有時仍會不小心在程式中留下安全漏洞。 已知的漏洞來源可能會被駭客所利用（使用 EPSS 評分和公共漏洞通報），而即使是已修補版本，仍是需要注意仍存在的漏洞。
開源套件來源很重要，但與有別於軟體原著性，沒有一個開源套件會是因為可以以合法公開原著而無法放棄使用的——而我們所指的＂放棄＂是指＂完全無法妥協＂。 在著名的 SolarWinds 攻擊中，威脅行為者能夠將惡意程式碼植入套件之中，然後對其進行簽署並散布給數以萬計的 SolarWinds 客戶。 雖然 SolarWinds 的 Orion 不是開源套件，但這種攻擊也有機會發生在開源套件上。 攻擊者使用多種手法將惡意代碼植入合法套件中，例如滲透代管維護人員的帳戶、利用存儲庫中的漏洞假扮成真正的開發者並將惡意代碼隱藏在普通測試檔案中，就像在 XZ-utils 中的一般檔案。
目前有許多含有惡意、非法和惡意軟體冒充為友善的程式碼。駭客將使用名稱、標誌和其他特徵標記來欺騙混淆毫不知情的開發人員，下載到這些已被加料的套件。這些套件同時具有原先的功能，但多含包了未被檢測到的後門程式。一旦這些套件進入您的系統使用，不僅系統安全性是脆弱的，甚至因此受到攻擊。 還記得前面提到來源安全很重要嗎？ 這個風險突顯了其原因。
開源套件開發貢獻者製作開源軟體通常是出於熱情，通常是由空閒時間完成。當沒有空閒時間可以利用時，則程式的定期更新和安全性修補也會受到影響或停滯。原始專案團隊以外的開發者雖然可以製作自己的補正版本，但他們相對缺乏套件相關開發的背景經驗可能會導致解決問題的時間更長。
有時候我們未更新元件，可能是因為遺忘、不知道有新版本可用，或是因為沒有時間。但問題在於老舊版本會存在已知風險，當累積待更新的版本越多，若這期間發生了重大安全問題，更新版本會變得更加困難。
保護未知的事情是困難的。相依性有許多不同的因素造成不易追蹤，進而產製了不完整的軟體物料清單（SBOM）。或者由人工進行盤點，導致過多的相依性來不急消化。即使使用自動追蹤工具盤點，也可能因僅放入部份片段程式碼或未採用套件管理器安裝而遺漏。
並非所有的開源授權都給予相同的權限，它們之間不一定相互相容，而一些看似「開源」的專案實際上根本沒有獲得開源授權。在不考慮授權情況下使用 開源套件，可能會使你的專案陷入棘手且衍生法律範疇問題。此外，開源套件可能無法滿足像 FedRAMP 這樣的監管計畫要求，從而使您的最終產品沒有資格銷售給某些企業客戶。
雖然許多 開源專案是由經驗豐富且熟練的開發人員創建的，但有些專案實際上並非如此。在缺乏經驗的開發下，會增添不佳的程式編碼可能產生額外的風險，例如在更新版本的驗證測試不充份、測試文件很少或幾乎沒有，或者使用令人困惑的非標準版本控制，這些方案在更新時對於功能造成破壞。都可能增加開發人員的工作量和作業時間。當然，草率的程式編碼也可能引入許多安全漏洞。
您的開源元件可能會引入來自其他專案套件的程式碼和資料，這些程式碼和數據可能會在開發人員不知情或未經批准的情況下進行更改或篡改。這些未經授權的更改可能來自未經版本控管的資料來源、不安全的資料傳輸以及已更改的版本化資源，這可能發生在開發人員在命名套件版本時使用萬用字符，或者將 git 存儲庫的主版本指向特定版本。即使沒有任何安全問題，可變更套件物件也可能導致穩定性問題和無法重現的構建
過少相依性的套件其程式碼行數非常少，可能直接自行開發即可。由於任何開源套件都可能受到帳號接管或惡意拉取請求的影響，因此專案開發越大量依賴專案使用 開源套件 都會增加更多的風險。例如，我們無法控制套件作者是否安全保護其帳戶密碼。另一方面，若僅使用大型套件中的一小部份，也可能因為其可攻擊面多而增加被攻擊的可能。尤其是常需要注意這種大型套件的漏洞通報也是另人困擾的。