全量扫描跑一次要几小时，CI 流水线被卡住；只做增量扫描，又担心历史遗留漏洞没人处理——这是很多研发团队部署代码安全扫描工具后的常见困境。

增量扫描和全量扫描不是替代关系，而是按项目阶段、发布频率、风险等级组合使用的两种互补手段。核心原则是：增量管日常反馈，全量管基线与合规；两者配合配置，才能既快又不漏。

一、增量扫描与全量扫描：本质差异

代码安全扫描在实践中至少包含两类对象，策略不宜混为一谈：

源码静态扫描（SAST）：针对源代码与配置；

依赖与制品扫描：针对 lockfile、SBOM、容器镜像层等。

「增量」与「全量」在上述两类上的触发逻辑相似，但对比基线不同：SAST 增量通常基于 Git 变更集；依赖扫描增量常基于锁文件或镜像 digest 是否变化。

增量扫描：扫什么、何时触发

增量扫描只对本次变更涉及的检测面执行规则，常见实现包括：

• 基于Git diff / Merge Request分析变更文件与受影响模块；
• 基于对比基线（如对main分支的 merge base，或「新代码周期」内提交）限定检测范围；
• 依赖侧在lockfile、镜像层变更时触发，而非每次重复扫全量依赖树。

特点：耗时短（通常秒级到分钟级），适合嵌入每次代码推送、PR/MR 创建与 CI 流水线门禁。

开源侧常见方案包括 Bandit（Python）、Semgrep（多语言规则）等；SonarQube 的增量/新代码分析需配置质量门禁与基线分支。

全量扫描：扫什么、何时兜底

全量扫描对仓库当前全部源码、完整依赖清单（及已启用的镜像/制品层）执行完整规则集，用于建立或刷新安全基线，覆盖增量模式无法触达的存量问题。

注意：全量扫描指的是当前代码树与依赖快照，并非重扫全部 Git 历史提交。执行耗时与仓库规模、规则集、并行度相关，大型项目可达数十分钟至数小时。

典型触发时机：首次接入扫描工具、重大版本发布前、季度/等保类安全审计。依赖与镜像场景下，Trivy 等工具常用于全量检测；也可通过定时任务在周末夜间等低峰窗口执行，避开工作日 CI 高峰。

核心区别对照

本质是检测效率与覆盖完整性的权衡：日常迭代要增量的响应速度，安全治理要全量的覆盖广度。

二、为什么只选一种不够

只做增量：历史代码中的存量漏洞可能长期不被发现；传递依赖的间接风险若未纳入 lockfile 变更检测，也可能漏报；等保、ISO 27001 等合规审计通常需要定期完整扫描记录，仅增量难以单独满足。

只做全量：大型仓库每次全量耗时过长，绑定在每次发布上会明显拖慢交付；结果中混杂大量历史问题，与本次变更无关，易引发扫描疲劳，高危项反而被淹没。

业界 DevSecOps 的通行做法是「全量定期 + 增量实时」双轨：全量保安全基线，增量保研发效率。早阶段发现问题，修复与回归成本通常低于生产环境事后补救——落地时以左移门禁为目标即可。

三、按项目阶段匹配扫描策略

1. 新项目接入期：先全量，建立基线

团队首次引入代码安全扫描时，应先执行一次全量扫描，导出问题清单并按严重级别分类。处理策略建议：

高危：接入前或首个迭代内必须修复或明确豁免理由；

中低危：纳入 backlog，标注发现版本与责任人；

基线快照：保存报告编号与扫描时间，作为后续增量的对照。

基线确定后，增量结果可区分为「本次引入」与「存量遗留」，避免反复争论「是不是你这次改坏的」。

2. 日常迭代期：以增量为默认门禁

在代码推送、PR/MR 创建、CI 流水线中配置增量扫描作为质量门禁：

• 仅对本次变更范围阻断合并（按团队策略：高危零容忍，或中危以上阻断）；
• 扫描结果自动关联提交/MR，要求修复或关联缺陷单后再合并；
• 若已使用缺陷/测试管理系统，可将扫描问题同步至 Bug 流程，避免在 IM 里反复口头确认。

3. 发版与审计节点：全量兜底

在版本发布前、重大功能上线、季度安全审计、等保评测前，执行全量扫描兜底，确认存量问题无遗漏、无异常反弹。

4. 扫描频率参考（需按仓库规模调整）

下表为经验区间，非硬性标准；monorepo、规则集过大或小时级全量时，应拉长全量周期或分模块扫描。

具体频率需结合代码规模、合规等级、扫描耗时实测调整；全量任务建议放在夜间/周末时间窗口。

四、组合策略落地要点

触发机制怎么配

优先让扫描触发与 MR 门禁、流水线在同一套权限与审计体系内完成，避免「扫描在 A 工具、合并在 B 工具、报告在 C 表格」的拼接成本。是否保留外部 Jenkins 等引擎，取决于既有投资，以 POC 验证为准。

扫描结果怎么处理

增量发现：默认归属当次变更，合并前修复或关联缺陷单；未修复的高危项不应静默合并。

全量发现：按严重级别分级——高危优先排期，中低危纳入迭代 backlog。

处理原则：增量问题不放过，存量问题有排期；豁免项需记录理由与复核周期。

误报率怎么控制

静态扫描误报受语言、框架、规则集影响大，不存在放之四海而皆准的误报率数字，必须以本项目2–4 周试运行为准：

1. 统计高频误报规则，禁用或调级别；
2. 对框架特有模式添加抑制或自定义规则；
3. 区分安全与风格/质量规则，避免门禁过载。

私有化与信创环境

金融、政企、军工等场景需先确认：扫描服务能否内网部署、规则库能否离线更新、报告能否满足审计留痕、是否与统一身份认证对接。以上能力应在选型 POC 中逐项验证，而非仅看规则数量宣传。

落地参考（工具配置示例）

一体化 DevOps 平台可在不同节点分别挂载增量与全量策略。以GitFox为例：支持在 PR/MR、代码推送、定时任务等节点配置增量 / 全量 / 动作触发，扫描结果可关联代码库与提交记录，并与 MR 评审、CI/CD 流水线共用同一套权限与审计；私有化与信创适配清单以官网当期材料为准。具体规则覆盖与版本差异，建议用实际仓库试用验证。

五、常见问题解答

Q1：全量扫描多久做一次合适？

一般建议每季度至少一次，或每个 major 版本发布前必做；首次接入工具时必须先做全量建立基线。发布频繁、合规要求高的团队可提高到每月一次；超大仓库若单次全量超过可接受时长，可改为分模块轮转全量或缩短增量基线窗口 + 降低全量频率。

Q2：增量扫描会漏掉历史漏洞吗？

会。增量只覆盖本次变更检测面，存量代码与未变更依赖中的问题不在范围内。解决方式是定期全量兜底，并维护基线问题清单，区分新增与遗留。

Q3：小团队适合只用增量扫描吗？

不适合。小团队更应在接入时做一次全量建基线，日常用增量；否则存量漏洞随代码积累，后期修复与合规成本更高。

Q4：增量扫描和全量扫描可以同时开启吗？

可以，且推荐。提交/PR 跑增量，夜间或周末跑全量，两者触发节点分开，多数商业与开源工具均支持独立策略，无需人工切换。

Q5：每次提交都做全量扫描行不行？

不建议。大型仓库全量可达小时级，会严重拖慢 CI 与交付节奏。需要快速反馈的场景用增量；全量放在固定时间窗口或发版节点更合理。