自欺欺人的“眾人之眼”，與軟件開發(fā)的三重門

顯然，開源代碼所謂的“眾人之眼”，并不能有效地杜絕安全漏洞，至少不能保證在黑客降臨之前消滅隱患。

如今，開源代碼爆出安全漏洞的事件還在不停發(fā)生，而很多項目并沒有查找和修復問題的機制。這么一想，GitHub的程序員用戶算是幸運多了，至少他們還能掏贖金把自己的代碼買回來。而那些被盜走了信息的普通用戶，也許只能成為黑客們的“肉雞”了。

但問題是，如果我們吃了一家餐廳的食物而中毒了，那么可以起訴這家餐廳。但同樣的邏輯在數(shù)字世界卻不成立了。如果用戶因為一個軟件而中毒／被盜竊個人信息，他幾乎沒有辦法找平臺負責（參考Facebook隱私門）。而且軟件開發(fā)商還會在用戶許可協(xié)議中進行“免責”，要求用戶同意不因為安全漏洞而起訴它。

為此，劍橋大學安全研究員Richard Clayton博士曾提出，要讓軟件開發(fā)商為可避免的安全漏洞帶來的損失負起責任。歐盟官員也一度考慮，試圖將開發(fā)人員的草率編碼行為導致的惡意漏洞引入法律。但最終都不了了之。

微軟是這么反駁的：軟件公司也是（黑客／罪犯）入室搶劫的受害者，大眾不能起訴門和窗戶的制造商。

聽起來是不是快要被說服了呢？打臉的是，在一個針對500多名開源項目維護者的調查中，清晰地展示了，只有30％不到三分之一的開源工程師具有較高的安全意識。這意味著，程序員和軟件開發(fā)商并沒有如大眾期望的那樣，將門和窗戶建造的更牢固一點。

導致這一現(xiàn)象的，是一種蔓延在整個軟件開發(fā)產業(yè)鏈上的“迷之自信”：

首先，開源社區(qū)顧此失彼的安全審查。一般情況下，為了讓開源項目免于災難，社區(qū)會依據(jù)Linux的Linus Torvalds，用他們的“千眼”不斷地審查代碼。運維人員必須十分小心，篩選代碼，檢查潛在的漏洞，并將其報告給安全數(shù)據(jù)庫。

但是，由于開源資源分布散而廣泛，很多漏洞軟件會在GitHub，nowhere．net等網(wǎng)站上肆意流通，因此因此持續(xù)監(jiān)控、趕在黑客前面發(fā)現(xiàn)漏洞也就成了一項艱巨的任務。

其次，日益消弭的開發(fā)門檻和隨性的開發(fā)者。以往，能夠開發(fā)開源組件的開發(fā)者本身素質相對較高，代碼質量較高，也使開源組件出漏洞的可能性較小。但隨著許多界面友好的平臺出現(xiàn)，像是GitHub，即使是新手編程也可以利用Git；任何人都可以免費注冊和托管公共代碼存儲庫，還有人利用GitHub來進行其他類型的項目，比如寫書。

缺乏安全基礎的開發(fā)者增多，許多潛在的組件安全特性被忽略，而這些特性往往是造成漏洞的罪魁禍首。

而且，即使是成熟的開發(fā)人員，也需要不斷在應用更新過程中解決新漏洞。但很少有程序員會審查舊工程中用到的庫，一般就是到開源項目頁面下載下來，集成到自己的應用中，然后就再也不管它了。這些軟件自然也就像鳳梨罐頭一樣，很快就過期。

在此基礎上，企業(yè)利用開源軟件或組件來進行開發(fā)，就像在一個搖搖欲墜的積木塔上蓋樓一樣，全靠運氣。

絕大多數(shù)企業(yè)的開發(fā)團隊，對開源軟件的使用都非常隨意，這就給應用的安全風險管控帶來了極大的挑戰(zhàn)，運維人員也無法知曉軟件系統(tǒng)中是否包含了開源軟件，包含了哪些開源軟件，以及這些軟件中是否存在安全漏洞。

而大多數(shù)云供應商在將企業(yè)數(shù)據(jù)上傳到集群之前都不會加密數(shù)據(jù)，比如OpenStack就不提供任何數(shù)據(jù)加密方法。這就需要企業(yè)和用戶自己先加密數(shù)據(jù)，再上傳加密后的數(shù)據(jù)和管理密鑰本身。

還有一些公司由于兼容性問題、合規(guī)問題等原因，無法遷移到最新版本的開源代碼，只能繼續(xù)使用包含漏洞的舊代碼。據(jù)Snyk稱，只有16％的漏洞補丁是向后兼容其他版本的。這也給黑客們創(chuàng)造了不少機會。

總而言之，在這樣從源代碼創(chuàng)造、分享、開發(fā)等一系列產業(yè)鏈上的“不著調”，造成了“漣漪效應”，最終締造了令人頭痛的安全事故。

那么，除了改密碼、打補丁之外，產業(yè)端有沒有一些更“治本”的辦法來杜絕此類隱患呢？