撰文及整理：叡揚資訊資安團隊

在過去，企業組織在開發軟體時，對於使用Open Source 抱持謹慎的態度。多數的法務並不想處理繁雜的Open Source 授權(Licensing)與版權(Copyright)問題，高階主管甚不希望在自家產品中看到"自由"與"軟體"的組合，擔心產品一旦銷售出去，可能被有心人士窺探他們的"獨家配方"。

在那之後，我們走了很長一段路。直到現在，Open Source幾乎是各團隊開發標準中的一部份，且多數組織都使用Open Source提供客戶服務。現今在多數企業組織的專案中，有60% 到80%是由Open Source 組成，這個數字不言而喻。

確保您使用無風險的Open Source 

儘管我們喜歡Open Source所帶來的好處，但它們也一併帶來風險。是的，我們了解自行開發的軟體(Proprietary Software，或稱非自由軟體)有其一系列的問題。但今天我們先來聊聊Open Source 的使用風險。

為了確保我們使用的Open Source在產品(系統)發佈時合法合規，且具有足夠的安全性及品質，我們必須了解：使用Open Source時，會帶來那些風險，以及該採取那些措施來避掉風險。許多線上的軟體原始碼代管服務平台(如：GitHub)都有提供Open Source。不過開發人員並不太會去了解其程式碼品質或安全等級。若是組織沒有正視並控管之，放任Open Source 的濫用，等同於把自己置於風險之中。當這些風險隨著時間累積堆疊，不論是上線前夕要修復這些問題，或是上線後遭受攻擊，都得付出昂貴的代價。使用Open Source時，須注意法律、程式品質和安全方面的問題。若企業組織使用Open Source 時，沒有了解其"成分"，不知不覺中可能就使用了易受攻擊、危險、未經許可或過時的Open Source。

#1 Open Source 軟體安全風險

對駭客來說，Open Source 安全漏洞是能輕鬆圖利的好東西。漏洞一旦被安全研究社群發現，如何重現漏洞以及利用漏洞的細節就會公諸於世。駭客會從社群中得到許多有利於發動攻擊的訊息。更糟糕的是，熱門的Open Source 通常有著龐大的使用群，對駭客而言就是一群肥羊。也因如此，一旦漏洞被發現並公開，就有許多攻擊者企圖從中得利。

駭客們無時無刻盯著Open Source 社群，伺機攻擊熱門的Open Source 。如果企業沒做好Open Source 使用管理，沒掌握好自家軟體或網站使用了那些品質不佳的Open Source，就容易遭受惡意攻擊。

欲追蹤Open Source 的安全漏洞及其修補程式，需要使用特定的工具和流程。時至今日，已知的Open Source 漏洞會透過各種安全通報或資料庫發佈，而非在一個集中位置發佈。這使得追蹤Open Source 漏洞的工作難以手動執行，尤其是有一定規模的軟體(系統)，幾乎不可能人工完成這個工作。然而為了降低安全風險，必須不斷的尋找修補程式(patch, fix)或更新版本。這需要大量的工時，而且追蹤的速度若跟不上漏洞發佈的速度，這件事就不可能做到完整徹底。不幸的是，一個Open Source，內部可能還使用了其他Open Source函式庫(library)。因此追蹤的過程中，還得要注意Open Source 和library之間煩人的依賴問題(dependencies)。

一旦安全漏洞及其緩解措施被發佈了，駭客們就很有可能開始計劃攻擊。這是一場時間競賽，企業組織要在客戶遭受攻擊之前，從專案中找出有風險的Open Source 及其分支(branches)。

#2 Open Source 軟體授權合規風險

每個Open Source及其依賴項都有其授權方式(license)。當專案使用了Open Source，就視為我們同意遵守該授權所代表的一系列條款和條件。對於那些不熟悉Open Source 授權的人來說，這是一個地雷區。要深入了解Open Source 授權可不輕鬆，您知道Open Source 的授權方式超過200種，每種都有其特殊、具體，且常令人困惑的條款和條件？有"copy-left"、有"Anything Goes"，也有"permissive with strings"。也有甚麼授權方式都沒註記的Open Source，這意味著它使用默認的授權法(copyright laws)。甚至不少Open Source 採用"多重"授權方式。在短暫的開發衝刺期內，面對如此多樣的授權方式，讓合法合規的工作極具挑戰性。若企業組織沒有確認授權方式就隨意使用Open Source ，無異於飛蛾撲火。忽視授權規範中的條款，可能使組織陷入Open Source 訴訟，甚至被迫公開程式碼。

#3 Open Source 軟體品質風險

雖然多數開發團隊投入了大量資源來維護內部開發的程式碼品質，卻忘了也要檢查Open Source 的品質。誠然，大家都希望最終產品在各種壓力下能保持穩定性和一致性。但我們該如何確保開發團隊不會使用到品質低劣的Open Source？或者應該問，要用什麼條件來評斷品質？這個問題讓使用了Open Source 的產品、軟體、系統，難以確保其品質無慮。因為評估Open Source 品質的方法並沒有一致的標準，其特有的協作性質，讓測量工作具有相當的挑戰性。

Red Hat的Preethi Thomas指出，在Open Source 中，"社群參與是自願的，因此每個人的技能，參與程度和開發時間可能有所不同"，這使得品質保證成為一項困難的任務。通常，在選擇Open Source 時，大多數開發人員會使用他們所熟悉的來用。如果不熟，他們也可能會先去問朋友。總之，在挑選Open Source 這件事情上，品質往往不會是他們所在意的事情。但是，如果我們真的想確保我們所選用的Open Source 專案是穩定可靠的- 我們該怎麼分辨？

WhiteSource建議從三個面向來評估Open Source 組件的品質：

• commit的數量，作為其活躍度的指標。
• 每個特定版本中修復bug的數量。
• 每個特定版本中發現的bug數量及其嚴重程度。

自動化工具可以減輕Open Source 風險

Open Source幫助我們加速開發並降低成本，讓我們能夠在短時間內開發出新創產品，持續在商業競爭中保持領先地位與優勢。為了保持這個優勢，必須解決上述三個Open Source的使用風險。為此，需要追蹤我們正在使用的Open Source，包括所有依賴的Open Source，同時還要持續關注所有Open Source 社群的訊息及版本更新。唯有如此，才能走得比駭客快，在漏洞被利用之前修補掉。

而不錯過任何Open Source 消息的最佳辦法，就是整合自動化工具，讓工具分析出我們的Open Source 使用情況，並自動比對最新的Open Source 版本、授權方式、漏洞和修復方法。

自動化的Open Source 管理工具能針對我們正在使用的Open Source，代替我們到不同漏洞資料庫蒐集相關訊息，並且持續關注多方Open Source 社群的動向，幫助我們安全的使用Open Source，而無須擔心誤用到品質不佳、含有漏洞或侵權的Open Source。