安全運(yùn)營(yíng)團(tuán)隊(duì)通常都忙于處理惡意軟件、網(wǎng)絡(luò)釣魚(yú)和DDoS攻擊。但I(xiàn)T領(lǐng)域有塊地方卻是盡管有數(shù)據(jù)泄露、信譽(yù)損失、競(jìng)爭(zhēng)優(yōu)勢(shì)喪失的風(fēng)險(xiǎn)，很多安全運(yùn)營(yíng)團(tuán)隊(duì)卻都沒(méi)有給予足夠監(jiān)管的。

GitHub是超級(jí)流行的源代碼管理平臺(tái)，公司和個(gè)人都在用GitHub存儲(chǔ)和管理源代碼，保持軟件開(kāi)發(fā)項(xiàng)目平穩(wěn)進(jìn)行。GitHub以其實(shí)用的功能和用戶(hù)友好的界面攀上了全球最大代碼倉(cāng)庫(kù)的位置，如今其上托管著超過(guò)8000萬(wàn)源代碼庫(kù)。Facebook、谷歌和微軟的部分重要軟件項(xiàng)目也用到了GitHub。

GitHub無(wú)疑是成功案例。為什么安全運(yùn)營(yíng)團(tuán)隊(duì)需要多加注意呢？

這是因?yàn)?，GitHub如此流行，公司研發(fā)團(tuán)隊(duì)極有可能把一些項(xiàng)目也放到了GitHub上。但過(guò)去幾年的事實(shí)已經(jīng)證明，某些開(kāi)發(fā)人員那漫不經(jīng)心的GitHub使用習(xí)慣會(huì)產(chǎn)生嚴(yán)重的安全風(fēng)險(xiǎn)。即便開(kāi)發(fā)人員遵循最佳實(shí)踐，用ForTIfy一類(lèi)的源代碼分析工具檢查過(guò)提交源碼中是否存在安全漏洞，這些風(fēng)險(xiǎn)依然存在。

漫不經(jīng)心的安全操作本身就足夠危險(xiǎn)。而在黑客死死盯上這個(gè)管理松散的系統(tǒng)時(shí)，風(fēng)險(xiǎn)就更大了。

原因有很多：

1. 源代碼

存儲(chǔ)在GitHub上的軟件是很有價(jià)值的知識(shí)產(chǎn)權(quán)。將這些代碼復(fù)制下來(lái)有可能讓其他公司甚至民族國(guó)家快速研發(fā)出派生應(yīng)用，節(jié)省幾年甚至幾十年的研發(fā)時(shí)間，或者不付版權(quán)費(fèi)就利用了別人的商業(yè)秘密。黑客還可以盜取源代碼轉(zhuǎn)賣(mài)到暗網(wǎng)。

2. 攻擊方法

源代碼可能為黑客提供攻擊生產(chǎn)環(huán)境中軟件的思路。盜取源代碼能賦予他們時(shí)間去研究和查找漏洞，比通過(guò)滲透要簡(jiǎn)單得多。他們甚至可以在生產(chǎn)環(huán)境中運(yùn)行代碼并嘗試攻擊，不斷精煉攻擊，提升攻擊速度、隱蔽性和有效性。

3. 登錄憑證

提交到GitHub上的代碼和支持文件有時(shí)候一不小心就包含了登錄其他服務(wù)的憑證，比如登錄AWS的。黑客獲取到這些代碼，也就獲得了相關(guān)服務(wù)的訪問(wèn)權(quán)，有了盜取更多數(shù)據(jù)和中斷運(yùn)營(yíng)的機(jī)會(huì)。

4. 未授權(quán)訪問(wèn)

開(kāi)發(fā)人員通常都會(huì)有以個(gè)人郵箱賬戶(hù)登錄公司代碼庫(kù)的權(quán)限。這些賬戶(hù)就是漏洞，尤其是在開(kāi)發(fā)人員離職后。另外，開(kāi)發(fā)人員手里的權(quán)限往往還是公司所有代碼庫(kù)的，而不僅僅是自己負(fù)責(zé)的項(xiàng)目的，這就留下了巨大的攻擊界面。

5. 內(nèi)部人威脅

主動(dòng)監(jiān)視的缺乏可使得惡意內(nèi)部人易于隱藏異常行為。某個(gè)開(kāi)發(fā)人員訪問(wèn)幾十個(gè)代碼庫(kù)就是內(nèi)部人威脅的征兆，而此類(lèi)行為應(yīng)被檢測(cè)并標(biāo)記。

2016年Uber托管在GitHub上的源碼庫(kù)被滲透時(shí)，黑客收獲的贓物中有一部分就是登錄憑證。攻擊者不僅僅拿到了先進(jìn)的知識(shí)產(chǎn)權(quán);還挖到了內(nèi)含700萬(wàn)Uber司機(jī)和5000萬(wàn)客戶(hù)個(gè)人信息的AWS憑證。這些個(gè)人數(shù)據(jù)中包括了姓名、地址、駕照等等信息。

幸運(yùn)的是，安全運(yùn)營(yíng)團(tuán)隊(duì)可以采取一些實(shí)用措施來(lái)收緊公司GitHub代碼庫(kù)的安全。比如：

1. 清理登錄憑證

提醒開(kāi)發(fā)人員留心自己的GitHub登錄憑證。項(xiàng)目的訪問(wèn)權(quán)限只對(duì)參與項(xiàng)目的開(kāi)發(fā)人員開(kāi)放。當(dāng)開(kāi)發(fā)人員脫離項(xiàng)目，憑證應(yīng)被撤銷(xiāo)。

2. 反復(fù)檢查代碼庫(kù)設(shè)置

GitHub背后的軟件——軟件版本控制程序Git，原本是用來(lái)管理Linux內(nèi)核開(kāi)發(fā)的。無(wú)論Git還是GitHub，在開(kāi)源項(xiàng)目中的應(yīng)用都很廣。一些開(kāi)發(fā)人員，尤其是那些開(kāi)源項(xiàng)目貢獻(xiàn)者，基本將所有GitHub代碼庫(kù)都當(dāng)成公共的，也不管項(xiàng)目是否真的開(kāi)源。最好反復(fù)檢查一下公司的GitHub配置，確保項(xiàng)目訪問(wèn)權(quán)是否超出了所需范圍。

3. 公開(kāi)代碼中不混入秘密

提醒開(kāi)發(fā)人員不要將登錄憑證和其他高度敏感的信息混入了代碼、GitHub項(xiàng)目介紹頁(yè)或其他外部人可以訪問(wèn)的GitHub內(nèi)容。自Uber數(shù)據(jù)泄露事件之后，GitHub就敦促開(kāi)發(fā)人員小心對(duì)待此事，但來(lái)自安全運(yùn)營(yíng)團(tuán)隊(duì)的定期提醒永遠(yuǎn)不多余。

4. 監(jiān)測(cè)GitHub上的可疑行為

哪些行為是可疑的？代碼提交的激增、授權(quán)某人下載超大量源代碼、不正常位置的登錄、公司外部用戶(hù)的登錄或請(qǐng)求等等。

5. 收集GitHub日志

持續(xù)監(jiān)視GitHub的最佳方式，是收集公司代碼庫(kù)GitHub數(shù)據(jù)的日志。從現(xiàn)在開(kāi)始收集也為時(shí)不晚。

6. 對(duì)GitHub行為做個(gè)基線安全評(píng)估

可以用工具分析GitHub日志中報(bào)告的行為，定義出正常行為的基線，讓未來(lái)的異常行為檢測(cè)更加容易。

7. 自動(dòng)化GitHub日志監(jiān)視

你會(huì)想要持續(xù)監(jiān)視GitHub行為以確保公司源代碼安全，保證外部人沒(méi)有滲透你的代碼庫(kù)。寫(xiě)腳本來(lái)自動(dòng)化這一工作，或者找個(gè)預(yù)置了自動(dòng)化的解決方案都可以。

軟件代碼是公司最有價(jià)值資產(chǎn)之一。將GitHub納入公司安全運(yùn)營(yíng)團(tuán)隊(duì)常規(guī)威脅追捕工作不僅僅可以保護(hù)該有價(jià)值資產(chǎn)，還可以保住公司的信譽(yù)和競(jìng)爭(zhēng)優(yōu)勢(shì)。