"C/C++" 被視爲内存不安全的編程語言由來已久，很多開發者似乎也見怪不怪了，然而近日外媒 TheNewStack 最新發表了一篇《聯邦政府：關鍵軟件必須在 2026 年之前放棄 C/C++，否則将面臨風險》文章，讓人警鈴大作。
因爲過往包括美國網絡安全和基礎設施安全局（CISA）、聯邦調查局（FBI）、國防高級研究計劃局（DARPA）等多個機構雖然發起多個指南、甚至想盡辦法開發 AI 工具旨在一鍵将舊的 C 代碼轉爲 Rust，但終歸沒有采取過于強硬的手段或者是給 " 去 C、C++ 加上一個時間限制 "。如今外媒報道中赫然出現了一個「2026 年」的期限到底是怎麽一回事？倘若在軟件中繼續使用 C/C++ 語言最終又會帶來哪些影響？
CISA 和 FBI 最新發布《産品安全不良實踐》指南
進一步來看，這篇報道的來源依據的是美國 CISA、FBI 最近聯合發布的一份關于《産品安全不良實踐》的報告。
在報告中，CISA 表示，軟件制造商應确保從軟件開發之初就将安全性作爲核心考慮因素。基于此，CISA 和 FBI 希望能夠敦促軟件制造商通過在整個産品開發過程中優先考慮安全性來降低客戶風險。
不過，值得注意的是，雖然 CISA、FBI 想要盡可能地讓開發用于支持關鍵基礎設施或 NCF 的軟件産品和服務（包括本地軟件、雲服務和軟件即服務 ( SaaS ) ）的軟件制造商去避免産品安全不良做法，但是其在發布這份報告時說得也很明确——并未強硬地要求軟件開發商們必須按照這份報告的建議去做。
目前這份報告指南還正處于征求公衆意見期間，收集各方的反饋意見，以指導這些産品安全不良做法的制定。倘若開發者、企業對這份報告提出的做法有意見，可以在 2024 年 12 月 16 日提交反饋意見。
來源：https://www.federalregister.gov/documents/2024/10/29/2024-25078/request-for-comment-on-product-security-bad-practices-guidance
話雖如此，CISA、FBI 在這份主題爲《産品安全不良實踐》的報告中概述了被認爲極其危險的産品安全不良做法，特别是對于生産用于關鍵基礎設施或國家關鍵功能 ( NCF ) 的軟件的軟件制造商而言，并爲軟件制造商提供了減輕這些風險的建議，同時還是忍不住地多次強調了「2026 年」這個時間節點。
建議在 2026 年前軟件開發商發布内存安全路線圖
CISA、FBI 将不良實踐劃分爲三類：
産品特性：描述軟件産品可觀察的、與安全相關的質量。
安全特性：描述産品支持的安全功能。
組織流程和政策：描述軟件制造商爲确保其安全方法的高度透明度而采取的行動。
在産品特性維度上，美國兩大組織首先将 " 内存不安全語言的開發 " 列爲首要不良實踐的做法。
其指出，" 在有現成的内存安全語言可供使用的情況下，使用内存不安全的語言（如 C 或 C++）開發用于關鍵基礎設施或（國家關鍵功能）NCF 的新産品線是危險的，并且會大大增加對國家安全、國家經濟安全以及國家公共健康和安全的風險。"
此處，這份指南特别強調了——對于使用内存不安全語言編寫的現有産品，如果在 2026 年 1 月 1 日之前未發布内存安全路線圖，則非常危險，會大大增加國家安全、國家經濟安全和國家公共衛生與安全的風險。内存安全路線圖應概述制造商消除優先代碼組件（例如面向網絡的代碼或處理加密操作等敏感功能的代碼）中的内存安全漏洞的優先方法。制造商應證明内存安全路線圖将顯著、優先減少制造商産品中的内存安全漏洞，并證明他們正在做出合理的努力來遵循内存安全路線圖。這不适用于宣布支持終止日期在 2030 年 1 月 1 日之前的産品。
至于爲什麽是「2026 年之前」，CISA、FBI 并未做特别的解釋，僅是在「建議采取的措施」中又一次表示，當前的軟件制造商應以系統性的方式構建産品，以防止引入内存安全漏洞，例如使用内存安全語言或防止内存安全漏洞的硬件功能。此外，軟件制造商應在 2026 年 1 月 1 日之前發布内存安全路線圖。
其他建議
除此之外，CISA、FBI 還列舉了幾種常見的産品不安全的實踐，譬如：
在 SQL 查詢字符串中發現包含用戶提供的輸入。其建議産品應以系統性防止 SQL 注入漏洞引入的方式構建，例如通過始終強制使用參數化查詢；
在操作系統命令字符串中有包含用戶提供的輸入。其建議軟件制造商應以系統性防止命令注入漏洞的方式構建産品，例如通過始終确保命令輸入與命令本身的内容有明确的區分。
關鍵基礎設施或 NCF 使用的産品發布時帶有默認密碼。對此，其建議軟件制造商應确保産品中不存在默認密碼，例如爲産品提供随機的、實例唯一的初始密碼，要求安裝産品的用戶在安裝開始時創建一個強密碼等等。
存在已知被利用的漏洞。對此，軟件制造商應在發布前修補軟件組件中所有已知被利用的漏洞。對于 CISA 目錄中新發布的 KEV，制造商應及時免費向用戶提供補丁（任何情況下不超過 30 天），并明确警告用戶不安裝補丁的相關風險。
存在已知可利用漏洞的開源軟件。對此，軟件制造商應對他們依賴的開源軟件負責任地使用并可持續地貢獻。
在安全功能方面，CISA 和 FBI 還發現很多軟件開發商在開發中缺乏多因素身份驗證、缺乏收入入侵證據的能力，其指出，2026 年 1 月 1 日之後未默認爲管理員帳戶啓用 MFA 的産品非常危險，軟件制造商應在産品中原生支持 MFA（如果産品本身處理身份驗證），或在産品的基線版本中支持使用外部身份提供者，例如通過單點登錄、要求管理員使用 MFA。對于雲服務提供商和 SaaS 産品，軟件制造商應免費保留一定時間範圍内的日志（至少 6 個月）。
在組織流程和政策方面，軟件制造商應及時發布所有嚴重或高影響漏洞的完整 CVE，以及公開發布漏洞披露政策 ( VDP ) 等。
不放棄 C/C++，又會帶來什麽樣的影響？
「以 2026 年爲時間節點」來敦促軟件開發商們想盡辦法去改進，以此提升産品安全性，本意或許是好的，但是在僅有 14 個月的時間裏，爲産品規劃内存安全路線圖也不是一件小事。
此前，CISA 自己也發布過一份 23 頁的《内存安全路線圖指南》，其指出，在 MSL 中重寫現有代碼可能是一個巨大的挑戰，特别是如果代碼已經運行良好，而組織還不具備所選 MSL 的專業知識。
當時，該組織隻是給出較爲籠統的路線圖制定建議：
定義階段，包括日期和結果。與所有軟件開發工作一樣，開發團隊可以将較大的工作分解爲具有明确結果的較小項目，以度量最新進展。具體包括 MSL 評估、測試在 MSL 中編寫新組建的試點項目、找到最危險的内存不安全代碼、重構内存不安全代碼。
确定新系統完全使用 MSL 的時間。此後，公司将會僅在 MSL 中編寫新代碼。
内部開發者和培訓和整合計劃。沒有 MSL 過渡是免費的，制造商需要留出時間讓開發人員精通用所選語言編寫軟件、調試、工具、将 MSL 集成到生産環境中、全面的質量控制流程。
外部依賴計劃。路線圖應該記錄處理對用 C 和 C++ 編寫的庫的依賴關系的計劃。
透明度計劃。通過定期 ( 例如，每季度或每半年 ) 更新來保持上述信息的最新性，将進一步建立組織正在認真對待内存安全漏洞的信心。
CVE 支持計劃。行業需要詳細和正确地公開數據，以了解給客戶帶來風險的漏洞類别。
但是綜合成本與風險，很多企業無意遷移到内存更安全的編程語言上。
那麽不遷移到 MSL 語言又會帶來什麽樣的影響？
對此，業界的開發者們也展開了激烈的讨論，多數人認爲「這些建議終究隻是一個建議罷了，無傷大雅」：
目前它們隻是建議，這是 " 如果可以，請遵守我的規則 "，僅僅是對即将發生的事情的一個警告，但它不會在 2026 年成爲法律，我 100% 确定這一點。
作爲一名用 C++ 爲政府編寫軟件的人，讀到這些也真的很有趣。我們的項目直到 2020 年之後才被允許使用 C++11 功能，而且顯然很快就會被允許使用 C++14。而且必須是 C++，因爲我們需要支持平台和供應商。即使對于我們所有的新項目也是如此！
現在和可預見的未來，放棄 C 或 C++ 是完全不可能的。此外，我喜歡 Rust，它正在被采用，但讓它成爲新的黃金标準，未免操之過急。它仍然是一種新語言，在我們考慮真正用 Rust 重寫所有内容之前，它還有一些非常大的問題需要解決。
不過也有人一些開發者聲稱自己以及公司已經受到了一些影響：
我們公司所開發的軟件類别在政府認證時，已經被禁止在任何新開發中使用非内存安全的語言，并且我們必須提供源代碼以供檢查。
當有網友究竟問及是哪一類的軟件時，該開發者回應道，「它是一類必須實現 Linux 中存在的幾乎所有安全層的軟件。」
而就國外現在呼籲放棄 C/C++ 這種内存不安全語言的做法，國内知名 C++ 專家吳詠炜此前在接受 CSDN 采訪時表示：
這一事件的起源重點是關注網絡安全，内存安全的編程語言是其中的一小部分内容。
确實建議大家避免使用内存不安全的語言。但問題是，如果不是對效率有極緻追求的場景，大家本來就不會選用 C 和 C++（如在企業應用裏，本來 Java 就是主流）。而用到 C 和 C++ 的，基本都是确有需要。此前報告裏也提過，空間系統裏仍然使用 C 和 C++，并描述了如何使用其他技術手段來規避不安全語言可能帶來的問題。
吳詠炜認爲，對于 C 和 C++ 的安全性，也有必要做幾點陳述：
C 和 C++ 不是一回事。在現代 C++ 代碼裏，因爲有很多好的語言構件（如容器和智能指針）可以用，犯内存錯誤的可能性要比 C 低得多。C 的固定大小數組是很多安全問題的根源。
已經存在很多工具，可以幫助檢查代碼的安全性，如 clang-tidy、cppsafe 和 address sanitizer（ASan）。
C++ 本身也在發展，像 lifetime profile（生存期規格配置）等方面的工作就是爲了能提前檢查出安全問題。
内存安全是代碼安全的一部分，不是全部。
代碼安全問題是個系統工程，不是靠某種銀彈就能立即解決的。培訓、語言、工具等等都是解決方案的一部分。
那麽，針對内存安全編程語言的争論，你有什麽樣的看法？在 Linux、Google、微軟等組織紛紛開始擁抱 Rust 的情況下，你開發的項目是否有受到這波趨勢的影響？歡迎留言分享你的看法。
參考：
https://www.cisa.gov/resources-tools/resources/product-security-bad-practices
https://thenewstack.io/feds-critical-software-must-drop-c-c-by-2026-or-face-risk/
https://www.reddit.com/r/rust/comments/1ggt7m2/feds_critical_software_must_drop_cc_by_2026_or/
