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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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