今天小編分享的科技經驗：美政府再發警告：關鍵軟體勿用C/C++，2026年前給遷移方案，否則非常危險！，歡迎閲讀。
"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/
