現(xiàn)代軟件開發(fā)的依賴樹讓黑客更容易從小型開源項目入手攻克。

若惡意黑客參與了小型開源軟件的開發(fā)，在自身關(guān)鍵應(yīng)用中包含了這些開源軟件的公司企業(yè)就可能面臨遭遇漏洞利用的風(fēng)險。

安全專家指出，這些項目的開源本質(zhì)和代碼的廣泛應(yīng)用，對企業(yè)造成了切實(shí)的威脅。

一旦潛入開源項目，罪犯就有多種下手方式可供選擇，但必須動作夠快。

因為無論是后門鍵盤記錄器還是某種木馬，如果不是動手夠快，或者真的非常非常隱蔽，用不了多久就會被 “眾人之眼” 揪出。

網(wǎng)絡(luò)罪犯之所以熱衷于黑開源項目，正是由于開源項目兼具靈活性和可用性的特點(diǎn)，能為黑客行動的開展帶來大量機(jī)會。

真可謂眾所周知的攻擊途徑了。

而且開源項目被黑概率很可能比大眾認(rèn)知的要高得多。

安全公司 Checkmarx 安全研究主管 Eran Yalon 就表示：“這可不是什么道聽途說，而是身邊時時刻刻在發(fā)生的事。

以前就曾出現(xiàn)過這種事情，我們沒理由認(rèn)為現(xiàn)在就絕跡了。

幾乎所有開源項目都要求貢獻(xiàn)者的工作要經(jīng)過項目其他成員審核才能并入項目。

審核層級隨貢獻(xiàn)者個人聲譽(yù)而遞減，貢獻(xiàn)者受信度越高，則審核層級越少。

尤其是在大型知名開源項目中，比如主流 Linux 發(fā)行版，整個審核過程非常精細(xì)完備，也有充足的人力資源持續(xù)執(zhí)行這一規(guī)程。

項目越小，則可供保障安全的資源就越少。

所以，小型項目被黑的情況也就更常見了。

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

超小型開源軟件包也有可能是大型軟件包的依賴，無論依賴層有多深。

你覺得自己的項目只有一兩個依賴，但實(shí)際上可能有成百上千的，而且你根本無法徹查。

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

“Event-stream 項目的開發(fā)人員沒有足夠的時間來維護(hù)。

一名惡意用戶說服了開發(fā)者，接管了該項目。

剛剛接管的時候該項目還是像以往一樣維護(hù)。

此后，這名惡意用戶修改了 Event-stream 自身依賴的一個包，注入了可以劫持特定比特幣錢包的代碼。

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

另一起非惡意事件例證了小型開源軟件包的深遠(yuǎn)影響：2016 年 3 月 23 日，開發(fā)者 Azer Koçulu 刪除了他通過 NPM 分發(fā)的 250 個模塊。

其中一個模塊非常之小，僅含 11 行代碼，是往文本字符串左側(cè)添加空格以適應(yīng)變量定義的。

結(jié)果，這個名為 “left-pad” 的模塊是全世界成千上萬的企業(yè)和商業(yè)軟件所用依賴包的一部分，包括用 JavaScript 開發(fā)的中流砥柱 Babel 和 Node 構(gòu)建的那些。

而由于 “left-pad” 下架，這些數(shù)以千萬計的應(yīng)用全都失靈了。

雖說開發(fā)者重新創(chuàng)建該功能也不是很難，但如此簡單的動作受到的短期影響也已經(jīng)十分巨大。

(近) 普遍威脅開源的普遍性眾所周知。

Gartner 數(shù)據(jù)顯示，95% 的企業(yè)在內(nèi)部項目中使用開源代碼。

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

于是，開發(fā)團(tuán)隊怎么增強(qiáng)代碼安全性呢？第一步就是甄選納入技術(shù)棧的庫和開源項目。

有些項目的 “履歷” 優(yōu)于其他項目。

第二步，確保所用項目是活躍項目，有定期更新。

查看項目的活動歷史可以確保項目是有眾多活躍開發(fā)者支持的好項目。

有漏洞出現(xiàn)時能被及時修復(fù)的概率也高得多。

而一旦補(bǔ)丁可用，要確保及時應(yīng)用補(bǔ)丁修復(fù)漏洞。

常有關(guān)注零日漏洞和黑客國家隊的組織機(jī)構(gòu)自己的 “基本代碼安全” 卻沒做好。

保持開源代碼更新和做好基礎(chǔ)的代碼掃描，才是最基本而堅實(shí)的網(wǎng)絡(luò)威脅防線。

這就是個信任問題：對開源項目和使用該代碼的內(nèi)部開發(fā)人員的信任。

惡意開源代碼包如果沒人用，也是不會造成嚴(yán)重后果的。

IT 部門里誰能升級或修改軟件包必須有著非常明確的規(guī)定。

必須有人監(jiān)管著所發(fā)生的一切。