在Veracode里说“做基线”，先要把两个场景分开。一个是开发流水线里的基线，也就是用Pipeline Scan的baseline file把已知问题先记下来，后续重点盯新增问题；另一个是平台里的存量治理，也就是对Upload and Scan扫出来的历史问题做分类、缓解、整改和阶段性收口。Veracode官方文档写得很清楚，Pipeline Scan支持baseline file，但它不连接Veracode Platform，所以不支持flaw mitigations或flaw matching；如果你需要在平台里做正式的缺陷治理和缓解，就要回到Upload and Scan与Triage Flaws这条线。

　　一、Veracode怎么做基线

　　如果你的目标是让CI先稳住，不被历史问题一上来全部拦死，最直接的基线做法就是用Pipeline Scan的结果文件生成baseline。Veracode官方说明里写得很明确，每次Pipeline Scan默认都会产出一个`results.json`，这个文件就可以当作已知问题基线；后续扫描把它作为baseline file传入后，扫描会把基线中的问题当作已知问题，只突出新的问题。

　　1、先跑一版完整Pipeline Scan

　　先对当前应用跑一版Pipeline Scan，让工具把现阶段问题全部扫出来。官方文档说明，扫描结果默认会保存为`results.json`，这也是后面做基线的起点。

　　2、把首轮结果保存成基线文件

　　如果不想让后续扫描覆盖默认的`results.json`，可以在首轮扫描时直接用自定义文件名保存，比如单独保存成`baseline.json`。Veracode官方建议把这类基线文件纳入版本管理，因为它本身会影响后续“哪些问题算新增”的判断。

　　3、后续扫描显式引用基线

　　在后续Pipeline Scan配置里加上`--baseline_file`，让当前扫描结果和那份基线文件比较。官方文档说明，比较时基线里的问题会被忽略，扫描结果会重点标出新的问题，这正是流水线“先控新增、再消存量”的基本做法。

　　4、把拦截条件和基线一起定下来

　　Veracode官方同时提供了`--fail_on_severity`这类参数，用来决定新增问题到什么严重度时才真正阻断构建。也就是说，基线不是单独存在的，它最好和你的门禁阈值一起配置，不然即使做了基线，流水线也未必能按团队预期工作。

　　5、平台侧不要把基线理解成同一件事

　　这里要特别分清，官方文档已经写明，Pipeline Scan的baseline file只能由Pipeline Scan自己生成，而且Pipeline Scan不支持平台侧的flaw mitigations或flaw matching。换句话说，Pipeline基线更适合做“新增问题门禁”，不适合替代平台里的正式存量治理。

　　二、Veracode存量问题如何分期治理

　　存量问题治理，更稳的做法不是一次性全量清零，而是先把问题收进平台，再按风险和业务节奏分批处理。Veracode官方的Triage Flaws和Mitigate flaws文档说明，平台侧可以对Static Analysis Upload and Scan与DAST结果进行review、triage和mitigation；同时Upload and Scan与development sandbox又允许你在生产政策之外先做开发期扫描和阶段性验证。也就是说，平台侧治理更像“正式台账管理”，而不是流水线里的轻量基线。

　　1、先把存量问题归到平台统一看

　　如果你要做的是长期治理，优先用Upload and Scan把问题沉到Veracode Platform里，而不是只停留在Pipeline Scan的JSON结果上。官方文档说明，Triage Flaws页面就是静态分析和动态分析结果的集中治理入口。

　　2、不能马上修的先做缓解而不是硬拖

　　Veracode官方对mitigation的定义很清楚，它适合处理那些短期内不准备修、当前不构成实际风险，或暂时不违反策略的问题。但官方也特别提醒，mitigation不是长期修复方案，它更适合作为阶段治理中的过渡动作。

　　3、开发阶段的问题先放sandbox消化

　　如果你不想让正在治理中的问题直接影响整条应用主线，可以先把开发期扫描放进development sandbox。官方文档说明，sandbox允许团队在生产环境之外做Upload and Scan，也可以做policy scan，而且这些sandbox结果不会影响整个应用的最终政策合规状态。这个机制很适合做“先在分支或项目组内消化，再逐步推进到主应用”的分期治理。

　　4、阶段性收口时再推进policy scan

　　当一批高风险问题处理完，或者某个版本准备出门禁结果时，再把成果收口到policy scan。官方文档说明，Upload and Scan可以按安全策略运行policy scan，用来判断应用是否符合组织的安全要求。这样做的好处是，日常开发和正式考核不会混成一团。

　　5、需要在IDE里跟进时用平台结果反导

　　如果团队希望把平台里的问题继续分配到开发者日常工作里，Veracode官方更新说明里已经提到，部分IDE集成可以把平台上的静态扫描结果导入本地，并支持提出mitigation。对存量问题来说，这能把“平台台账”继续推回研发现场。

　　三、Veracode治理节奏怎么定

　　真正把Veracode跑顺，关键不是“做不做基线”，而是把基线、门禁和治理节奏拆开。官方文档已经把这三层边界说得很清楚，Pipeline baseline file负责识别新增问题，Triage Flaws和mitigation负责平台侧治理，sandbox和policy scan则负责把开发期处理与正式合规考核分层。顺着这个边界去定节奏，团队通常不会被一开始的大量历史问题压垮。

　　1、第一阶段先锁新增

　　先用Pipeline Scan加baseline file，把新增问题和历史问题拆开，让流水线先只盯新增。这样团队不会因为老问题过多而失去门禁执行力。

　　2、第二阶段再压高风险存量

　　平台里优先盯真正高严重度、影响策略通过的问题，其余问题先triage，再决定是缓解、延期还是纳入后续版本。官方mitigation文档已经明确，缓解更适合暂时处理，而不是永久替代修复。

　　3、第三阶段用sandbox做版本内消化

　　对改动量大、修复周期长的模块，可以先放到development sandbox里迭代处理，等到某个阶段稳定后，再把结果提升到正式policy scan口径。这样既能持续推进，又不至于把整个应用主线一直挂在失败状态。

　　4、最后再把治理结果回收到正式策略

　　当新增问题已经稳住、主要存量也被压下去，再让policy scan成为正式门禁。这样做的好处，是基线不会长期变成“永远放过历史问题”的借口，而是一个阶段性控新增工具。这个判断是基于Veracode对baseline、mitigation、sandbox和policy scan各自作用边界整理出来的。

　　总结

　　Veracode怎么做基线，最直接的做法是用Pipeline Scan首次扫描产生的结果文件作为baseline file，后续扫描围绕它只识别新增问题。Veracode存量问题如何分期治理，真正稳的办法则是把平台台账、缓解、sandbox和policy scan串起来，先控新增，再压高风险存量，最后再把治理成果收口到正式策略里。这样推进下来，团队通常既能保住门禁，又不会被一开始的大量历史问题拖死。