我們從 SolarWinds 學到的事 – 評估第三方資料庫

在 2020 年 12 月，SolarWinds 公開表示其 Orion 產品受到大規模攻擊，讓攻擊者取得通往眾多 SolarWinds 客戶基礎架構的後門存取途徑，其中甚至包含多個政府機構。此次入侵攻擊的規模，引起大眾對於供應鏈安全漏洞和第三方相依性在軟體系統安全性中之作用的高度注意。即使這些並不是新的威脅，但目前事件所引發的額外審查，讓各大組織強烈希望能改善其安全性狀態，使得自己不會成為下一個目標。身為軟體工程團隊，您與供應鏈最常見的互動，是選擇要在應用程式中包含何種外部資料庫。管理良好的外部資料庫對開發工作而言可謂是一大福音，讓您專注於產品的重要差異處，而非重新實作常見功能，進而節省無數的工程師工時。相對地，實作情形不佳的資料庫可能難以使用、引入安全漏洞而造成組織與客戶的風險，在極端案例中，甚至會干擾與服務不相關部分的運作，或破壞整體架構。我會在此處概述用來評估資料庫的工程實作方法完善程度，以及其可能之安全性影響的諸多考量。我提供的方法只是協助開始的參考，而非唯一作法。尋找能滿足您需求的方法。雖然在此空間中沒有絕對的錦囊妙計，但確保專案僅仰賴高品質的相依性，可大幅縮小您的攻擊面，並讓您的專案易於擴充和維護。

資料庫範圍

此初始考量是關鍵，因為這會決定必要或適當的評估縝密程度。資料庫提供多少功能？此功能對於讓您的產品正常運作有多重要？簡單且佔用空間小的資料庫，與將和自己的程式碼密切整合之大型架構相較之下，需要的審核工作少非常多。且關鍵功能（例如非經常性更新）的部分重大問題指標，可能對於僅用來完成極具針對性之工作的小型資料庫來說，屬於正常或預期中結果。其中一個相關問題，便是您打算如何使用資料庫。開發相依性（例如靜態分析工具或單位測試框架的元件）所面臨的風險，遠比執行階段相依性來得小。雖然組建管線中的故障可能會使發行延遲，或對開發人員造成其他短期問題，但這些故障並不會直接影響使用者，且一般來說對於應用程式本身的安全性也沒有風險。

維護歷程記錄

瞭解專案整體健全狀況的最快方法，即是查看其原始碼控制歷程記錄。上一個版本的發行時間為何？版本的發佈頻率為何，以及原始碼存放庫的認可率為何？我希望能看見專案頻繁更新，因為這樣能讓我放心覺得資料庫在往後也會持續受到維護。相對地，已許久沒有變動的專案，可能會包含未處理的錯誤，或導致與新通用相依性版本，甚至是語言執行階段本身不相容的問題。查看資料庫的變更記錄也是非常有價值的。有時候，版本頁面上會說明各版本的變更。其他時候，變更記錄則是位於原始碼存放庫最上層的檔案。如果此資訊並非立即可用，則會是難以忽視的大問題。我會查看是否提供版本之間之變更內容的清楚說明，以及是否有清楚記錄任何不向下相容的情況。但是，過於頻繁地對核心功能做出與不向下相容性相關的變更或錯誤修正，也會引起疑慮，因為這表示開發人員在發行前，沒有做好規劃和除錯變更的工作。

維護人員關係

若要進行深度評估，則可能需要仔細查看專案的問題追蹤器，以及其他公共通訊頻道。維護人員對使用者的回應情況如何？他們是否友善且樂於收到意見回饋，還是他們的語氣往往較為逞強好辯？待處理與已結案問題的比例為何？維護人員是否會主動化解使用者的疑慮，還是會長期忽略錯誤報告？說明文件的涵蓋範圍有多廣泛，以及其是否能有效引導使用者採用最佳實作方法？是否可以證明此專案有活躍的社群在支援？舉例來說，支援使用者的重擔是否全由主要維護人員承擔，或是有其他社群成員願意且有能力分擔一些工作？可與其社群維持良好健全關係的專案，較有可能符合使用者的特定需求，並快速適應不斷變遷的環境。

傳遞相依性

與單純計算發行頻率相較之下，此項評估需花費更多的心力，但提供的資訊也更為豐富。首先，我會想要瞭解資料庫仰賴多少額外相依性，尤其是資料庫是否使用非必要的相依性。相較於為資料庫提供關鍵功能的相依性，為了不相關工作而使用許多額外資料庫更令人擔憂。每項額外相依性都會帶來額外的複雜性和供應鏈風險。如有疑慮，有個簡單的評估工具，就是將資料庫安裝在 Docker 容器中，並記錄過程中新增了多少額外資料庫。此類別的最大考量，即是在發現新的安全漏洞時，我們能夠多輕鬆地更新相依性。正因如此，評估的一個重要部分，便是記錄相依性為受限的（僅適用於特定資料庫版本）或是不受限的（適用於各種版本）。受限相依性是一大隱憂，因為這可能會讓修補作業難以進行，甚至會迫使我們必須為其他功能將所仰賴的資料庫降級。相關的還有，這些傳遞相依性是否為近期發行。發行兩個月的相依性版本，遠比已發行兩年的相依性要來得令人放心。同樣地，執行良好之專案的其中一個跡象，便是其頻繁更新的歷程記錄，讓其相依性保持最新狀態。

跨語言相依性

特別注意以某一種語言編寫，並具備不同語言之相依性的封裝（例如具備已編入之 C 語言延伸模組的 Python 資料庫）。如果次要相依性含有您較不熟悉的語言或編程環境，您將難以評估其整體品質。除此之外，不同的語言通常具備不同的封裝慣例，而涉及多個語言專案的維護人員，通常較不熟悉其所有必須處理的編程語言最佳作法，讓修補和更新作業變得更為困難。

密碼編譯資料庫

由於牽涉其中的演算複雜性，以及潛在安全漏洞在此空間中的高度影響，密碼編譯資料庫值得特別考量。尤其要小心地評估此類資料庫，並確保您僅仰賴於具備長期追蹤記錄，且經過仔細審視的資料庫。部分安全選擇包括 C 和 C++ 適用的 OpenSSL、Java 適用的 BouncyCastle，以及 Python 適用的 PyCA 密碼編譯資料庫。您的選項可能會受限於貴組織的資安政策或合規性要求。請注意密碼編譯資料庫中的已知安全漏洞，並掌握最新版本的資訊。在您所有的第三方相依性中，這些是最有安全性影響的。

程式碼和文件品質

本區段和下一個區段為需要大量工作的評估，但有時候對於高風險的案例也需要此層級的審查。當我想要瞭解某項專案的程式碼整體品質時，我會嘗試尋找使用我已有深度瞭解之功能的原始碼，並評估在其程式碼基底之小區域的編寫完善度。有時候我會查看專案說明文件的整體品質，專注於編寫者所編寫的內容是否清晰，且是否有能力詳實說明複雜的概念。無論是何種情況，我的目標都是判斷維護人員是否會注意細節，還是想抄捷徑。但也有例外狀況，專案中的一部分若顯示其經過細心處理，則此部分可能可以代表整個專案的狀態。舉一個具體範例，如果我選擇查看 Python 專案對 SSL 的處理方式，我可能會注意下列事情：

他們是否使用預設 SSL 連線參數，或是嘗試將其自訂為更安全的設定？
如果他們採用自訂設定，則變更是否合理？
他們是否允使許用者進行進一步的自訂設定？
如果允許自訂設定，他們是否重複使用 Python 的標準資料庫 SSLContext 物件，或是否嘗試重複一樣的工作？

在如此的評估當中，我想要看到完善的設計原則，重複使用標準慣用語法，以及作者可預測可能的使用者需求，並提供適當的擴充性以滿足該需求。

安全漏洞處理

我將此項目列在最後，是因為這是我需要經過一段時間才能建立的印象，如果在初始評估進行便比較沒有幫助。我也非常看重特定資料庫有多麼被廣泛使用，以及其安全性相關程度。但是，這當然可以被視為是否繼續使用現有資料庫，或嘗試移轉至替代品的評斷因素。簡單來說，我會嘗試評估專案維護人員對於修補安全漏洞的回應速度，以及在我們的部署中，是否可以輕易獲得修補所帶來的好處。經常受到安全漏洞暴露影響的專案有些令人擔憂，但也很容易成為廣泛使用和安全性相關性的要素，而非程式碼整體品質和維護作法。一個較佳的指標，是觀察安全漏洞被發現後的情形。是否隨後便快速將修補程式包含在新版本中？發行修補版本後，是否可輕易升級？如果專案經常進行大幅變更，特別是如果經常性地破壞向下相容性，是否也會將修正內容向後移植到舊版？如果資料庫是 Linux 發行版本的一部分，那麼向後移植修補程式的責任通常在發行版本維護人員身上，而非原始開發人員，但相同問題可以套用於封裝者如何處理資料庫（發行版本通常會將主動維護的核心封裝，與偏向周圍的封裝作出區隔，一般來說是追蹤上游版本，並套用最低程度的變更）。當資料庫中清楚記錄著安全漏洞處理不佳的情形，或以令人難以有效運用安全性修補的方式運作時，我通常會建議我的團隊移轉至替代品。

總結想法

評估軟體專案的整體品質及其周圍社群，是一項必備技能，且會隨著軟體專案變得更互相依賴時而益發具關聯性。這同時也是一項極為個人化的技能；您經常會在自己的專業領域中，藉由調查資料庫維護人員所做的決策而取得最大成果。由於完整驗證潛在供應商的所有細節，比您自己建構功能還要困難，評估程序便成為建立信任程度，並採取措施以確保沒有錯誤信任的必要過程之一。最終而言，瞭解如何評估第三方相依性，是一項重要元素，用以建構掌管產品安全性與可靠性的工程文化。