AI驅動時代，安全跨越鴻溝的困境和機遇
責編：gltian ｜2025-05-20 15:00:52如今，顯而易見，人工智能正在從根本上改變軟件開發的格局和未來。在過去幾年里，生成式人工智能（GenAI）和大型語言模型（LLMs）已徹底顛覆了軟件開發生態系統。
從英偉達（NVIDIA）首席執行官黃仁勛調侃“孩子們不應該學習編程”，到谷歌等行業領導者宣稱其 25%的代碼如今由人工智能編寫，風險投資公司YCombinator表示其最新一批員工的代碼庫中有 25%由人工智能完成度高達 95%，再到 Anthropic 首席執行官聲稱 6 個月內 90%的代碼將由人工智能生成。谷歌 2024 年的 DORA 報告還發現，75%的開發人員現已依賴人工智能編碼助手。
即便拋開我近期在《Vibe Coding 的難題》一文中提到的“Vibe Coding”等趨勢不談，人工智能顯然正在重塑現代軟件開發的方式，涉及勞動力、工具、產出等諸多方面。
盡管如此，這也帶來了固有的安全問題，我們將在后文展開討論。
此外，安全領域有機會成為先進技術的早期采用者，而非落伍者，并且不再繼續糾結是“事后附加安全”還是“內置安全”的問題。
速度、數量和漏洞
我們已經探討過編碼助手和人工智能驅動的開發工具是如何被迅速廣泛采用的。除了廣泛應用之外，這些工具還推動了“生產力”的大幅提升。盡管具體數據有所不同，但就交付速度和代碼輸出而言，估計提升幅度通常在 35%至 50%之間。
從表面上看，這對主要關注收入和上市速度等激勵因素而非安全性的企業和開發人員來說是一件好事。然而，這種速度和數量的提升會對另一個方面產生影響，即漏洞。
讓我們來看看現有的漏洞狀況。撇開通用漏洞與暴露（CVE）和 NIST 國家漏洞數據庫（NVD）的崩潰情況不談，多年來，安全領域一直在努力跟上軟件開發的步伐。
就在 2024 年 3 月，從 2024 年到 2025 年，CVE 的年增長率達到了 +48.37%，且絲毫沒有放緩的跡象。
Source: Jerry Gamblin
這是由多種因素造成的，例如漏洞發現和披露工作的改進與增加、漏洞管理生態系統的成熟，但也與基本的數學原理有關。從歷史上看，更多的應用程序、軟件和代碼行意味著更多的漏洞，即更大的攻擊面。
這在許多企業環境中表現為成千上萬的大量漏洞積壓，安全工作無法跟上不斷增長的攻擊面、日益加快的軟件開發速度，以及業務方面相互競爭的優先事項，如功能發布、客戶滿意度、上市速度和收入。
安全部門嘗試過各種方法，如“左移”策略和“DevSecOps”理念，但這在很大程度上是將一系列縮略語式的安全工具（如SAST、DAST、IaC、容器掃描等）生硬地納入持續集成/持續交付（CI/CD）管道。這些工具大多保真度低、存在數據質量問題，并且幾乎沒有與應用或組織相關的背景信息，從而加劇了安全與開發之間的隔閡。而具有諷刺意味的是，“DevSecOps”理念本應改善這種隔閡。
你不需要是天才也能想到，當我們考慮到 Copilots、編碼助手以及通用人工智能驅動開發的廣泛采用時，這個問題的可能影響及其未來的惡化趨勢。
你可能會問，編碼助手和人工智能工具難道不會生成更安全的代碼嗎？
嗯，不完全是，至少目前還不是。
整個行業的各種研究人員和相關方都在研究這個問題，目前情況不容樂觀。一項資料顯示，人工智能生成的解決方案中有 62%存在錯誤和/或包含安全漏洞。另一項研究發現，29.6%的人工智能生成代碼片段存在安全弱點。
Source: BaxBench
盡管有這些研究和發現，但調查顯示，開發人員高估了人工智能生成代碼的安全性，往往從本質上信任其輸出，而不從安全角度進一步驗證或核實。還有研究稱，人工智能編碼工具的廣泛應用可能會導致技能衰退，從批判性思維到軟件開發細微差別方面的專業知識都會受到影響。
此外，還存在一個“人工智能反饋回路”，這是一個具有挑戰性的二分法。隨著人工智能創建更現代化的代碼庫，這些最初由人工智能生成的代碼片段和代碼隨后會被用于未來的人工智能模型訓練。這就造成了一種反饋性影響，即人工智能模型訓練使用了潛在的不安全和脆弱代碼，從而擴大了未來的安全影響。
誠然，這個問題并非人工智能生成代碼所獨有。事實上，現代編碼助手所使用的大多數基礎人工智能模型都不是憑空創造的有機代碼，而是在龐大的開源軟件生態系統中訓練出來的。
正如我在一篇題為《2025 年開源安全格局》的文章中所寫的那樣，開源技術的采用已經呈現出指數級的逐年增長態勢，97%的代碼庫都包含開源技術，平均每個應用程序中的開源文件數量在過去四年里增加了兩倍。這些開源代碼同時存在漏洞和可持續性問題。
如上所述，開源代碼中的漏洞非常普遍。絕大多數開源組件已經過時數年，在許多情況下，已經多年沒有新的開發，這表明這些漏洞不可能在短期內得到修復。
這并不是說開源技術天生就比專有代碼糟糕或不安全。事實上，如上所述，大多數商業代碼都源于開源技術。
同樣的情況也適用于領先的前沿人工智能模型和它們所訓練的代碼，這些代碼現在可以幫助開發人員創建并發布到現代軟件生態系統中。
治理 – 模型、代碼和集成
人工智能驅動的開發挑戰的一個基本方面是治理工作，這涵蓋模型、代碼和集成三個關鍵領域。在模型方面，BaxBench等研究表明，并非所有的人工智能模型及其編碼能力（包括生成安全代碼的能力）都處于同一水平。企業需要對軟件開發活動中使用的 Copilots、編碼助手和模型進行管理。
在代碼方面，這需要根據深入的上下文（遠不止已知的漏洞），就應用程序、產品和系統中應包含哪些代碼做出基于風險的決策。這包括已知利用情況、利用概率、可及性、業務背景等因素。傳統的漏洞管理方法會給開發團隊帶來低情境、低質量的安全掃描結果，拖慢開發速度，起到類似商業稅收的作用，而非促進作用。開發人員深知這一點，這也正是他們積極主動地規避安全流程，而非積極配合安全工作的原因。
在集成方面，隨著模型上下文協議（MCP）和代理 2 代理協議（Agent2Agent Protocol）等的興起，我們看到了支持協議和方法論的爆炸式增長與令人興奮的發展態勢。這些協議和方法論不僅支持人工智能驅動的開發，還支持整個代理架構。
我們將繼續看到人工智能驅動的開發以及快速開發的應用程序和軟件的整個代理架構和工作流程得到廣泛應用。這些架構和流程在代理之間進行內部協調，并與數據源、工具和服務進行外部交互。
安全領域跨越鴻溝的機遇
安全問題歷來是企業的一個摩擦點，被開發人員稱為“讓人靈魂發白的苦差事”。它常常被視為“不可能的辦公室”，通常被企業視為必要的“惡魔”。
這是由于我在上文討論的諸多問題，再加上安全領域繼續使用傳統方法、基于紙張的合規流程、無法向企業闡明自身價值，以及固有的風險規避文化所導致的。
經典的技術營銷和銷售書籍《跨越鴻溝》概述了技術采用的生命周期，包括創新者、早期采用者、早期多數人、后期多數人和落后者。
安全領域幾乎總是處于落后狀態。
當企業正在快速采用云技術、移動技術、軟件即服務（SaaS）、人工智能以及接下來出現的任何新技術時，安全問題卻始終袖手旁觀，對假想的和現實的風險應對不力，強調過度謹慎，最終不可避免地被拋在后面。
這就是為什么我們會聽到“安全需要內置，而不是附加”這樣的說法。雖然每個從事安全工作的人聽到這句話都會點頭認同，但我們的行為、與開發和工程同行的互動，以及我們如何在企業內部和整個企業中實施“安全”措施，卻反映出不同的情況。
我們因處于落后狀態而延續了過去的問題。
然而，擺在我們面前的是一個真正的抉擇和機遇。我們是繼續延續過去的問題，還是通過在技術應用生命周期中提前布局，成為早期采用者甚至創新者呢？
我們已經知道，開發人員和企業正在迅速采用人工智能和人工智能驅動的開發。最近的一份報告顯示，企業對人工智能代理的采用也在迅速增長，其中包括一個顯著的激增態勢。僅在一個季度內，試點比例就從 37%增長到 65%，幾乎翻了一番。
我曾在一篇標題相同的文章中討論過人工智能與網絡安全的交集。初創企業、創新者和投資者正在探索代理人工智能在治理、風險與合規（GRC）、安全運營（SecOps）和應用安全（AppSec）等領域的潛力，本文主要關注這些領域。
代理人工智能為安全領域提供了應對系統性挑戰的機遇，例如漏洞管理、勞動力限制以及長期存在的摩擦和挫折。
這包括識別錯誤配置和漏洞，并通過主動識別、建議和及時補救等措施，積極維護源代碼和運行時的應用程序安全。
多個 AI 代理可用于在數千個拉取請求中擴展安全代碼審查等活動，帶來豐富的代碼上下文和深刻的安全見解，并減少因開發人員在組織中人數相對較少而困擾安全工作的人工審查和工作量。
就像人工智能提高了開發人員的生產力一樣，它也可以成為安全領域的倍增器，將安全任務和活動擴展到人類勞動力難以企及的水平。
MCP 等協議的興起允許與人工智能編碼助手集成，直接嵌入到本地開發人員的工作流程中，在提交之前捕捉缺陷和漏洞，并在安全/保密庫、升級和補救等方面為開發人員提供上下文代碼審查和建議。
需要強調的是，在所有行業熱潮中，關于 MCP 和代理人工智能，一個關鍵點是 MCP 和這些工作流程的可擴展性與所集成的數據、工具和服務的質量息息相關。
如果你集成了傳統的、保真度差的、低質量的工具和服務，那么你只是在復制我上文討論過的問題。盡管如此，CI/CD 工作流程中的低質量安全工具和發現還沒有整合到集成開發環境中，這開發人員感受到的挫折和痛苦比以前更嚴重，而不是改善組織的安全成果。
其中一個例子來自 AppSec 領導者 Endor Labs，我在該公司擔任首席安全顧問。正如您在下面的演示中看到的，通過 Endor Labs 的 MCP Server 功能，您將看到VSCode和 Copilot 的演示。用戶可以用自然語言詢問有關代碼漏洞的問題，甚至可以指示修復代碼依賴關系中的漏洞，所有這一切都不會干擾開發人員的工作流程。
這包括使用領先的集成開發環境進行上下文代碼審查、準確且有優先級的補救結果、更安全的庫建議以及針對潛在破壞性更改的上下文升級。
這顯示了通過 MCP 和大型語言模型（LLMs）與開發人員工具和工作流程集成的能力，從而改善組織的安全成果。
結束語
正如我在文章中所討論的那樣，人工智能驅動的開發正在徹底改變現代軟件開發的方式。現在，安全性正處于一個關鍵的十字路口。我們可以延續過去的問題，保持落后狀態；也可以跨越鴻溝，將自己定位為這一新興技術的早期采用者和創新者。
我們知道我們的業務、開發和工程同行以及惡意行為者在做什么。
從這一點出發，我們的所作所為將決定安全問題是事后才想到的附加問題，還是設計中的內置問題。
我們真的希望我們的行業留下落后者的名聲嗎？
原文鏈接：
https://www.resilientcyber.io/p/securitys-ai-driven-dilemma