原標(biāo)題：程序員大本營GitHub遭黑客劫持，是時候認(rèn)真聊聊開源代碼安全了

著名的“交友網(wǎng)站”GitHub是程序員的“大本營”，很多人都將源代碼托管在上面，并不斷利用社區(qū)開源資源開發(fā)新的算法、軟件、應(yīng)用。

這樣一個極客云集的平臺，居然被黑客給一窩端了，委實(shí)有點(diǎn)玄幻。

5月2日開始，GitHub遭到了黑客的攻擊勒索，有370多名用戶的源代碼和信息被名為“gitb ackup”的賬號刪除。

黑客下載了那些代碼，并存儲到了自己的服務(wù)器上。要求他們往特定賬戶上支付0.1比特幣。并進(jìn)行了惡狠狠發(fā)威脅——“如果我們在未來10天內(nèi)未收到您的付款，會將您的代碼公開或以其他方式使用?！?/p>

花開兩朵各表一枝，這邊GitHub程序員忙著找代碼， 隔壁微軟的開源開發(fā)平臺也不幸被黑客選中了。黑客擦除了其392個代碼儲存庫，要求微軟支付一定的款項(xiàng)才會歸還竊取的數(shù)百個源代碼。

對此，許多受害者認(rèn)為，開源平臺遭受攻擊是其上開發(fā)的應(yīng)用程序有漏洞，被黑客利用了。

那么，有什么解決辦法么？GitLab建議是，使用強(qiáng)密碼降低被破解的風(fēng)險，開啟雙重身份驗(yàn)證，使用SSH密鑰等……

什么？？全球頂尖程序員匯聚的平臺，安全措施也這么原始嗎？富土康流水線工人、村頭王大爺?shù)慕挥奄~號也都是這么提示的好嗎？

不得不說，GitHub程序員被劫持事件給業(yè)界上了生動一課，提醒人們，而開源軟件和組件的先天不足，可能給普通網(wǎng)民和企業(yè)安全帶來巨大的風(fēng)險，尤其是建造著數(shù)字網(wǎng)絡(luò)的“工程師”也可能“打盹兒”的時候。

從GitHub說起：開源社區(qū)集體缺了一節(jié)“安全行駛課”

1998年，“開源”這一概念被首次提出，到2019年已經(jīng)度過了20個春秋。憑借著開放、共享、自由等特性，開源平臺在軟件開發(fā)中扮演著越來越重要的角色。Gartner的一項(xiàng)調(diào)查顯示，有99%的組織在其IT系統(tǒng)中使用了開源軟件。

很多我們熟悉的日常軟件功能，比如支付賬單、娛樂社交、工作效率等等，有60-80％的代碼庫都來自開源社區(qū)。

前不久Snyk 公司發(fā)布的2019年開源安全現(xiàn)狀調(diào)查報告也說明，開源項(xiàng)目的采用率正在以驚人的速度增長。僅是2018年，Java 工具包翻了一番，而 npm 增加了大約 250000 個新的工具包。

（每種語言其生態(tài)系統(tǒng)的新漏洞增長情況）

數(shù)字時代的進(jìn)度條，因?yàn)殚_源而飛快加載。但步子邁得太大，也容易摔著。說到影響網(wǎng)絡(luò)安全的最大掣肘，恐怕也要追溯到開源社區(qū)。

Snyk報告中提到，有37％ 的開源開發(fā)者在持續(xù)集成(CI)期間沒有實(shí)施任何類型的安全測試，54％ 的開發(fā)者沒有對 Docker 鏡像進(jìn)行任何安全測試。這也導(dǎo)致兩年時間內(nèi)，各大平臺的應(yīng)用程序漏洞數(shù)量增長了 88％。 GitHub上排名前40萬的公共代碼庫中，僅2.4%有安全文檔。而npm 和 Maven 中央倉庫的安全隱患尤其嚴(yán)重，因?yàn)槎咭彩枪ぞ甙鼣?shù)量增長最多的平臺。

搞了半天開發(fā)者們都是在不系“安全帶”的前提下超速飆車啊？？話又說回來，漏洞的存在會帶來多大的影響呢？

原本不需要這么緊張的，但在開源的情況下，事情就變得很不一樣了。

因?yàn)楫?dāng)一個開源組件存在漏洞（通常稱為CVE）時，這個漏洞會迅速公布。原本，開源可以讓更多人及時發(fā)現(xiàn)漏洞，并對其執(zhí)行必要的修復(fù)。不幸的是，一些圖謀不軌的人也同樣可以看到這些信息。

他們幾乎不需要付出太多努力，就能了解哪些組件更容易受到攻擊以及如何做。然后，找到哪些平臺和公司可能會反應(yīng)遲鈍，在被修復(fù)之前黑掉他們的系統(tǒng)。

2018年4月，黑客就暴力破解了流行開源Magento電子商務(wù)平臺的口令，利用拿到的訪問權(quán)大肆搜刮信用卡記錄并安裝加密貨幣挖礦惡意軟件。另外諸如著名的OpenSSL水牢漏洞事件、心臟滴血事件、Equifax數(shù)據(jù)泄露事件、Gmail、yahoo和Hotmail賬號泄露等等，都是被黑客搶占了先機(jī)。

數(shù)據(jù)表明，如今開源平臺漏洞出現(xiàn)到修復(fù)的時間，中位數(shù)幾乎長達(dá)2年之久。這意味著，所有使用了那些漏洞代碼或組件的軟件用戶，只是在黑客們的陰影還沒來得及動手的“慈悲”下盲目而快樂地沖浪在網(wǎng)絡(luò)。

那么問題來了，究竟是什么導(dǎo)致了程序員們?nèi)绱恕靶拇蟆?，甚至不停地給黑客們“送人頭”呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開源代碼的安全戰(zhàn)役，有沒有另一種打開方式？

無論從哪個角度看，開源代碼的安全戰(zhàn)都是一場十分必要、不容退卻的全民戰(zhàn)爭。當(dāng)然了，普通用戶只能打call，沖鋒陷陣的還得是軟件公司和程序員們。

對此，產(chǎn)業(yè)界也開始拿出了一些試圖從根源上解決問題的辦法。簡單說幾個：

1.漏洞獎勵。

2012年，谷歌推出了Chrome獎勵計劃和漏洞獎勵計劃，鼓勵程序員找出其瀏覽器及在線服務(wù)中的具體弱點(diǎn)，使得廣泛使用的開源軟件盡可能不那么容易遭受攻擊，并為此支付500到3133美元不等的報酬。2013年，美國國家安全局也撥出了2510萬美元，用于“額外秘密購買軟件弱點(diǎn)”。

如今，漏洞賞金計劃已成為許多互聯(lián)網(wǎng)公司的重要安全策略之一，微軟推出了迄今為止最高的Windows Bug獎勵計劃，達(dá)到250000美金。蘋果、美國國防部、Facebook、騰訊、阿里ASRC、百度等為其漏洞支付的總金額也非常的驚人。

重賞之下，安全漏洞的時間差也有望有效減少。

2.新技術(shù)工具。

無論是防止源代碼中的信息泄露，還是要尋找惡意文件、阻止惡意進(jìn)程、保證端點(diǎn)安全，都有越來越多的技術(shù)工具可供使用，許多云安全公司和運(yùn)營商等也都開始參與安全工具的開發(fā)。

比如最近的開源領(lǐng)導(dǎo)者峰會上，Linux基金會就宣布了Red Team（紅隊(duì)）項(xiàng)目。新項(xiàng)目將孵化開源網(wǎng)絡(luò)安全工具，以幫助提高開源軟件的安全性。

作為開源安全工具的孵化器，Red Team支持網(wǎng)絡(luò)范圍自動化，容器化滲透測試工具，二進(jìn)制風(fēng)險量化和標(biāo)準(zhǔn)驗(yàn)證程序等。并且能夠在云上模擬黑客攻擊，用戶可以部署黑客腳本，并對現(xiàn)實(shí)中的團(tuán)隊(duì)進(jìn)行安全培訓(xùn)。

諸如Commit Watcher等種種開源工具的出現(xiàn)，幫助程序員查找潛在危險失誤，也正在使軟件開發(fā)過程變得大不相同。

3.加密算法。

如果我們將數(shù)據(jù)信息看做是網(wǎng)絡(luò)世界最寶貴的財富，那么加密機(jī)制就是一個可以保護(hù)數(shù)據(jù)的保險箱。除了將箱體打造的更加水火不侵，“鎖芯”這道防線也需要不斷迭代。

尤其是現(xiàn)在越來越多的機(jī)構(gòu)與企業(yè)選擇云計算技術(shù)作為復(fù)雜業(yè)務(wù)的解決方案，開源云平臺的安全問題也更加速咋，因此，數(shù)據(jù)加密算法的解決方案就顯得尤為重要了。

像是可以對企業(yè)數(shù)據(jù)進(jìn)行安全分級，對等級高的數(shù)據(jù)先采用對稱算法進(jìn)行加密，并將對稱算法產(chǎn)生的秘鑰進(jìn)行非對稱加密存儲，從而兼顧數(shù)據(jù)和安全性，以及系統(tǒng)運(yùn)行效率。

在硬件端，谷歌也剛剛推出了針對低端手機(jī)的新加密標(biāo)準(zhǔn)Adiantum，在沒有足夠計算能力芯片的前提下，也能實(shí)現(xiàn)高速計算來進(jìn)行哈希算法加密及解密，從而提升終端設(shè)備的安全性能。

從長遠(yuǎn)來看，開源社區(qū)更加靈活和開放的構(gòu)建方式，會令它繼續(xù)成為開發(fā)江湖的“根據(jù)地”。但當(dāng)開放與自由成為雙刃劍，又成為一個流著“奶與蜜”的數(shù)據(jù)豐饒之地，就很容易被不法之徒虎視眈眈。至少從GitHub這件事上看，開源代碼的安全問題，應(yīng)該已經(jīng)來到了一個危險的臨界點(diǎn)，也給一直以來“違規(guī)飆車”的業(yè)界敲響了警鐘。

用開源軟件的倡導(dǎo)者Eric S. Raymond的話來說——高質(zhì)量的代碼，就是對程序自己最好的注釋。

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。