AI代码安全通过率仅56%，四成生成任务引入已知漏洞

AI编程助手已脱离实验阶段。在采用该技术的组织中，AI生成的代码约占提交总量的50%。开发者是否使用AI已非争议焦点，关键在于安全团队能否有效管控其产出内容。

数据显示，AI代码在语法正确性上表现优异，通过率高达99.9%，但安全性能堪忧。目前平均安全测试通过率仅为56%，意味着约44%的经测代码任务引入了已知漏洞。随着AI生成代码量增加而安全水平停滞，组织面临将更多脆弱代码引入开发环境的风险。软件漏洞现已成为占比31%的主要入侵途径，超过被盗凭证。

Veracode首席安全布道师Chris Wysopal指出，缩小这一差距需重构AI辅助开发流程中的安全策略。组织应从起步阶段便将安全纳入开发环节，选择具备风险意识的模型，并在代码投产前进行上下文验证。目标并非拖慢开发速度，而是确保安全运营与软件创建的规模和速度同步。

AI模型基于海量历史及公开代码训练，数据集中既包含安全实现，也混杂过时库、弱化验证逻辑及不安全编码模式。若缺乏适当控制，模型可能大规模复制这些不安全模式。

虽然组织无法控制所有训练数据源，但可决定哪些模型进入开发环节。测试显示，表现最强的模型安全通过率为68%，其余11个模型中有6个集中在50%至53%之间。因此，模型选择不仅是生产力决策，更是风险评估。

选择更强模型可降低暴露面，但输出结果并非默认可信。在软件开发生命周期中，仍需利用静态分析和可执行安全策略等功能对AI代码进行测试，使安全成为交付流程的一部分。

AI生成的代码可能编译成功并通过功能测试，但仍潜藏安全漏洞。在截止日期压力下，若开发人员未充分理解代码在整体应用中的行为便接受输出，易产生错误自信。

不同漏洞类型的安全性能差异凸显了上下文的重要性。模型在SQL注入方面的通过率为83%，不安全加密算法为87%，但在跨站脚本（XSS）方面降至15%，日志注入仅为12%。部分弱点可通过编码模式识别，其他则取决于数据流、授权、信任边界及应用交互方式。

因此，验证需在工作流和应用上下文中进行。原生AI分析可在静态分析基础上增加上下文风险检测，直接在拉取请求中揭示逻辑缺陷和身份验证失效等问题。关键是在代码合并及风险扩散前，将上下文分析与独立测试相结合。

AI在提升软件开发速度和体量的同时，也增加了安全团队需评估、排序和修复的风险量。这对已有大量未解决漏洞积压的组织而言，加剧了压力。

这种积压导致“安全债务”累积，即已知缺陷未被修复，风险在应用中停留时间更长。债务越多，降低难度和成本越高。如今，82%的组织受安全债务影响，其中60%面临严重安全债务。

数据显示，组织发现和生成风险的速度快于消除速度。将所有发现项视为同等紧急只会加剧问题。团队应专注于可利用性、应用关键性和业务影响，将有限资源引导至最可能造成实质危害的漏洞上。

AI驱动的修复建议有助于缩小发现与行动间的差距，减少重复性手动工作。但修复仍需治理：生成方案必须经过测试、验证并检查回归情况。目标应是减少实质暴露面，而非单纯增加系统中流转的发现项或修复项数量。

鉴于AI辅助代码已嵌入软件开发，领导者应将AI的安全影响视为软件运营模式的变更。

这意味着需明确AI代码在组织中的流入位置，根据安全要求评估模型，将验证构建到开发人员工作流中，并将修复重点放在可被利用的业务风险上。同时，保留关于测试、修复及已知接受风险的证据。

成功的企业不会是那些减缓AI采用的企业，而是演进开发实践以使安全跟上软件创建步伐的企业。AI让生成可用代码更易，真正的考验在于企业能否在代码投产前证明其安全性。