5種方法 決定套裝軟體是否值得信賴


作者:Mike Bursell
出處:opensource.com
文章連結: https://opensource.com/article/20/11/trust-package


知道如何去評估套裝軟體的完整性

■ 圖片版權所有 :Jessy Bailey在Unsplash上拍攝的照片

現今到處都有開源軟體—這是非常棒—但是對於那些你下載的軟體‚如何去確定信任哪些軟體是會完成你所想要它執行的事呢?在這次討論中有一部分提到‚軟體供應鏈管理領域已成為了業界的新話題 ‚而且開源軟體這個領域變得越來越重要。我將討論一個特殊的例子 。


首先‚雖然套裝軟體是否值得信賴‚或許不是如警察局的劇情所描述:有個可疑的包裹到達警局‚有人及時意識到‚這可能是一顆炸彈如此的場景。我在這裡談論的是套裝軟體 (如果你能夠抱持不太去懷疑的話‚則若是就應用程式的影響來看‚就有可能和警局劇情相似之處)。有一個以信任意義為出發點的長篇談話 (在我即將出版的新書《計算機的信任和Wiley的雲端》(Trust in Computing and the Cloud for Wiley)。


就本文的目的而言‚若你需要的是提供一些實行加密協定的一個儲存庫‚那什麼是你需要了解的呢?什麼是你所要選擇的呢? 你總不會想從源頭去建構一切‚現在我假設你已經做出幾乎肯定的選擇‚並且採用了開源軟體來執行。(請參閱許多我以前寫的文章‚來了解為何開源軟體會是最佳安全套裝軟體。)若你需要一些穩定和維護的套裝軟體‚那麼你應該在何處獲得這新的套裝軟體呢?


選項1—使用的供應商(Use a vendor)

很多供應商通過多樣的機制(通常是訂閱)來提供開源軟體‚我的雇主Red Hat (請參閱我的部落格有相關的標準揭露)就是其中之一。在這個案件‚供應商通常會支持特定合適的套裝軟體‚來提供使用和補救措施等。在許多情況下‚這是你最簡單和最佳的選擇。然而‚有時你會想使用那些供應商未提供或是未列入選擇的套裝軟體‚那你應該怎麼辦?同樣地‚供應商要如何相信套裝軟體並且做出決定呢?


選項2 -深入研究(Delve deeper)

這就是事情變得複雜的地方。事實上‚要做決定來信任套裝軟體‚這件事是如此複雜‚我將在我書中的一些篇幅去檢視它們。然而在這篇文章中‚我設法簡捷表達。我將從一個套裝軟體的維護者(maintainer)和多貢獻者〈(contributors)指最初對開源軟體或項目‚提供代碼的人或組織〉的假設開始。貢獻者為項目提供代碼(測試和文檔等)‚維護者提供建構(二元/儲存庫)供你使用‚而不是你自己獲得開源代碼自行編譯(這實際上有可能是供應商的代碼‚儘管他們仍需考慮以下大部分的要點(套裝軟體安全上五個特定領域)。儲存庫有提供加密功能‚假設你關心的是儲存庫的安全性‚儲存庫就是會相當安全的。要知道儲存庫是否安全‚你需要詳細考慮至少五個特定領域 ‚所有領域在很大程度上都倚賴維護者‚ (儘管在所有套裝軟體中都存在非常相似的考量因素‚但在這我使用安全上的範例)‚來看看這些問題。


1 建構(Build):
你的套裝軟體是如何建立的?套裝軟體建立過程是否帶有合適的編譯和儲存庫「乾淨」機器(指未經破壞)的電腦上執行?如果二進文件建立‚用的是非信任的工具所設立‚那麼你要如何完全信任它?以及維護者需採取甚麼措施‚來確保建構的套裝軟體環境是「乾淨」的?如果在建構套裝軟體過程的記載‚是視為可重複寫入的建立 ‚這樣很好‚以便有人可以檢查它們。


2 完整性(Integrity):
這與建構套裝軟體相關‚你要確保建構的過程中輸入的源代碼—例如來自Git 儲存庫代碼‚是要符合你的期望。如果用某種方式‚將受到損壞的代碼注入到建構過程中‚那將會陷入不利的處境。你想確切知道哪個版本的源代碼‚能被正在使用的套裝軟體當成基礎‚以便我們可以有跟蹤和糾錯功能。如上所述‚這裡具有重複建構是很棒的額外好處。


3 回應式網頁(Responsiveness):
(指系統或功能單元在給定時間內完成指定任務的能力): 是維護者更改回應(是或否)的一種度量。通常‚你需要穩定功能去綁訂你所知的版本‚但對於錯誤(特別是安全補救方面)會快速反應。如果維護者不能即時確認補救‚你則需要擔心你的套裝軟體安全性。你還應該問的問題像是:是否對漏洞管理流程的安全揭露有較好定義?(請參閱我的文章《安全性揭漏和漏洞管理》(Security disclousure or vulnerability management?)


4 出處(Provenance):
並非所有代碼是都是平等的。維護者應該持續追蹤的是貢獻者的出處。如果具有匿名的電子郵件地址‚沒有安全功能歷史的的貢獻者‚突然提供特別敏感功能套裝軟體‚該軟體中有一部分提交大量代碼‚是將會引起警鐘。另一方面‚如果一家有開放源代碼貢獻者‚是經過良好審查代碼的公司‚僱用了一組貢獻者提交了很大補救措施 ‚可能會有較少麻煩。這是個很難解決的問題‚通常沒有明確的「合格」或「不合格」標示‚但維護者對於貢獻者貢獻的意識和管理‚是需要考慮的重要問題。


5 專門技術(Expertise):
這是最棘手的。你可能有一個維護者‚他在所有方面的管理上都很出色‚但他在貢獻者代碼功能的某方面並不是專家。然而身為套裝軟體的消費者‚我的目的是套裝軟體是確保合適‚並且可能包括確保正確密碼原語的合適性(這裡是在考慮安全相關的套裝軟體的情況下)。在字節流上執行檢查、使用適當的密碼長度、或特定原語所提供恆定時間的安裝啟用。這些都是非常困難的‚如果維護人員是擔任大型、(是/或)複雜項目的專家‚這時維護人員的工作就很容易成為專職人員。確實在這種情況下‚最佳做法是擁有個值得信賴的團隊、經驗豐富的專家‚他們是可以擔任項目的共同維護者或高級顧問小組。另一個方式是讓外部人員或組織(例如業界機構)‚在關鍵時刻對項目(例如:當在主要版本到期或重要漏洞的修補)去進行審核。例如‚讓維護人員可以分擔此責任。重要的是要注意到該項目‚不會因它是「開源軟體」(open source)而神奇地以為「安全」 (請參閱《不相信許多人眼光的假設》(Disbelieving the many eyes hypothesis)‚當開源社群(外界人員或組織)一起達成計畫‚則消費者對於這個套裝軟體的生產會明顯增進信心。

一旦考慮到這些領域‚就需要去解決如何權衡和追蹤到每個領域。誰能判斷任一特定維護者‚他們在各方面所能夠滿足我們需求的程度?你能相信他們有多少?這些都是複雜的問題‚還有許多需要寫的問題‚但是我非常熱衷在電腦開源方面明確信任的重要性。尤其這項工作圍繞在開源供應鏈管理—例如新的Rekor(提供人工智慧與機器學習功能的自動車牌辨識系統項目‚由OpenALPR軟體支援)‚在這個項目仍有很多工作要去做。

記得:當你拿到一個套裝軟體(無論是儲存庫或是可執行程序)‚請考慮什麼你所使用的‚什麼你可以信任的‚以及什麼是你所建立信任的保證。

【發表於 CC BY-SA(Creative Commons Attribution-ShareAlike)非商業性相同方式共享許可證 】