美國關鍵基礎設施軟件供應鏈安全指南的十大謬誤

美國網絡和基礎設施安全局（CISA）等機構聯合發布的軟件供應鏈安全指南遭到了軟件開發業界人士的廣泛批評，企業網絡安全專家凱利肖特里奇認為這份指南脫離實際甚至非常危險，任何實施該指南的企業都將面臨災難性的后果。里奇為此專門發布了萬字長文，對指南進行了猛烈抨擊，并提出了自己的十大反對意見內容整理如下：

不久前，美國網絡安全和基礎設施安全局(CISA)、國家安全局(NSA)和國家情報總監辦公室(ODNI)發布了一份題為《保護軟件供應鏈——開發人員推薦實踐指南》（以下簡稱指南）的文件。我們原本期望該指南能夠提供企業提高系統應對供應鏈攻擊的彈性的實用方法，甚至新穎的方法，因為指南出自權威機構。

但結果非常讓人失望，該指南充斥著不切實際、令人困惑甚至危險的建議。

網絡安全界有一個集體謬論，即將“安全”作為首要任務是所有組織員工的“工作”。這種謬誤使組織無法獲得理想的防御結果。不幸的是，“軟件供應鏈安全指南”再次強化了這種謬誤。

針對《指南》中最顯著同時也是最危險的謬誤，筆者提出了十條反對意見：

1. 放慢軟件交付速度無助于安全，反而會傷害它

2. （該指南基于）一個底層悖論（“思維機器”悖論）

3. 指南對大多數企業不適用

4. 大多數企業都不想實施該指南

5. 安全供應商的配套解決方案被過分強調

6. 相關的安全和基礎設施創新被忽視

7. 關于軟件交付實踐和基本術語不準確

8. 主管部門傳遞的信息令人困惑、矛盾

9. 忽略了二階效應和潛在的因果因素

10. 無視安全廠商自身軟件安全的危險性

一、放慢軟件交付速度無助于安全，反而會傷害它

犧牲交付速度來換取安全，結果你兩樣都得不到。來自企業軟件工程界的經驗證據清楚地表明，開發速度不僅有利于業務成果（如發布速度），而且也有利于安全成果（如恢復時間、修復安全問題的時間）。相反，“保護軟件供應鏈指南”主張在整個軟件交付過程中增加額外障礙和摩擦，這會有效地拖慢開發速度。

該指南要求集中化管理的安全團隊對軟件工程活動施加重大限制，從而實現“將安全作為重中之重”。例如，將IDE（和插件）視為威脅，需要“在集成到任何開發人員機器之前進行預先批準、驗證和漏洞掃描”。

為了安全起見，速度甚至可靠性都被視為合理的“傷亡代價”。對于政府情報部門而言，國家安全是主要使命，因此他們認為安全摩擦和障礙是值得的。因為這些部門的目標不是通過更快地發布更多軟件來增加市場份額或客戶群或提高利潤率。這意味著他們的觀點根本無法轉化為私營部門的觀點，除非全社會都決定一家公司必須為國家安全而不是其股東服務。

實施該指南（例如被財富500強企業實施）導致的結果是：軟件難以開發交付。軟件工程師會辭職（因為低效工作而辭職）。無論企業的預算如何，根據指南的這些建議，企業的軟件開發周期將極為漫長，并且質量會更差——這也直接損害了開發更高質量、更安全軟件的目標。

二、指南基于一個潛在的悖論（“思維機器悖論”）

指南存在邏輯上的不一致（甚至可能是一個悖論），那就是：開發人員不可信，但又鼓勵人工運行的手動流程而不是實施自動化。如果指南對開發人員引入的“意外缺陷”存在偏見，那么為什么要推薦手動流程來引入更多“人為錯誤”的機會呢？

如果擔心開發人員的用戶憑證會導致惡意攻擊和錯誤，那么為什么要阻止（控制自動流程的擁有特權的機器）服務帳戶，因為它們本質上與特定用戶身份解綁？不使用服務帳戶的話，就會出現人類用戶離職或被解雇后憑據仍然可用的情況——這是一個危險的游戲。

該指南竭盡全力將開發人員描繪成內部威脅——無論是故意還是“訓練不足”——但隨后明確支持手動開發和發布流程。一方面軟件工程師個人不值得信任，但同時又要求他們執行和批準軟件交付活動，這不矛盾嗎？

誠然，人類的大腦并不擅長每次都以相同的方式執行任務。計算機在這方面的表現要好得多！但是，盡管指南警告了人為錯誤的危險，但同時又希望依靠這些人來完成可重復任務，而不是將任務自動化。

三、指南對大多數企業不適用

大多數企業沒有機會實施“保護軟件供應鏈”指南中的建議。雖然該指南宣稱是開發人員的參考指南，但實際上只是與NSA具有相同目標和資源的情報機構的參考指南。

谷歌經常遭到這樣的批評：谷歌提出的“有用”建議都是基于谷歌龐大的預算和人才庫，而沒有考慮“普通人”所面臨的限制和權衡。CISA、NSA和ODNI也掉入了類似的陷阱。

指南中的許多建議對企業來說是不切實際的，不僅僅是在“開發” 和“工程” 系統中禁止互聯網訪問的荒謬建議。例如，如果企業的開發文檔記錄了一個軟件執行的所有內容，則相當于編寫了兩次（并且文檔將不可避免地與源代碼不同）；如果根本沒有文檔，只閱讀源代碼，企業可能會過得更好。

另一個例子，指南還建議“在開發過程中對所有軟件組件執行模糊測試”。如果在開發過程中對所有軟件組件進行模糊測試是一項嚴格的要求，那么企業可能永遠都開發不出軟件。指南還建議“使用測試方法……確保修復的漏洞能夠真正修復所有可能的危害。” 如果企業軟件工程團隊有辦法看清楚所有威脅和漏洞，為什么還需要這個指南？

四、大多數企業都不想實施這個指南

大多數企業不想實施該指南。因為指南的建議沒有匹配企業規模，與企業軟件交付優先級不一致，并且降低了生產力。

以國家安全為使命的情報機構別無選擇，只能實施上述規范，否則就不能開發軟件。而以賺錢為使命的私營企業不會面臨同樣的限制；相反，私營企業面臨的限制是他們可支配的資源數量，為了支持他們的使命，通常最好將其用于收入或產生利潤的活動而不是那些阻礙或侵蝕它的活動。

無論企業的商業模式是B2B還是B2C，企業客戶的重中之重通常也不是安全性（盡管安全的優先級也很高）。只有當主要客戶是情報機構時，安全才會成為客戶最關心的問題，此類企業極少，特別是在財富500/1000強企業中。

站在大多數企業的視角，諸如“如果可能，工程網絡不應直接訪問互聯網” 和“如果可能，開發系統不應訪問互聯網” 等建議對于營利性企業來說非常不現實。同樣，在企業軟件開發的現實中，貶低“易于開發”的特性也是不合理的；更具建設性的建議是：必須將此類（安全）功能視為系統設計的一部分，并通過適當的訪問控制和審計日志提供保護。

從可靠性和彈性的角度來看，指南中的一些建議在軟件工程師眼中是“糟糕的做法”，因此會被拒絕。例如該指南建議使用“臨時SSH密鑰”來允許管理員訪問生產系統，而Ops工程師和SRE通常更喜歡不可變的基礎設施來專門禁止使用SSH，這有助于提高可靠性（并切斷對攻擊者的誘惑機制）。

五、推薦的安全供應商配套解決方案被過分強調

指南過分強調供應商工具，幾乎完全忽略了非供應商解決方案。具體來說，指南大肆吹捧現有安全供應商的一系列“配套”商業解決方案——IAST、DAST、RASP、SCA、EDR、IDS、AV、SIEM、DLP、“基于機器學習的保護” 等等——通篇充斥著贊美之詞，卻沒有提供關于流程自動化并使其可重復和可維護的建設性、理智的建議。

該指南明確表示不鼓勵開源軟件。通過設計實現的安全性也很少提及，例如DIE反脆弱安全模型（取代CIA模型）。該指南給人的印象是安全供應商成功地游說政府部門將他們包含在指南中，這（使企業）對其中立性提出了質疑。

事實上，為了推銷廠商的安全產品，指南甚至給出了諸如手動發布流程之類的危險建議。例如，指南建議：“在將軟件交付給客戶之前，開發人員應執行二進制成分分析以驗證軟件包的內容。” 但是，如果期望的結果是高質量、安全的軟件，則開發人員不應該自己執行軟件包發布（參見反對意見#2）。

再舉一個例子，他們建議“應該在簽入（check-in）和發布之前對每個版本的所有代碼執行SAST和DAST分析……”但是企業應該如何在簽入之前對代碼執行DAST/SAST？這是一個荒謬的“左移”，接下來是不是要在開發人員頭腦風暴如何編寫代碼時在他們的大腦里運行安全工具？

指南始終沒有提及有必要將DAST/SAST集成到開發人員工作流程中并確保不犧牲開發速度。在企業軟件安全中，安全附加解決方案的成功取決于其可用性或強制。

如果您使安全方式變得簡單，并確保軟件工程師不需要過度偏離他們的工作流程來與安全解決方案進行交互，那么很可能會產生更好的安全結果（或者至少不會導致更差的生產力結果）。另一種方法是強制實施安全解決方案；但如果該方案不可用，那么它將被繞過以確保工作仍然完成，除非有足夠的強制力來強制使用。

當推薦安全方案與指南的“斷開開發系統與互聯網的連接”的建議相結合時，它產生了一個問題：如果開發系統未連接到互聯網，您如何使用SCA工具等？

“基本衛生習慣”可以說比任何這些推薦方案都要好，包括：

• 了解存在哪些依賴項
• 確保了解向軟件中添加的內容的目的性
• 選擇您可以理解和維護的技術堆棧
• 選擇適合您正在開發的軟件的工具

“向軟件中增加內容的目的性”是什么意思？它的意思是：

• 將依賴項作為設計的一部分，而不是實現
• 謹慎添加依賴項
• 了解為什么包含其他庫和服務
• 了解依賴項的打包問題；例如，如果您包含一個依賴項，那么給操作和交付帶來成本是多少？
• 如果您依賴另一個團隊的服務，他們的SLO是什么？你信任他們嗎？它是一個穩定的系統嗎？是否存在問題？
• 如果它是一個開源庫，它是由一個人還是一個團隊維護？是一個提供付費支持服務的公司嗎？你能看到這家公司的更新和補丁歷史記錄嗎？

本質上，答案不是：“永遠不要依賴” ，或者，了解您的依賴項是什么。

總體而言，指南建議的緩解措施都是關于輸出而不是結果，是關于安全威脅因素，而不是實際保護任何東西并用實證方法驗證其有效性。很明顯，該指南不考慮每季度交付超過一次的組織；事實上，指南似乎認為快速的軟件交付是不可取的，是錯誤的（根據反對意見＃1）。

六、省略了相關的安全和基礎設施創新

如反對意見5中所述，該文件忽略了過去十年私營部門在軟件安全方面的大量創新。該指南采取了NSA/CISA/ODNI的安全方式優于私營部門現狀的立場，這是一種錯誤的二元論。

事實上，像SolarWinds這樣的公司已經承認自身“動作慢”是一個不利因素，并且已經對其實踐進行了現代化改造（包括使用開源代碼）以提高安全性。

沒有提及這些創新表明指南只是對手頭的問題進行了孤立的審查，這削弱了指南的知識中立性。下面列出了企業安全團隊希望在權威參考指南中看到的安全和基礎設施創新類型：

• Netflix的Wall-E框架
• Segment.io關于威脅建模
• Segment.io關于基于時間的訪問
• WebAssembly(Wasm)組件模型
• Wasmtime中的安全性和正確性字節碼聯盟
• IDE支持基于云的靜態分析
• 通過CI/CD的軟件交付
• 通過IaC自動修補
• GitHub的Dependabot工具
• 基于安全混沌工程的彈性安全日志管道
• Facebook on 2FA用于內部基礎設施身份驗證
• AWS的 API密鑰金絲雀令牌
• Google的配置分發工作示例

指南還應該采用來自私營部門的調查數據和報告來加強指導，例如最近的Golang調查（其中有一個專門針對安全性的部分，包括模糊測試）和GitHub從2020年開始的Octoverse安全報告。

指南還警告不要“允許對手在遠程環境中使用后門來訪問和修改受保護的基礎設施中的源代碼。” 這差不多就是推翻了過去30多年的源代碼管理(SCM)系統。

在現代軟件交付過程中，你不可能在沒有人注意到的情況下直接修改源代碼。甚至子版本也是建立在跟蹤增量的想法之上的。如果您更改了某些代碼，系統會記錄該代碼何時更改，由誰更改，何時更改。大多數開發工作流將SCM系統配置為在將更改合并到重要分支之前需要同行批準。幾十年來軟件工程的實踐一直如此，如果主管部門連這一點都不知道，那就堪憂了；如果指南推薦的供應商對此也沒有說法，那就說明聯邦采購存在嚴重問題。

七、指南關于軟件交付實踐的基本術語不準確

指南的整個文檔對現代軟件交付實踐存在大量誤解和不準確之處，包括對基本術語的誤解和不準確之處，例如CI/CD 、編排、每日構建、代碼存儲庫等等。這是信息安全相關的更大范疇的文化問題的一部分，即（政府部門）試圖規范他們不了解的東西。

參考指南似乎不了解企業工程團隊中誰在做什么。今天的產品和工程管理沒有定義安全實踐和程序，因為他們的優先事項不是安全，而是與他們權限范圍內的業務邏輯相對應的成功指標（通常與收入和客戶采用率有關）。QA的定義尤其令人困惑，這表明情報機構與私營企業的QA方法截然不同。

如果企業遵循“軟件開發組經理應確保開發過程避免有意或無意地將設計缺陷注入生產代碼”的建議，那么軟件可能永遠不會在私營企業再次發布。該指南似乎還認為軟件工程師不熟悉功能蠕變（feature creep）的概念，好像壓根不知道這是當今產品工程中的默認概念。

指南還充斥令人困惑的陳述，例如，“管理員不得（調整系統本身）除非必須修復生產的平均故障時間。” 我不知道它們是什么意思，也很難猜測它們可能意味著什么。這損害了指南的知識可信度。

即使在政府情報部門的專業領域（例如密碼學），該指南也不準確。“加密簽名可用于驗證軟件沒有被篡改，并且是由軟件供應商編寫的。” 這是錯誤的說法。加密簽名驗證供應商在某個時候申請了該密鑰，但并不能用來判定相關軟件的安全性。例如，游戲Genshin Impact的反作弊驅動程序的密鑰盡管容易受到提權漏洞的影響，但仍未被撤銷。

在另外一個例子中，指南的作者將“零日漏洞”稱為“容易被利用的媒介”。對于“方程式小組”黑客部隊及其算資金而言，這可能是正確的，但從大多數網絡犯罪分子以及企業的角度來看，情況并非如此。

企業面臨的主要威脅仍然是泄露的憑據、社會工程和錯誤配置。對于財富500強來說，如果攻擊者被迫使用零日漏洞來攻擊你，那說明你的安全工作到位了，黑客用盡了常規攻擊手段都不能奏效。這應該被認為是對企業安全態勢的一種肯定。

八、來自政府機構的令人困惑、矛盾的信息

令人困惑的是，去年還強調可重復性和可擴展性需求的CISA在指南中只有一次提到了可重復性的重要性。另一家政府機構(NSA)在2020年1月的報告中指出，供應鏈漏洞需要高度復雜的利用，同時在野外的流行率很低。

然而，該指南似乎要求軟件工程活動的設計將供應鏈漏洞作為最高權重因素。錯誤配置卻很少被提及，盡管NSA曾認為錯誤配置才是最普遍且最有可能被利用的。

在前面提到的CISA的指南中，強調了云計算和自動化的一些好處。但在本參考指南中，他們卻指出云比本地系統更危險（36條），但沒有解釋為什么會給出這個判斷。

指南的很多措辭也令人困惑，并且從未得到澄清。什么是“高風險”缺陷？在開發環境中，“網絡安全衛生”是什么意思？指南堅持“應該修復安全缺陷”，但缺陷（defeat）的定義是什么？它存在嗎？它是可利用的嗎？會是犯罪分子還是國家黑客的目標？都沒有明確定義。

九、忽略二階效應和潛在的因果因素

沒有考慮二階效應或潛在的因果因素，例如組織激勵和生產壓力。（有一次提到，一筆帶過，而且開發人員可能面臨各種限制）。這忽略了復雜系統中的彈性問題以及適用廣泛的行為科學。事實上，指南的這些僵化建議可以說是適應能力的反面教材，是彈性科學中的一個陷阱。

如果企業要嘗試實施這些建議（我非常不鼓勵他們這樣做），那么盡管存在令人暈厥的后果，如何實現這些建議的指導是必不可少的。如果不改變激勵措施，指南的大部分內容將變得毫無意義。

指南的實施建議也沒有討論用戶體驗(UX)考慮因素，這些建議可能比實施的內容更能影響安全結果，因為不可用的工作流程注定會被繞過。由于該指南忽略了軟件交付活動的復雜性并對開發人員行為進行“想當然”的解釋，因此給出的建議通常是“粗野”的。

指南錯過了討論使安全方式變得簡單的機會，最大限度減少開發人員工作流程摩擦的重要性，以及與IDE等工具集成的必要性等等。缺失這些內容導致指南既膚淺又空洞。

十、無視安全供應商軟件的安全性

指南不厭其煩地討論掃描第三方開發或使用的軟件的必要性，以及一長串商業安全工具如何能幫助企業做到這一點（參見反對意見#5）。奇怪的是，指南沒有提到需要掃描這些安全工具，例如為您的EDR或防病毒推薦解決方案執行SCA。

安全工具通常需要對系統進行特權訪問，無論是作為內核模塊運行還是需要對關鍵系統進行讀/寫(R/W)訪問。考慮到安全工具中嚴重漏洞的悠久歷史，這是一個相當令人不安的“疏漏”。除了端點安全工具產生的眾多軟件可靠性問題之外，還有很多問題也沒有得到提及。眾所周知，工程團隊出于正當理由而鄙視服務器上的端點安全：內核恐慌、CPU癱瘓以及其他令人惱火的奇怪故障。

指南高度質疑IDE和其他開發人員工具的安全性，但對安全供應商和安全工具的代碼卻網開一面，沒有任何安全警告，這感覺很奇怪。指南推薦的安全工具不需要任何安全檢測？這些工具對代碼開發部署中制造無數障礙的建議是否也適用于安全補丁？畢竟，補丁也是軟件更改。如果開發安全工具不適用補丁，那么這對攻擊者來說就是可以利用的巨大漏洞。

指南的另一個“驚喜”是防病毒軟件被列為能夠檢測DLL注入之類威脅的分類，最近的經驗數據表明，即使對于被認為遠遠領先于防病毒解決方案的EDR也做不到。同樣，指南給人的印象是熱衷于推銷安全供應商，而不是提供一套更完整的安全戰略建議。這些安全工具可能對底層系統造成的嚴重性能影響，例如生產環境主機上的內核恐慌，指南也沒有提及。

結論

如果你將《指南》奉為圭臬并將其實施到企業中，結果將會是災難性的，軟件供應鏈將徹底崩潰。您所在的企業會將您視為理論家、傻瓜或兩者兼而有之，您將把軟件工程活動限制到一定程度，以至于完全放棄交付軟件。公平地說，最安全的軟件是從未編寫過的軟件。但是，在一個與軟件交付密切相關的世界發展過程中，我們可以做得比指南建議的要好。