在持续交付环境中安全扫描很容易陷入两个极端一端是只跑静态规则输出大量告警开发者只能靠经验逐条判断另一端是把代码、日志和扫描结果直接交给模型期望它给出“是否存在漏洞”的结论。前者缺少业务上下文后者则可能把不完整的上下文当作完整事实。更可操作的目标不是让工具替代安全决策而是让每一次结论都能回答三个问题攻击者的起点是什么中间需要跨越哪些可验证条件最终影响能否在当前变更和部署边界内成立这就是攻击路径验证与普通漏洞扫描的区别。扫描负责发现候选风险路径验证负责筛除不成立的假设、补足证据并把高风险变更送入人工审批。本文给出一条适用于合并请求的最小流水线规则扫描生成候选项脚本汇总变更上下文模型仅输出结构化分析最后由策略引擎和人工共同决定是否放行。示例以 GitHub Actions 为载体但各步骤也可迁移到其他 CI 系统。原理把“漏洞判断”拆成证据链一次可审计的攻击路径至少应包含以下节点入口攻击者可以控制的数据例如 HTTP 参数、消息队列载荷、上传文件或第三方回调。传播数据如何经过解析、拼接、反序列化、模板渲染或权限转换。危险操作例如执行命令、构造 SQL、发起服务端请求、读取敏感文件或修改权限。防护条件鉴权、白名单、参数化接口、输出编码、网络隔离、运行账户权限等实际存在的控制。影响与前提成功利用后的资源影响以及攻击所需的身份、网络位置、配置状态。只有“入口到危险操作”的可达性与“防护条件不足”同时有证据才应提高风险等级。例如扫描器发现字符串拼接不必然意味着 SQL 注入还要确认该字符串是否来自不可信输入、是否经过允许列表约束、是否最终进入数据库执行接口。反过来单纯依赖模型的自然语言判断也不可靠因为模型看不到未提供的路由、鉴权中间件和部署网络策略。因此模型在流水线中的职责应限定为根据输入证据提出假设、指出缺失证据、生成复查清单。它不应拥有合并权限不应直接执行探测命令更不应被允许读取完整生产数据。流水线设计建议将流程分为四层。第一层确定性扫描。使用现有 SAST、依赖漏洞扫描、密钥泄露扫描等工具生成机器可读结果。规则命中是候选项不是最终定级。第二层最小上下文归集。仅提取本次变更的 diff、命中的文件片段、相关调用点、依赖版本与仓库中明确标注的安全控制。不要把整个仓库、部署密钥、生产日志或客户数据默认发送到外部服务。第三层受约束分析。要求模型返回固定 JSON路径节点、证据位置、待验证前提、置信度说明和建议动作。输出格式受约束后脚本可校验字段也更方便审计。第四层策略与人工关卡。例如涉及认证、授权、支付、执行命令或敏感数据导出的变更即使自动分析认为风险较低也要求指定人员复核。自动化适合排序和归纳不适合绕过职责分离。可执行步骤1. 定义机器可读的分析契约先确定模型输出而不是先设计提示词。以下 JSON Schema 足以支撑最小流程{type:object,required:[findings],properties:{findings:{type:array,items:{type:object,required:[rule_id,verdict,evidence,missing_evidence,action],properties:{rule_id:{type:string},verdict:{enum:[likely_exploitable,needs_review,unlikely_from_evidence]},evidence:{type:array,items:{type:string}},missing_evidence:{type:array,items:{type:string}},action:{enum:[block,require_human_review,record_only]}}}}}}其中unlikely_from_evidence的含义是“现有材料不足以支持攻击路径”不是“系统绝对安全”。这个措辞能避免把缺失上下文误写成否定结论。2. 在 CI 中收集受控输入下面的工作流示例只展示编排方式。security-scan应替换为团队实际采用且已验证的扫描命令扫描结果应采用 JSON 文件而不是依赖控制台文本解析。name:security-reviewon:pull_request:branches:[main]permissions:contents:readpull-requests:readjobs:review:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4with:fetch-depth:0-name:Run deterministic scanrun:./scripts/security-scan--format json--output findings.json-name:Build review packetrun:|git diff --unified20 origin/${{ github.base_ref }}...HEAD change.diff python scripts/build_review_packet.py findings.json change.diff review-packet.json-name:Analyze candidate pathsenv:LLM_API_BASE:${{secrets.LLM_API_BASE}}LLM_API_KEY:${{secrets.LLM_API_KEY}}LLM_MODEL:${{vars.LLM_MODEL}}run:python scripts/analyze_paths.py review-packet.json review-result.json-name:Enforce review policyrun:python scripts/enforce_policy.py review-result.json不要在来自 fork 的不可信拉取请求中直接注入可访问外部模型的密钥。GitHub Actions 的事件权限和密钥可用性应按仓库设置核对对于不可信代码较稳妥的做法是仅执行不带密钥的扫描或把分析任务移交到受控环境。3. 用环境变量调用兼容接口以下脚本不假定任何特定供应商的端点或模型名称LLM_API_BASE、LLM_MODEL均由部署配置决定。若团队选择通过 HaerAPIhttps://www.haerapi.com或其他服务接入模型应先以其当前文档确认认证方式、请求格式、地域与数据处理边界。# scripts/analyze_paths.pyimportjsonimportosimportsysfromurllibimportrequest packet_path,output_pathsys.argv[1],sys.argv[2]baseos.environ[LLM_API_BASE].rstrip(/)api_keyos.environ[LLM_API_KEY]modelos.environ[LLM_MODEL]withopen(packet_path,encodingutf-8)asf:packetjson.load(f)instruction你是安全审查辅助工具。只能依据提供的证据分析。 不要声称已运行代码、访问系统或确认未提供的控制措施。 对每个候选项给出入口、传播、危险操作、防护条件、缺失证据和建议动作。 结果必须是 JSON 对象顶层字段为 findings。body{model:model,messages:[{role:system,content:instruction},{role:user,content:json.dumps(packet,ensure_asciiFalse)}],temperature:0}reqrequest.Request(f{base}/chat/completions,datajson.dumps(body).encode(utf-8),headers{Authorization:fBearer{api_key},Content-Type:application/json},methodPOST,)withrequest.urlopen(req,timeout30)asresponse:payloadjson.load(response)contentpayload[choices][0][message][content]resultjson.loads(content)ifnotisinstance(result.get(findings),list):raiseValueError(model result lacks findings array)withopen(output_path,w,encodingutf-8)asf:json.dump(result,f,ensure_asciiFalse,indent2)脚本将密钥完全留在环境变量中。还应在日志中避免打印请求头、完整 diff 和模型原始响应异常信息应做截断与脱敏。对于支持结构化输出的接口可在确认当前接口文档后启用相应参数但不要假设所有兼容接口都有相同行为。4. 将高风险结论转为确定性门禁策略脚本不应信任自由文本而应只读取枚举字段。示例规则是任何block都失败require_human_review则以非零退出码等待人工处理。# scripts/enforce_policy.pyimportjsonimportsyswithopen(sys.argv[1],encodingutf-8)asf:findingsjson.load(f).get(findings,[])actions{item.get(action)foriteminfindings}ifblockinactions:raiseSystemExit(security policy: blocking finding exists)ifrequire_human_reviewinactions:raiseSystemExit(security policy: human review required)生产团队通常还需要把rule_id、提交 SHA、分析输入摘要、模型配置标识、结果和人工处置记录写入审计存储。保留摘要而非无差别保留源码有助于在可追溯性与数据最小化之间取得平衡具体保留期限仍应按组织制度执行。常见问题模型说“不可利用”能否自动放行不能仅据此放行。该结论至多说明给定证据未形成完整路径。涉及高价值资产的规则命中应由确定性策略和人工审批共同决定特别是身份认证、租户隔离、命令执行、反序列化和数据导出场景。为什么不能把全部代码喂给模型完整代码不一定提高结论质量却会扩大数据暴露范围、增加成本也可能让关键证据被长上下文淹没。优先传递命中附近代码、调用链摘要、变更 diff 和已知控制措施当证据不足时要求模型明确列出需要补查的文件或配置。提示注入会影响安全审查吗会。代码注释、测试数据、提交信息甚至扫描结果中的字符串都可能包含试图改变模型指令的文本。应把这些内容视为不可信数据与系统指令分离模型输出必须经过 JSON 解析和策略校验不能直接作为 shell 命令、SQL 或审批动作执行。扫描器与模型结论冲突时怎么办以可复核证据为准而不是以工具权威性为准。保留扫描规则、源代码位置、调用关系和防护配置。若模型认为路径不成立应检查它引用的证据是否真实若扫描器漏报则将复现条件转化为测试、规则或人工检查项。总结将安全审查接入 CI 的关键不是增加一个“智能判定器”而是建立一条可追溯的证据链确定性工具发现候选风险受控上下文支撑路径分析结构化输出进入策略门禁高影响决策仍由有权限的人完成。这样做既能减少低价值告警对研发节奏的干扰也能避免把模型的概率性输出误当作安全事实。从一个高频风险类别开始例如外部输入到命令执行或敏感数据导出先定义输出契约、审计字段和人工升级规则在积累真实处置记录后再逐步扩展规则覆盖面与上下文采集范围。