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

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

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

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

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

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

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

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

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

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

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

缺乏安全基礎(chǔ)的開發(fā)者增多，許多潛在的組件安全特性被忽略，而這些特性往往是造成漏洞的罪魁禍?zhǔn)住?/p>

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

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

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

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

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

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

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