編譯 | 核子可樂、Tina
此次意見可謂美國政府在軟體安全方面表達的最強硬立場，訊息一齣很快引起軟體開發商關注：若不對編碼實踐做出修復，則意味著需要承擔過失風險。
美聯邦政府正在加強關於危險軟體開發實踐的警告，日前美國網路安全與基礎設施安全域性（CISA）和聯邦調查局（FBI）陸續釋出關於困擾關鍵基礎設施的基本安全問題的明確處置訊號。
CISA 和 FBI 在關於產品安全性不良實踐的最新報告中，提醒軟體開發商應高度關注使用非記憶體安全程式語言等不良行為，而 C 和 C++ 更是在其中被列為反面典型。
報告指出，“在支援關鍵基礎設施或國家關鍵職能（NCF）的新產品線的開發過程中，使用非記憶體安全語言（例如 C 或 C++）可能引發風險，即顯著提高了國家安全、國家經濟安全以及國家公共衛生及安全所面臨的風險。”
這份報告還將不良實踐具體分為三大類別：
-
產品屬性，即描述軟體產品中肉眼可見與安全相關的質量屬性。
-
安全功能，描述產品所支援的安全功能。
-
組織流程和政策，描述軟體開發商在確保安全方法的透明度等方面採取的實際行動。
這份報告主要面向負責為關鍵基礎設施或者國家關鍵職能等應用場景開發軟體產品及服務的各軟體開發商（包括本地軟體、雲服務以及 SaaS 軟體即服務）。
此外，這份報告還鼓勵全體軟體開發商避免採取這些可能影響產品安全性的不良實踐。報告提到，“透過遵循本指南中的建議，開發商將向客戶發出訊號，表明他們高度關注向客戶交付成果的安全因素、牢牢秉持在設計之初就重視安全的基本原則。”
Omdia 分析師 Brad Shimmin 表示，“這項指南是對美國政府此前關於軟體安全問題的早期宣告的延續，當時的宣告可以追溯到 2022 年，意在提醒技術提供商和企業使用者儘量使用或遷移至記憶體安全語言。”
他解釋稱，“拋開新增程式碼不談，當時的檔案和美國政府表達的立場相對比較和緩，沒有立即要求從 C/C++ 遷移至 Rust。CISA 的設計文件中也提到，軟體維護者根本不可能在短時間內完成如此規模的程式碼庫遷移。”
當時的指南雖然屬於自願性質，但也代表著 CISA 在基準安全實踐方面的最強立場，包括提醒企業注意到可能被疏忽的不良軟體開發實踐，特別是其中觸及基礎設施的部分。
但時間的洪流一刻不停向前奔湧，最新報告已經要求企業必須在 2026 年 1 月 1 日之前建立記憶體安全發展路線圖。
報告指出，“對於以非記憶體安全語言編寫的現有產品，到 2026 年 1 月 1 日前仍缺少明確記憶體安全遷移路線圖的情況，將被視為存在風險，即顯著提高了國家安全、國家經濟安全以及國家公共衛生及安全所面臨的風險。”
CISA 戰略合作伙伴關係及漏洞專案開發負責人 Rina Rakipi 表示，CISA 已獲得超過 230 家軟體廠商的自願承諾。加入“安全設計”計劃，意味著這些廠商承諾在一年內達成一系列網路安全目標，包括減少產品中的預設密碼、增加多因素身份驗證的使用，以及消除特定類別的漏洞。
Rakipi 說：“我們非常高興有超過 230 家軟體廠商自願參與這一承諾。展望未來，我們期待 在接下來的一年中，看到這 230 家公司取得的實質性進展。”
截圖來源：https://www.cisa.gov/securebydesign/pledge/secure-design-pledge-signers
此外，報告還要求企業在同一日期之前移除管理員賬戶中使用的全部預設密碼。這一截止日期已經將指南內容從建議升級為預期標準。
報告同時指出，記憶體安全路線圖應要搞開發商在主要程式碼元件（例如面向網路的程式碼或者處理加密操作等敏感功能的程式碼）當中將要採取的首選記憶體安全漏洞消除方法。
報告指出，“開發商應當證明，其記憶體安全路線圖將如何優先緩解其所開發產品中記憶體安全性的脆弱性，同時證明他們正做出合理努力以實施並推進其記憶體安全路線圖。”
Shimmin 在採訪中解釋稱，“但有兩個現實理由會迫使企業繼續維護由 COBOL 和 Fortran 編寫的成規模程式碼——成本和風險。首先，對數百萬行舊程式碼進行遷移在財務上不具備可行性，而且任何負責任的組織都無法承擔由此帶來的業務風險。”
此外，根據報告內容，關鍵基礎設施還面臨著以下“異常風險”的困擾：
-
預設密碼。
-
直接 SQL 注入漏洞。
-
缺少基本注入檢測機制。
-
缺少多因素身份驗證機制。
對於開源軟體，該報告稱應特別關注開源漏洞。其他建議還包括：
-
企業必須維護明確的軟體物料清單（SBOM）。
-
應當快取依賴項，而非直接從公共來源處提取。
-
需要以負責任方式為其依賴的開源專案做出貢獻。
報告提到，“軟體開發商應當以負責任的方式使用並持續為其所依賴的開源軟體做出貢獻。”
報告還敦促提高軟體開發透明度，包括：
-
企業必須釋出漏洞披露政策。
-
應當為所有關鍵漏洞釋出 CVE。
-
必須提供關於安全問題的清晰說明文件。
-
預計將安全日誌維護並儲存六個月。
最後，Shimmin 總結稱，CISA 建議掌握關鍵軟體的企業在 2026 年初之前制定出明確的安全計劃無疑是件好事。因為這能讓軟體行業有更多時間探索出理想的方法，確保我們的關鍵軟體資產免遭威脅侵擾。
“這些方法能夠包括在硬體製造層面消除潛在的攻擊面，以及由程式語言維護者提出方案。以 Safe C++ 提案為例，其呼籲為 C++ 建立一個超集以解決記憶體安全問題，藉此避免強制進行大規模程式碼重寫。”
這並不是 CISA 對記憶體安全語言的首次提倡。
在去年 9 月的一篇博文中，CISA 也曾公開敦促開發人員使用記憶體安全程式語言。網路與基礎設施安全域性、聯邦調查局（FBI）、國家安全域性及各盟國機構隨後於 12 月釋出了題為《記憶體安全路線圖案例》（The Case for Memory Safe Roadmaps）的研究報告，其中就點名 C/C++ 存在記憶體安全漏洞，軟體開發商應放棄使用，改用 C#、Rust、Go、Java、Python 和 Swift 等記憶體安全的程式語言 (MSL)。
今年 2 月底，白宮國家網路主任辦公室 (ONCD) 也就此釋出了一份報告，呼籲科技界主動減少網路空間的攻擊面；透過改用 Rust 等記憶體安全程式語言、避免使用 C++ 和 C 語言等易受攻擊的語言，以減少記憶體安全漏洞的數量來提高軟體安全性。
隨後，C++ 的建立者 Bjarne Stroustrup 針對白宮的這些言論進行了反駁。
Stroustrup 指出了 C++ 的優勢，並提到該語言最早於 1979 年設計。“令我感到驚訝的是，這些政府檔案的作者似乎忽略了現代 C++ 的優勢以及在提供強大安全保障方面所做的努力，” Stroustrup 表示，“但另一方面，他們似乎認識到程式語言只是工具鏈的一部分，因此改進工具和開發流程也至關重要。”
Stroustrup 強調，C++ 開發始終將安全性改進作為目標之一。“自第一天起，安全性改進就是 C++ 發展的目標之一，並貫穿了整個演進過程。只要將 K&R 時代的 C 語言與最早的 C++ 比較，再將早期的 C++ 與當代 C++ 比較就可以看出這一點，”他說。“許多高質量的 C++ 程式碼採用了基於 RAII（資源獲取即初始化）、容器和資源管理指標的技術，而不是傳統的 C-style pointer messes。”
其實在更早之前，Stroustrup 就明確表達過自己的看法，他曾在 CppCon2023 大會上主題演講上闡述了 C++ 的演變，還花了一些時間回應了批評。批評者說問題出在 C++ 本身，解決方案應該是改用另一種語言。Stroustrup 在演講中向與會者詳細說明了 C++ 語言在安全性方面所需的具體措施，並介紹了一項引入全新安全工具的提案，旨在為全球數十億行 C++ 程式碼提供更可靠的安全保障。
Stroustrup 反對透過更換語言來解決安全問題。他指出安全問題不僅僅是記憶體安全，還包括資源洩漏、溢位、併發和計時錯誤等多種複雜的隱患。
他強調，完全轉向其他語言不僅成本高昂，還缺乏關注跨語言互操作的需求——“實際上，我們在替換 C++ 時，可能需要用七種不同的語言來完成。而到 40 年後，可能會有 20 種語言需要彼此相容。這是巨大的挑戰。”
此外，Stroustrup 指出，許多所謂“安全”語言實際上將底層任務外包給 C 或 C++，以便訪問作業系統、硬體資源或其他歷史程式碼庫，這些程式碼往往隱藏在庫中，甚至使用完全不同的語言開發。
與 CISA 的“安全設計”計劃類似，Stroustrup 主張採用逐步改進的方案來提升 C++ 的安全性，而非推倒重來。他援引加爾定律，指出“有效的複雜系統總是從簡單系統演變而來”。
在他看來，“一邊倒地構建一個無舊系統問題的新系統是幻想，但這種幻想確實頗具吸引力。”
參考連結：
https://thenewstack.io/feds-critical-software-must-drop-c-c-by-2026-or-face-risk/
https://cyberscoop.com/cisa-secure-by-design-software-bad-practices/
https://www.infoq.cn/article/1wy3xq56dj6cmnwlgavi
https://www.infoworld.com/article/2336463/c-plus-plus-creator-rebuts-white-house-warning.html
