若惡意黑客參與了小型開源軟件的開發(fā)，在自身關(guān)鍵應(yīng)用中包含了這些開源軟件的公司企業(yè)就可能面臨遭遇漏洞利用的風(fēng)險(xiǎn)。安全專家指出，這些項(xiàng)目的開源本質(zhì)和代碼的廣泛應(yīng)用，對(duì)企業(yè)造成了切實(shí)的威脅。

一旦潛入開源項(xiàng)目，罪犯就有多種下手方式可供選擇，但必須動(dòng)作夠快。因?yàn)闊o(wú)論是后門鍵盤記錄器還是某種木馬，如果不是動(dòng)手夠快，或者真的非常非常隱蔽，用不了多久就會(huì)被 “眾人之眼” 揪出。

網(wǎng)絡(luò)罪犯之所以熱衷于黑開源項(xiàng)目，正是由于開源項(xiàng)目兼具靈活性和可用性的特點(diǎn)，能為黑客行動(dòng)的開展帶來(lái)大量機(jī)會(huì)。真可謂眾所周知的攻擊途徑了。而且開源項(xiàng)目被黑概率很可能比大眾認(rèn)知的要高得多。

安全公司 Checkmarx 安全研究主管 Eran Yalon 就表示：這可不是什么道聽途說(shuō)，而是身邊時(shí)時(shí)刻刻在發(fā)生的事。以前就曾出現(xiàn)過這種事情，我們沒理由認(rèn)為現(xiàn)在就絕跡了。

幾乎所有開源項(xiàng)目都要求貢獻(xiàn)者的工作要經(jīng)過項(xiàng)目其他成員審核才能并入項(xiàng)目。審核層級(jí)隨貢獻(xiàn)者個(gè)人聲譽(yù)而遞減，貢獻(xiàn)者受信度越高，則審核層級(jí)越少。尤其是在大型知名開源項(xiàng)目中，比如主流 Linux 發(fā)行版，整個(gè)審核過程非常精細(xì)完備，也有充足的人力資源持續(xù)執(zhí)行這一規(guī)程。

項(xiàng)目越小，則可供保障安全的資源就越少。所以，小型項(xiàng)目被黑的情況也就更常見了。

小項(xiàng)目，大影響

專家指出，超小型開源項(xiàng)目是黑客注入惡意代碼的重災(zāi)區(qū)。

超小型開源軟件包也有可能是大型軟件包的依賴，無(wú)論依賴層有多深。你覺得自己的項(xiàng)目只有一兩個(gè)依賴，但實(shí)際上可能有成百上千的，而且你根本無(wú)法徹查。

比如說(shuō)，由個(gè)人開發(fā)并維護(hù)的開源項(xiàng)目 Event-stream 就被惡意黑客接手，成功向經(jīng)由流行 JavaScript 包管理器 NPM 分發(fā)的代碼庫(kù)中注入了惡意代碼。

Event-stream 項(xiàng)目的開發(fā)人員沒有足夠的時(shí)間來(lái)維護(hù)。一名惡意用戶說(shuō)服了開發(fā)者，接管了該項(xiàng)目。

剛剛接管的時(shí)候該項(xiàng)目還是像以往一樣維護(hù)。此后，這名惡意用戶修改了 Event-stream 自身依賴的一個(gè)包，注入了可以劫持特定比特幣錢包的代碼。

該攻擊的影響范圍有多大？該項(xiàng)目代碼每周下載量近 150 萬(wàn)次，用在其他 1,600 多個(gè)軟件包中，而這些軟件包自身又各有數(shù)百萬(wàn)次的下載量。

另一起非惡意事件例證了小型開源軟件包的深遠(yuǎn)影響：2016 年 3 月 23 日，開發(fā)者 Azer Ko?ulu 刪除了他通過 NPM 分發(fā)的 250 個(gè)模塊。其中一個(gè)模塊非常之小，僅含 11 行代碼，是往文本字符串左側(cè)添加空格以適應(yīng)變量定義的。結(jié)果，這個(gè)名為 “l(fā)eft-pad” 的模塊是全世界成千上萬(wàn)的企業(yè)和商業(yè)軟件所用依賴包的一部分，包括用 JavaScript 開發(fā)的中流砥柱 Babel 和 Node 構(gòu)建的那些。

而由于 “l(fā)eft-pad” 下架，這些數(shù)以千萬(wàn)計(jì)的應(yīng)用全都失靈了。雖說(shuō)開發(fā)者重新創(chuàng)建該功能也不是很難，但如此簡(jiǎn)單的動(dòng)作受到的短期影響也已經(jīng)十分巨大。

(近) 普遍威脅

開源的普遍性眾所周知。Gartner 數(shù)據(jù)顯示，95% 的企業(yè)在內(nèi)部項(xiàng)目中使用開源代碼。

鑒于敏捷開發(fā)運(yùn)維方法的時(shí)間壓力，由內(nèi)部開發(fā)團(tuán)隊(duì)編寫自有功能和函數(shù)庫(kù)來(lái)打造確定性防御的做法，是不太可能被采用的。

于是，開發(fā)團(tuán)隊(duì)怎么增強(qiáng)代碼安全性呢？

第一步就是甄選納入技術(shù)棧的庫(kù)和開源項(xiàng)目。有些項(xiàng)目的 “履歷” 優(yōu)于其他項(xiàng)目。

第二步，確保所用項(xiàng)目是活躍項(xiàng)目，有定期更新。查看項(xiàng)目的活動(dòng)歷史可以確保項(xiàng)目是有眾多活躍開發(fā)者支持的好項(xiàng)目。有漏洞出現(xiàn)時(shí)能被及時(shí)修復(fù)的概率也高得多。

而一旦補(bǔ)丁可用，要確保及時(shí)應(yīng)用補(bǔ)丁修復(fù)漏洞。常有關(guān)注零日漏洞和黑客國(guó)家隊(duì)的組織機(jī)構(gòu)自己的 “基本代碼安全” 卻沒做好。保持開源代碼更新和做好基礎(chǔ)的代碼掃描，才是最基本而堅(jiān)實(shí)的網(wǎng)絡(luò)威脅防線。

這就是個(gè)信任問題：對(duì)開源項(xiàng)目和使用該代碼的內(nèi)部開發(fā)人員的信任。惡意開源代碼包如果沒人用，也是不會(huì)造成嚴(yán)重后果的。IT 部門里誰(shuí)能升級(jí)或修改軟件包必須有著非常明確的規(guī)定。必須有人監(jiān)管著所發(fā)生的一切。