開原始程式碼管理：如何安全地使用開源庫與框架？

在開發內部和外部應用程式時，企業越來越多地使用開原始程式碼——這是合理的。 使用免費預構建的元件，而不用自行編寫代碼，能夠顯著縮短應用開發時間和提高軟體發展成功概率。 在開發應用程式時，開發團隊可以輕鬆使用上百種以上的開源庫、框架和工具，以及無數來自互聯網的代碼。

然而，開原始程式碼有風險——即使是最廣泛認可的代碼庫也一樣。 沒有人能保證開原始程式碼不會有Bug，也不保證它在開發過程中採用了符合企業應用要求的開原始程式碼管理流程。 即使開源專案有一個活躍的使用者社區，它也可能有新舊漏洞。 例如，今年開源Ruby  on Rails  Web應用框架已經遇到幾次安全性漏洞攻擊，估計有200,000多個網站可能受到遠端執行代碼的攻擊。 更壞的是，這些Bug是在2007年出現的，這意味著6年多來這個框架的所有版本都有這樣的問題。 在本文中，我們將介紹使用開原始程式碼給企業應用帶來的風險範圍，以及使用開原始程式碼管理技術降低風險的方法。

開原始程式碼與易受攻擊的元件

有人認為開原始程式碼給企業應用帶來的風險很有限，因為許多時候開原始程式碼只應用於有限的應用元件。 然而，應用的元件幾乎總是擁有整個應用的全部許可權，所以一個有問題元件的總是可能會造成嚴重的後果。

任何代碼的漏洞危害可能很小也可能很嚴重，攻擊難度也可大可小，但是通用框架、庫或元件上出現的漏洞則明顯有較高的風險。 現在的免費駭客工具集更新很快，它們會將這些新發現的漏洞添加到自動掃描程式中，這樣使用這些問題代碼的應用程式就會很快被搜索到，然後遭受到攻擊，不僅高級駭客可以發起攻擊，一些使用自動化攻擊工具的初級駭客也可以攻擊。

在新應用中出現這些有漏洞的元件是很嚴重的問題，因此它出現在最新的OWASP十大應用漏洞清單。 在前一個版本的OWASP清單上，它屬於更一般的「安全配置錯誤」條目，但是它現在成為一個獨立條目——第9條：「使用有已知漏洞的元件」。

例如，OWASP指出，有2個帶漏洞的元件在2011年下載次數達到2200萬。 第一位就是繞過Apache CXF的身份驗證：Apache  CXF框架無法提供一個身份權杖，因此攻擊者可以有完整許可權去執行任何Web服務。 第二位是開源JAVA框架Spring中濫用的運算式語言，它允許攻擊者執行任意代碼，從而控制整個伺服器。 這樣的後果是什麼?只要企業應用程式使用了這些有問題的框架，它們就可能成為了攻擊者手上的玩物。

通過開原始程式碼管理實現軟體安全性

使用開原始程式碼的好處肯定勝過於從零開始開發應用程式所需要的時間與資源，但是另一方面，企業仍然必須使用一個流程保證所有協力廠商代碼的更新。 大多數開發團隊甚至不知道其中一些代碼的來歷，更不用說更新版本了。

可是，並非所有開源專案都使用一種可以理解的版本編號機制，因此漏洞報告並不總能夠確切指出有漏洞的元件版本。 幸好，CVE和NVD等網站提供了方便搜索與查詢這些資訊的服務。

要改進開原始程式碼的管理，開發團隊必須先創建和維護一個最新的協力廠商代碼使用清單，其中包括所有依賴代碼和來源。 為每一個來源指定一位負責人，專職跟蹤郵寄清單、新聞和更新。 這不應該只是一種被動的活動;因為並非所有新漏洞都會報告到一個集中的資訊中心，所以還需要監控公共安全郵寄清單。 有一些團隊可能發現他們必須減少所使用的代碼來源數量，才能提高管理效率;而且，肯定還要制定一個管理代碼使用的策略，如業務案例、風險評估和可接受授權。

如果一個應用程式使用了有問題的代碼，那麼首先要檢查它是否使用了包含漏洞的那部分代碼，然後評估它是否存在需要處理的風險。 一定要注意，許多開源專案並沒有發佈補丁;相反，它們通常都通過發佈新版本來修復問題。 要有緊急回應計畫來處理一些重要版本發佈，因為許多連接互聯網的應用都應該嚴格審查，它們可能需要一種快速回應措施，才能防止攻擊者成功攻破漏洞。

　　使用開源庫的企業開發者應該知道開原始程式碼的風險。 即使這些代碼能夠顯著減少軟體發展時間，使用它們也可能會不必要地增加企業應用程式的漏洞，從而提高組織的風險級別，最終需要更多的時間去處理風險。 要預先注意這些問題，企業就可以安全地使用開源庫和框架，而不會將應用及整個組織置於不必要的風險中。