根据 GitLab 最新发布的一篇博文，AI 正快速改变软件漏洞的检测方式，但“谁来负责治理 AI 所暴露的风险”以及“如何应对这些风险”等问题已变得日益紧迫。GitLab 认为，尽管静态扫描器、生成式模型等 AI 工具在识别潜在安全问题并给出修复建议方面效率远高于传统工具，但仅靠检测无法解决风险管理的全部问题。这也促使开发者与安全团队重新思考在现代开发生命周期中应如何构建治理、问责与执行机制。
文章强调，随着 AI 驱动工具可发现漏洞并提出整改方案等相关成果公布，行业思路正在发生转变。尽管这些创新体现了 AI 在加速检测方面的价值，但 GitLab 的文章指出，发现漏洞本身并不等同于降低风险。企业安全负责人愈发关注漏洞是否真正依据业务风险完成分类、定级与修复，相关决策是否有明确的责任主体。如果团队缺少策略约束、场景化风险评分与治理机制来明确哪些问题必须在发布前修复、哪些可以接受或延后处理，那么单纯发现更多漏洞只会产生无效信息，形成干扰噪音。
为解决这一问题，GitLab 主张将 AI 驱动的检测嵌入到更广泛的、基于策略的 DevSecOps 框架中，推荐的最佳实践包括：在组织层面定义风险容忍阈值；设置与漏洞严重性、可利用性及合规要求相关的合并与部署门禁；在风险接受时保留可审计的审批流程；随着代码、依赖项与威胁情报的变化持续重新评估风险。文章强调，在从代码、流水线到生产环境的整个软件生命周期中保持统一可视性至关重要，从而将 AI 发现的问题与资产重要性、运行时暴露情况相结合。在此模式下，AI 成为安全开发的效能倍增器，而通过平台级管控、可审计性与可量化策略执行实现的治理仍是将检测结果转化为可问责、基于风险的决策的核心机制。
开发者与安全工程师不应将 AI 当作风险治理的替代品，而应将其视为加速器，并与严格的监督流程和清晰的问责机制相结合。行业趋势显示，这种平衡理念正得到越来越多的认同：近期围绕容器安全与威胁事件的讨论凸显了大规模场景下软件风险的复杂性——AI 驱动的扫描与自动化手段正与日趋复杂的供应链攻击、运行时漏洞并存。
整个行业内，众多组织已就 AI 风险治理原则形成共识，强调检测能力必须与结构化的监督和问责机制相结合。美国国家标准与技术研究院（NIST）凭借被广泛采用的AI风险管理框架（AI RMF），提出以治理、风险映射、度量与持续管理为核心的全生命周期管理思路。关键实践包括：明确问责角色、留存审计轨迹、针对公平性与安全标准验证模型，以及将 AI 风险纳入更全面的企业风险管理体系，而非将其视作孤立的技术问题。这些建议与 GitLab 的观点高度契合：只有将 AI 检测结果融入可落地的治理流程与部署管控中，其价值才能真正体现。
科技公司与行业框架也呼应了这种“治理优先”的思路。例如，微软已建立规范的负责任 AI 治理体系，包括内部审查委员会、高风险系统的定义与审批流程，以及对模型偏见或不安全输出的持续监控。同时，IBM强调透明度、可解释性与问责制是构建信任的基础。此外，ISO/IEC 42001等国际标准及欧盟 AI 法案相关的新兴监管规范都倡导持续审计、AI 使用过程可视化，以及与生产环境中的模型同步迭代的策略化管控。从这些实践中可以形成明确共识：有效的 AI 治理并非更依赖检测工具的复杂度，而是依托监控、人工审核、可量化的风险阈值，以及贯穿 AI 全生命周期的持续合规校验等运营实践。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
查看英文原文：https://www.infoq.com/news/2026/03/gitlab-ai-governance/
