谷歌重新定義開(kāi)源軟件漏洞治理框架

一、摘要

開(kāi)源軟件的安全問(wèn)題理所當(dāng)然地引起了業(yè)界的關(guān)注，但解決方案需要對(duì)執(zhí)行過(guò)程中的挑戰(zhàn)和合作達(dá)成共識(shí)。這個(gè)問(wèn)題很復(fù)雜，涉及諸多方面：供應(yīng)鏈、依賴庫(kù)管理、身份識(shí)別和構(gòu)建流水線（build pipelines）。如果能夠準(zhǔn)確定義問(wèn)題，便可更快得出解決方案;為此，我們提出了一個(gè)框架（“知悉、預(yù)防、修復(fù)”），該框架是關(guān)于行業(yè)內(nèi)應(yīng)當(dāng)如何考慮開(kāi)源軟件中的漏洞，并列舉了需要首先解決的具體問(wèn)題，包括：

就元數(shù)據(jù)和身份識(shí)別標(biāo)準(zhǔn)達(dá)成共識(shí)。我們需要在基本面上達(dá)成一致來(lái)解決這些行業(yè)復(fù)雜問(wèn)題。就元數(shù)據(jù)細(xì)節(jié)和身份識(shí)別達(dá)成的共識(shí)將有助于實(shí)現(xiàn)自動(dòng)化，減少更新軟件所需的工作量，并將漏洞的影響最小化。

提高關(guān)鍵軟件的透明度并加強(qiáng)代碼審查。對(duì)于安全關(guān)鍵性軟件，我們需要就開(kāi)發(fā)流程達(dá)成一致意見(jiàn)，確保充分的審查，避免單方面變更，并透明公開(kāi)地生成定義明確、可被驗(yàn)證的正式版本。

下面提出的框架和目標(biāo)，旨在引發(fā)全行業(yè)對(duì)開(kāi)源軟件的安全問(wèn)題進(jìn)行探討并尋求進(jìn)步。

由于近期發(fā)生的事件，軟件界對(duì)供應(yīng)鏈攻擊的實(shí)際風(fēng)險(xiǎn)有了更加深刻的了解。因?yàn)槿看a和依賴關(guān)系都公開(kāi)可查驗(yàn)，開(kāi)源軟件在安全方面的風(fēng)險(xiǎn)相對(duì)較小。一般來(lái)講確實(shí)如此，但前提是人們真的有在查驗(yàn)。由于依賴關(guān)系眾多，要監(jiān)控所有這些依賴并不切實(shí)際，而且很多開(kāi)源包并沒(méi)有得到很好的維護(hù)。

程序通常直接或間接地依賴于數(shù)千個(gè)軟件包和庫(kù)。舉例來(lái)說(shuō)，Kubernetes現(xiàn)在依賴大約1000個(gè)軟件包。與閉源軟件相比，開(kāi)源軟件使用了更多的依賴庫(kù)，并且供應(yīng)商來(lái)源更加廣泛;因此需要信任相當(dāng)多的不同實(shí)體。這使得理解產(chǎn)品如何使用開(kāi)源軟件以及如何發(fā)現(xiàn)相關(guān)漏洞是極其困難的。此外，沒(méi)有辦法可以保證構(gòu)建出的程序與其源代碼相匹配。

退一步來(lái)講，雖然供應(yīng)鏈攻擊是一種風(fēng)險(xiǎn)，但絕大多數(shù)漏洞都是普通的、無(wú)意的--善意的開(kāi)發(fā)者所犯的無(wú)心之過(guò)。此外，相較于親自發(fā)現(xiàn)漏洞，惡意攻擊者更傾向于利用已知漏洞，原因很簡(jiǎn)單：因?yàn)檫@會(huì)使得攻擊更加容易。因此，我們必須集中精力做出根本性改變以解決大部分漏洞，唯有這樣做才會(huì)使整個(gè)行業(yè)得以深入解決那些復(fù)雜問(wèn)題（包括供應(yīng)鏈攻擊）。

幾乎沒(méi)有任何組織能夠驗(yàn)證他們使用的所有程序包，更不用說(shuō)這些包的更新了。就目前而言，跟蹤這些軟件包需要耗費(fèi)大量的基礎(chǔ)設(shè)施和顯著的人力開(kāi)銷。我們?cè)贕oogle擁有這些資源，并不遺余力管理我們使用的開(kāi)源包--包括為我們內(nèi)部使用的所有開(kāi)源包維護(hù)一個(gè)私有倉(cāng)庫(kù)--但想要跟蹤全部的更新仍然困難重重。龐大的更新流令人望而生畏。所有解決方案的核心部分都是更高程度的自動(dòng)化，這將是2021年及以后我們開(kāi)源安全工作的關(guān)鍵主題。

因?yàn)檫@是一個(gè)需要行業(yè)合作的復(fù)雜問(wèn)題，所以我們目的是圍繞具體的目標(biāo)展開(kāi)對(duì)話。Google聯(lián)合創(chuàng)立了OpenSSF并將其作為此次合作的重點(diǎn)。但是為了更進(jìn)一步，我們需要整個(gè)行業(yè)參與進(jìn)來(lái)，并就問(wèn)題所在以及如何解決問(wèn)題達(dá)成共識(shí)。作為開(kāi)始，我們提出了解決此問(wèn)題的一種方法，以及一系列具體的目標(biāo)，希望這些目標(biāo)可以加速產(chǎn)生整個(gè)行業(yè)的解決方案。

我們建議將這一挑戰(zhàn)定義為三個(gè)基本獨(dú)立的問(wèn)題領(lǐng)域，每個(gè)領(lǐng)域都有具體的目標(biāo)。

知悉軟件中的漏洞

預(yù)防新漏洞的產(chǎn)生

修復(fù)或消除漏洞

另一個(gè)相關(guān)但獨(dú)立的問(wèn)題是提高開(kāi)發(fā)過(guò)程的安全性，這對(duì)保障供應(yīng)鏈的安全至關(guān)重要。我們將在第四節(jié)“關(guān)鍵軟件的預(yù)防措施”中概述該問(wèn)題所面臨的挑戰(zhàn)并提出目標(biāo)。

二、知悉已有漏洞

由于各種原因，知悉已有漏洞遠(yuǎn)比預(yù)期來(lái)的更困難。盡管存在漏洞報(bào)告機(jī)制，但很難確認(rèn)軟件的特定版本是否受到漏洞影響。

1. 目標(biāo)：獲得準(zhǔn)確的漏洞數(shù)據(jù)

首先，從所有可用的數(shù)據(jù)來(lái)源中準(zhǔn)確獲取漏洞元數(shù)據(jù)至關(guān)重要。例如，知悉哪個(gè)版本引入了漏洞，將有助于判斷某個(gè)軟件是否受影響;而知悉何時(shí)漏洞被修復(fù)，就能準(zhǔn)確及時(shí)地打補(bǔ)?。úp少潛在的漏洞利用窗口期）。理想情況下，這種分流工作流程應(yīng)當(dāng)自動(dòng)化完成。

其次，大多數(shù)漏洞都存在于依賴庫(kù)中，而不是在你直接編寫或控制的代碼中。因此，即使你的代碼沒(méi)有改動(dòng)，漏洞也會(huì)不斷地出現(xiàn)，此消彼長(zhǎng)。

2. 目標(biāo)：建立漏洞數(shù)據(jù)庫(kù)的標(biāo)準(zhǔn)架構(gòu)

需要建立基礎(chǔ)設(shè)施和行業(yè)標(biāo)準(zhǔn)來(lái)跟蹤和維護(hù)開(kāi)源漏洞、了解漏洞產(chǎn)生的后果并管理緩解措施。標(biāo)準(zhǔn)的漏洞架構(gòu)將允許通用工具跨多個(gè)漏洞數(shù)據(jù)庫(kù)工作并簡(jiǎn)化跟蹤任務(wù)，特別是當(dāng)漏洞涉及多種語(yǔ)言或子系統(tǒng)時(shí)。

3. 目標(biāo)：準(zhǔn)確跟蹤依賴關(guān)系

我們需要更好的工具來(lái)快速了解哪些軟件受到新發(fā)現(xiàn)漏洞的影響，而依賴樹(shù)的巨大規(guī)模和動(dòng)態(tài)特性使這一問(wèn)題變得更加棘手。由于只有通過(guò)安裝程序才能解析出軟件的版本，因此如果不實(shí)際進(jìn)行安裝操作，當(dāng)前也很難有辦法準(zhǔn)確地預(yù)測(cè)出被調(diào)用的軟件版本。

三、預(yù)防新增漏洞

理想的做法是預(yù)防漏洞的產(chǎn)生，盡管測(cè)試和分析工具有所幫助，但預(yù)防始終是一個(gè)難題。在這里，我們著重討論兩個(gè)特定方面。

決定采用新的依賴庫(kù)時(shí)需要理解風(fēng)險(xiǎn)。

改進(jìn)安全關(guān)鍵性軟件（security-critical software）的開(kāi)發(fā)流程。

1. 目標(biāo)：理解新依賴庫(kù)的風(fēng)險(xiǎn)

第一個(gè)方面主要是：當(dāng)你決定使用一個(gè)軟件包的時(shí)候，需要了解它的漏洞。接受一個(gè)新的依賴庫(kù)會(huì)帶來(lái)固有風(fēng)險(xiǎn)，因此需要做出明智的決定。一旦使用了依賴庫(kù)，隨著時(shí)間的推移通常會(huì)變得越來(lái)越難以移除。了解漏洞是一個(gè)不錯(cuò)的開(kāi)始，但我們還可以更進(jìn)一步。

理想情況下，如果沒(méi)有顯式更新的情況，依賴庫(kù)的版本應(yīng)該是穩(wěn)定的，但具體的行為因打包系統(tǒng)而異。Go Modules和NuGet這兩個(gè)打包系統(tǒng)都以穩(wěn)定為目標(biāo)，而不追求快速升級(jí)，默認(rèn)情況下它們都只在需求項(xiàng)更新時(shí)才會(huì)安裝升級(jí)程序;依賴關(guān)系可能有誤，但它們只在顯式更新時(shí)才會(huì)去修改。

許多漏洞是由于在軟件開(kāi)發(fā)過(guò)程中沒(méi)有遵守安全最佳實(shí)踐而產(chǎn)生的。所有的貢獻(xiàn)者是否都使用了雙因素認(rèn)證（2FA）？項(xiàng)目是否設(shè)置了持續(xù)集成并運(yùn)行測(cè)試？是否集成了模糊測(cè)試？這些類型的安全檢查將幫助使用者了解新依賴庫(kù)帶來(lái)的風(fēng)險(xiǎn)。對(duì)于“得分”較低的軟件包需要仔細(xì)審查，并制定風(fēng)險(xiǎn)緩解計(jì)劃。

OpenSSF最近公布的“安全記分卡”（Security Scorecards）項(xiàng)目嘗試以全自動(dòng)的方式生成這些數(shù)據(jù)。使用記分卡還可以幫助抵御猖獗的名稱仿冒（Typosquatting）攻擊（惡意軟件包采用與流行軟件包相似的名稱），因?yàn)榉旅暗膼阂廛浖梅謺?huì)很低，并且無(wú)法通過(guò)很多安全檢查。

改進(jìn)關(guān)鍵軟件的開(kāi)發(fā)流程不僅僅與漏洞預(yù)防相關(guān)，我們將在后續(xù)章節(jié)中進(jìn)一步討論。

四、修復(fù)或消除漏洞

傳統(tǒng)意義上的修復(fù)漏洞問(wèn)題超出了我們的討論范圍，但對(duì)于管理軟件依賴庫(kù)中的漏洞這一具體問(wèn)題，需要我們做的還有很多。雖然現(xiàn)在沒(méi)什么幫助，但隨著我們提高準(zhǔn)確度，有必要對(duì)新的流程和工具進(jìn)行投資。

當(dāng)然，一種選擇是直接修復(fù)漏洞。如果你能通過(guò)向后兼容的方式完成修復(fù)，那么該修復(fù)程序就可以為大家所用。但面臨的挑戰(zhàn)是，你不太可能擁有關(guān)于這個(gè)漏洞的專業(yè)知識(shí)，也沒(méi)有辦法直接進(jìn)行修改。修復(fù)漏洞的前提是軟件維護(hù)者意識(shí)到問(wèn)題，并且公開(kāi)漏洞相關(guān)的知識(shí)和資源。

相反，如果你只是簡(jiǎn)單移除包含漏洞的依賴庫(kù)，那么對(duì)于你和那些導(dǎo)入或使用你軟件的人來(lái)說(shuō)漏洞被修復(fù)了，但對(duì)其他人則沒(méi)有。這是一個(gè)可由你直接控制的變更。

上述場(chǎng)景描述的是你的軟件與漏洞分別位于依賴關(guān)系鏈的兩端，但在實(shí)踐中可能還會(huì)存在許多其他關(guān)聯(lián)軟件包。大家普遍寄希望于依賴鏈上的某個(gè)人來(lái)修復(fù)它。不幸的是，僅修復(fù)一個(gè)環(huán)節(jié)是遠(yuǎn)遠(yuǎn)不夠的。只有你和漏洞之間依賴鏈中的每一個(gè)環(huán)節(jié)都更新完畢后，你的軟件才算被修復(fù)。每一個(gè)環(huán)節(jié)都必須引用其依賴鏈以下軟件包的已修復(fù)版本來(lái)清除漏洞。因此，更新需要自下而上地進(jìn)行，除非你能完全消除依賴關(guān)系（這或許需要類似的英雄膽識(shí)，而且?guī)缀醪豢赡馨l(fā)生——但在可能的情況下，這其實(shí)是最好的解決方案）。

1. 目標(biāo)：了解消除漏洞的可選方案

時(shí)至今日，我們對(duì)這一過(guò)程仍缺乏清晰認(rèn)知：別人已經(jīng)取得了哪些進(jìn)展？應(yīng)該在哪個(gè)層面上應(yīng)用哪個(gè)升級(jí)程序？這個(gè)過(guò)程又卡在哪里？誰(shuí)來(lái)負(fù)責(zé)修復(fù)漏洞本身？誰(shuí)來(lái)負(fù)責(zé)傳播修復(fù)程序？

2. 目標(biāo)：快速修復(fù)通知

最終而言，你的依賴庫(kù)漏洞將被修復(fù)，你可以在本地升級(jí)到新版本。但重要的是搞清楚這件事何時(shí)會(huì)發(fā)生，因?yàn)樗梢钥焖贉p少漏洞的暴露風(fēng)險(xiǎn)。此外，我們還需要一個(gè)漏洞發(fā)現(xiàn)通知系統(tǒng);通常來(lái)說(shuō)，新漏洞往往意味著新發(fā)現(xiàn)了潛伏的問(wèn)題，即使實(shí)際代碼并未改動(dòng)（比如Unix實(shí)用程序sudo漏洞已有10年的歷史）。對(duì)于大型項(xiàng)目來(lái)說(shuō)，大多數(shù)這樣的問(wèn)題出現(xiàn)于間接依賴庫(kù)中。如今，我們還缺乏做好通知系統(tǒng)所需的準(zhǔn)確度，因此在我們提高漏洞準(zhǔn)確度和改進(jìn)元數(shù)據(jù)（如上文所述）的同時(shí)，我們也應(yīng)該推動(dòng)通知系統(tǒng)的進(jìn)步。

目前為止，我們僅描述了一種簡(jiǎn)單情形：一連串向后兼容的升級(jí)，這意味著除了漏洞被消除之外，行為沒(méi)有區(qū)別。

但實(shí)際上，升級(jí)往往并不向后兼容，或者被版本限制要求所阻礙。這些問(wèn)題意味著更新依賴樹(shù)深處的軟件包必然會(huì)在依賴鏈上層引起一些混亂，或者至少會(huì)導(dǎo)致需求項(xiàng)更新。這種情況通常出現(xiàn)在最新版本（比如說(shuō)1.3版）有了更新程序，但你的軟件或相關(guān)的包需要引用1.2版時(shí)。這種情況司空見(jiàn)慣，成為一項(xiàng)重大挑戰(zhàn)，由于很難讓開(kāi)源項(xiàng)目的所有者更新相關(guān)的包，因此變得更加艱巨。此外，如果你在成百上千處使用了某個(gè)軟件包（這對(duì)于大型企業(yè)來(lái)說(shuō)并不瘋狂），那么你可能需要經(jīng)歷成百上千次更新過(guò)程。

3. 目標(biāo)：修復(fù)廣泛使用的版本

修復(fù)舊版本中的漏洞同樣重要，尤其是那些使用頻繁的版本。這種修復(fù)方式常見(jiàn)于那些擁有長(zhǎng)期支持的軟件中，但在理想情況下，所有廣泛使用的版本都應(yīng)該被修復(fù)，特別是包含安全風(fēng)險(xiǎn)的版本。

自動(dòng)化方法可能會(huì)有所幫助：給定某個(gè)版本的修復(fù)代碼，或許我們可以為其他版本自動(dòng)生成良好的備選修復(fù)代碼。目前這個(gè)過(guò)程有時(shí)是手工完成的，但如果此過(guò)程被大大簡(jiǎn)化，我們就能修復(fù)更多的版本，減少依賴鏈更高層的工作。

綜上所述，我們需要更便捷且更及時(shí)地修復(fù)漏洞，尤其是依賴庫(kù)中的漏洞。不僅是最新版本，廣泛使用的版本也需要獲得更多修復(fù)的機(jī)會(huì)，因?yàn)樽钚掳姹就ǔ０衅渌兏院茈y被采用。

最后，在“修復(fù)”方面還有很多其他選擇，包括各種緩解措施，比如避免調(diào)用特定方法，或者通過(guò)沙箱或訪問(wèn)控制來(lái)限制風(fēng)險(xiǎn)。這些都是重要且可行的備選方案，理應(yīng)得到更多的討論和支持。

五、關(guān)鍵軟件的預(yù)防措施

上述框架廣泛適用于各種漏洞，無(wú)論是惡意攻擊者蓄意造成的，或者僅僅是無(wú)心之過(guò)。雖然前面建議的目標(biāo)涵蓋了大多數(shù)漏洞，但僅靠這些并不足以防止惡意行為。為了對(duì)預(yù)防惡意攻擊者（包括供應(yīng)鏈攻擊）做出實(shí)質(zhì)性改變，我們需要改進(jìn)開(kāi)發(fā)流程。

這是一項(xiàng)艱巨的任務(wù)，并且目前對(duì)于大多數(shù)的開(kāi)源項(xiàng)目來(lái)說(shuō)都不切實(shí)際。開(kāi)源之美某種意義上來(lái)說(shuō)是由于缺少流程的約束，因此吸引了廣泛的貢獻(xiàn)者。然而，這種靈活性會(huì)阻礙安全方面的考慮。我們需要貢獻(xiàn)者，但我們不能寄希望于每個(gè)人都同樣關(guān)注安全問(wèn)題。相反，我們必須確定關(guān)鍵軟件包并加以保護(hù)。盡管可能會(huì)增加開(kāi)發(fā)人員之間的摩擦，但這些關(guān)鍵包必須遵循一系列更嚴(yán)格的開(kāi)發(fā)標(biāo)準(zhǔn)。

1. 目標(biāo)：定義符合更高標(biāo)準(zhǔn)的“關(guān)鍵”開(kāi)源項(xiàng)目的評(píng)判準(zhǔn)則

確定廣泛被依賴的“關(guān)鍵”軟件包至關(guān)重要，若失陷會(huì)危及關(guān)鍵基礎(chǔ)設(shè)施或用戶隱私。因此這些軟件包必須遵循更高的標(biāo)準(zhǔn)，我們?cè)谙挛闹懈攀隽似渲幸恍?biāo)準(zhǔn)。

如何定義“關(guān)鍵”的標(biāo)準(zhǔn)并不明確，隨著時(shí)間的推移，定義的范圍可能還會(huì)擴(kuò)大。除了顯而易見(jiàn)的軟件，如OpenSSL或密鑰加密庫(kù)，還有一些被廣泛使用的軟件包，其覆蓋面之廣使它們值得受到保護(hù)。Google啟動(dòng)了關(guān)鍵性得分項(xiàng)目（Criticality Score project），與社區(qū)一起對(duì)該問(wèn)題集思廣益，同時(shí)與哈佛大學(xué)合作開(kāi)展開(kāi)源普查（Open Source Census）工作。

2. 目標(biāo)：禁止對(duì)關(guān)鍵軟件進(jìn)行任何單方面變更

我們?cè)贕oogle中遵循的一個(gè)原則是，變更不應(yīng)該是單方面的--也就是說(shuō)，每一個(gè)變更都至少涉及一個(gè)作者和一個(gè)審核者/批準(zhǔn)者。目標(biāo)是限制對(duì)手可以憑借一己之力做的事情--我們需要確保有人真正在檢查這些變更。對(duì)于開(kāi)源項(xiàng)目來(lái)說(shuō)，要做好這一點(diǎn)其實(shí)比在一家公司內(nèi)部要難得多，因?yàn)楣緝?nèi)部擁有嚴(yán)格的身份認(rèn)證，并且會(huì)執(zhí)行代碼審查和其他檢查。

避免單方面變更可以分為兩個(gè)子目標(biāo)。

（1） 目標(biāo)：要求對(duì)關(guān)鍵軟件進(jìn)行代碼審查。

代碼審查不僅是改進(jìn)代碼的好方法，還能確保除了作者之外，至少有一個(gè)人在檢查每一項(xiàng)變更。代碼審查是Google內(nèi)部所有變更的標(biāo)準(zhǔn)做法。

（2） 目標(biāo)：對(duì)關(guān)鍵軟件的變更需要得到兩個(gè)獨(dú)立方的批準(zhǔn)。

為了真正實(shí)現(xiàn)“有人在檢查”的目標(biāo)，我們需要審查者獨(dú)立于代碼貢獻(xiàn)者。而對(duì)于重大變更，我們可能需要不止一個(gè)獨(dú)立審查。當(dāng)然，我們需要理清到底什么才算是“獨(dú)立”審查，但對(duì)大多數(shù)行業(yè)內(nèi)的審查而言，獨(dú)立性思想都至關(guān)重要。

3. 目標(biāo)：對(duì)關(guān)鍵軟件參與者進(jìn)行身份認(rèn)證

獨(dú)立性的概念通常意味著你了解參與者——匿名參與者不能被認(rèn)為是獨(dú)立的或值得信賴的。時(shí)至今日，我們基本上都使用化名：同一個(gè)人反復(fù)使用同一個(gè)身份，從而積攢聲譽(yù)，但我們并不了解這個(gè)人是否可信。這就引出了一系列的子目標(biāo)。

（1） 目標(biāo)：對(duì)于關(guān)鍵軟件，所有者和維護(hù)者不能匿名。

攻擊者都喜歡匿名。在過(guò)去的供應(yīng)鏈攻擊中，攻擊者利用匿名性，通過(guò)軟件包社區(qū)努力成為維護(hù)者，而沒(méi)有人意識(shí)到這個(gè)“新的維護(hù)者”具有惡意企圖（入侵代碼最終被注入上游）。為了減輕這種風(fēng)險(xiǎn)，我們認(rèn)為關(guān)鍵軟件的所有者和維護(hù)者一定不能匿名。

可以想見(jiàn)，與所有者和維護(hù)者不同，貢獻(xiàn)者可以匿名，但前提是他們的代碼已經(jīng)通過(guò)了可信人士的多次審查。

也可以想見(jiàn)，我們可以擁有“已驗(yàn)證”的身份，也就是說(shuō)：有一個(gè)可信實(shí)體知悉他的真實(shí)身份，但出于隱私原因，公眾并不知道。這將有助于有關(guān)獨(dú)立性的決策以及對(duì)非法行為進(jìn)行起訴。

（2） 目標(biāo)：為關(guān)鍵軟件的貢獻(xiàn)者提供嚴(yán)格的身份認(rèn)證。

惡意攻擊者會(huì)尋找容易的攻擊載體，所以網(wǎng)絡(luò)釣魚攻擊和其他形式的憑證盜竊行為很常見(jiàn)。一個(gè)顯而易見(jiàn)的改進(jìn)措施是要求使用雙因子認(rèn)證，尤其是對(duì)于所有者和維護(hù)者。

（3） 目標(biāo)：身份的聯(lián)合模型

為了繼續(xù)保持開(kāi)源的包容性，我們需要能夠信任各式各樣的身份，但是可驗(yàn)證的完整性仍不可或缺。這意味著身份的聯(lián)合模型，也許類似于我們今天支持聯(lián)合SSL證書的方式——多個(gè)團(tuán)體可以生成有效的證書，但必須具備嚴(yán)格的審計(jì)和相互監(jiān)督。

OpenSSF的數(shù)字身份認(rèn)證工作組已經(jīng)開(kāi)始對(duì)該話題進(jìn)行討論。

（4） 目標(biāo)：風(fēng)險(xiǎn)變化通知

為涵蓋風(fēng)險(xiǎn)的變化，我們應(yīng)當(dāng)擴(kuò)大通知的范圍。最明顯的是所有權(quán)變化，這可能是新攻擊的前奏（如最近的NPM事件流（NPM event-stream）失陷）。其他例子包括發(fā)現(xiàn)憑證被盜、串通或其他惡意行為者的行為。

（5） 目標(biāo)：增加構(gòu)件的透明度

通常使用安全散列來(lái)檢測(cè)構(gòu)件（artifact）是否完好無(wú)損，使用數(shù)字簽名來(lái)證明真實(shí)性。增加“透明度”意味著這些證明會(huì)被公開(kāi)記錄，從而將所有意圖文檔化。反過(guò)來(lái)，即使用戶沒(méi)有感知，外部各方也可以監(jiān)控日志中是否存在偽造版本。更進(jìn)一步來(lái)說(shuō)，當(dāng)憑證被盜時(shí)，我們可以了解到這些憑證被用來(lái)簽署了哪些構(gòu)件，并可以設(shè)法刪除它們。這種透明性，包括持久的公共日志和第三方監(jiān)控，已被成功應(yīng)用于SSL證書，我們也為包管理器提出了一種類似方法。知悉你使用了正確的軟件包或二進(jìn)制文件，類似于知悉你正在訪問(wèn)一個(gè)網(wǎng)站的真實(shí)版本一樣。

（6） 目標(biāo)：信任構(gòu)建過(guò)程

1984年，肯-湯普森著名的圖靈獎(jiǎng)演講證明了僅靠真實(shí)可信的源代碼還遠(yuǎn)遠(yuǎn)不夠，最近的事件表明構(gòu)建過(guò)程攻擊也是一種真正的威脅。如何確認(rèn)你的構(gòu)建系統(tǒng)是可信的？它的所有組件都必須可信，并通過(guò)一個(gè)持續(xù)的建立信任的過(guò)程來(lái)驗(yàn)證。

可重復(fù)構(gòu)建（Reproducible builds）會(huì)有所幫助（構(gòu)建具有確定的結(jié)果，由此我們可以驗(yàn)證我們的構(gòu)建是正確的），但由于臨時(shí)的數(shù)據(jù)（如時(shí)間戳）最終會(huì)出現(xiàn)在構(gòu)建的發(fā)行版中，因此這很難實(shí)現(xiàn)。而安全可重復(fù)的構(gòu)建需要驗(yàn)證工具，而驗(yàn)證工具又必須經(jīng)過(guò)可驗(yàn)證和可重復(fù)的構(gòu)建，以此類推。我們必須打造一個(gè)可信工具和構(gòu)建產(chǎn)品的網(wǎng)絡(luò)。

對(duì)構(gòu)件和工具的信任都可以通過(guò)“委托”（上述透明過(guò)程的變體，被稱為二進(jìn)制授權(quán)）來(lái)建立。在Google內(nèi)部，構(gòu)建系統(tǒng)會(huì)對(duì)所有構(gòu)件進(jìn)行簽名，并生成與源代碼相關(guān)聯(lián)的清單。對(duì)于開(kāi)源項(xiàng)目來(lái)說(shuō)，一個(gè)或多個(gè)受信任的代理可以將構(gòu)建作為一項(xiàng)服務(wù)來(lái)運(yùn)行，對(duì)構(gòu)件簽名以證明他們對(duì)其完整性負(fù)責(zé)。這種生態(tài)系統(tǒng)理應(yīng)存在，大部分情況下只需要大家都意識(shí)到這一點(diǎn)，并按照證明文書格式簽署一些協(xié)議，我們就可以安全地自動(dòng)化上述流程。

本節(jié)所述的措施非常適合于一般性的軟件，目前在Google內(nèi)部已廣泛使用，但是對(duì)于開(kāi)源項(xiàng)目來(lái)說(shuō)，它們的工作量要大得多。我們期望通過(guò)專注于少數(shù)關(guān)鍵的軟件，至少在關(guān)鍵軟件上實(shí)現(xiàn)這些目標(biāo)。隨著工具和自動(dòng)化程度的提高，這些目標(biāo)將更容易被廣泛采用。

六、總結(jié)

開(kāi)源的本質(zhì)要求我們通過(guò)共識(shí)和協(xié)作來(lái)解決問(wèn)題。對(duì)于漏洞等復(fù)雜主題，這意味著要圍繞關(guān)鍵問(wèn)題進(jìn)行集中討論。我們?yōu)檫@種討論提出了一種框架方法，并定義了一系列目標(biāo)，我們希望這些目標(biāo)能夠加速整個(gè)行業(yè)的討論并得出最終的解決方案。第一組目標(biāo)廣泛適用于各種漏洞，其實(shí)質(zhì)是關(guān)于實(shí)現(xiàn)自動(dòng)化，減少風(fēng)險(xiǎn)和辛勞。
責(zé)編AJX