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

然而，開源代碼有風險——即使是最廣泛認可的代碼庫也一樣。沒有人能保證開源代碼不會有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等網站提供了方便搜索與查詢這些信息的服務。

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

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

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