在持续交付环境中，安全扫描很容易陷入两个极端：一端是只跑静态规则，输出大量告警，开发者只能靠经验逐条判断；另一端是把代码、日志和扫描结果直接交给模型，期望它给出“是否存在漏洞”的结论。前者缺少业务上下文，后者则可能把不完整的上下文当作完整事实。
更可操作的目标不是让工具替代安全决策，而是让每一次结论都能回答三个问题：攻击者的起点是什么？中间需要跨越哪些可验证条件？最终影响能否在当前变更和部署边界内成立？这就是攻击路径验证与普通漏洞扫描的区别。扫描负责发现候选风险，路径验证负责筛除不成立的假设、补足证据，并把高风险变更送入人工审批。
本文给出一条适用于合并请求的最小流水线：规则扫描生成候选项，脚本汇总变更上下文，模型仅输出结构化分析，最后由策略引擎和人工共同决定是否放行。示例以 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/checkout@v4with:fetch-depth:0-name:Run deterministic scanrun:./scripts/security-scan--format json--output findings.json-name:Build review packetrun:|git diff --unified=20 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均由部署配置决定。若团队选择通过 HaerAPI（https://www.haerapi.com）或其他服务接入模型，应先以其当前文档确认认证方式、请求格式、地域与数据处理边界。
# scripts/analyze_paths.pyimportjsonimportosimportsysfromurllibimportrequest packet_path,output_path=sys.argv[1],sys.argv[2]base=os.environ["LLM_API_BASE"].rstrip("/")api_key=os.environ["LLM_API_KEY"]model=os.environ["LLM_MODEL"]withopen(packet_path,encoding="utf-8")asf:packet=json.load(f)instruction="""你是安全审查辅助工具。只能依据提供的证据分析。 不要声称已运行代码、访问系统或确认未提供的控制措施。 对每个候选项给出入口、传播、危险操作、防护条件、缺失证据和建议动作。 结果必须是 JSON 对象，顶层字段为 findings。"""body={"model":model,"messages":[{"role":"system","content":instruction},{"role":"user","content":json.dumps(packet,ensure_ascii=False)}],"temperature":0}req=request.Request(f"{base}/chat/completions",data=json.dumps(body).encode("utf-8"),headers={"Authorization":f"Bearer{api_key}","Content-Type":"application/json"},method="POST",)withrequest.urlopen(req,timeout=30)asresponse:payload=json.load(response)content=payload["choices"][0]["message"]["content"]result=json.loads(content)ifnotisinstance(result.get("findings"),list):raiseValueError("model result lacks findings array")withopen(output_path,"w",encoding="utf-8")asf:json.dump(result,f,ensure_ascii=False,indent=2)脚本将密钥完全留在环境变量中。还应在日志中避免打印请求头、完整 diff 和模型原始响应；异常信息应做截断与脱敏。对于支持结构化输出的接口，可在确认当前接口文档后启用相应参数，但不要假设所有兼容接口都有相同行为。
4. 将高风险结论转为确定性门禁
策略脚本不应信任自由文本，而应只读取枚举字段。示例规则是：任何block都失败；require_human_review则以非零退出码等待人工处理。
# scripts/enforce_policy.pyimportjsonimportsyswithopen(sys.argv[1],encoding="utf-8")asf:findings=json.load(f).get("findings",[])actions={item.get("action")foriteminfindings}if"block"inactions:raiseSystemExit("security policy: blocking finding exists")if"require_human_review"inactions:raiseSystemExit("security policy: human review required")生产团队通常还需要把rule_id、提交 SHA、分析输入摘要、模型配置标识、结果和人工处置记录写入审计存储。保留摘要而非无差别保留源码，有助于在可追溯性与数据最小化之间取得平衡，具体保留期限仍应按组织制度执行。
常见问题
模型说“不可利用”，能否自动放行？
不能仅据此放行。该结论至多说明给定证据未形成完整路径。涉及高价值资产的规则命中应由确定性策略和人工审批共同决定，特别是身份认证、租户隔离、命令执行、反序列化和数据导出场景。
为什么不能把全部代码喂给模型？
完整代码不一定提高结论质量，却会扩大数据暴露范围、增加成本，也可能让关键证据被长上下文淹没。优先传递命中附近代码、调用链摘要、变更 diff 和已知控制措施；当证据不足时，要求模型明确列出需要补查的文件或配置。
提示注入会影响安全审查吗？
会。代码注释、测试数据、提交信息甚至扫描结果中的字符串都可能包含试图改变模型指令的文本。应把这些内容视为不可信数据，与系统指令分离；模型输出必须经过 JSON 解析和策略校验，不能直接作为 shell 命令、SQL 或审批动作执行。
扫描器与模型结论冲突时怎么办？
以可复核证据为准，而不是以工具权威性为准。保留扫描规则、源代码位置、调用关系和防护配置。若模型认为路径不成立，应检查它引用的证据是否真实；若扫描器漏报，则将复现条件转化为测试、规则或人工检查项。
总结
将安全审查接入 CI 的关键，不是增加一个“智能判定器”，而是建立一条可追溯的证据链：确定性工具发现候选风险，受控上下文支撑路径分析，结构化输出进入策略门禁，高影响决策仍由有权限的人完成。这样做既能减少低价值告警对研发节奏的干扰，也能避免把模型的概率性输出误当作安全事实。
从一个高频风险类别开始，例如外部输入到命令执行或敏感数据导出，先定义输出契约、审计字段和人工升级规则；在积累真实处置记录后，再逐步扩展规则覆盖面与上下文采集范围。