用Veracode做审计，真正要交付的不是一张扫描截图，而是一套可复核的证据链：同一版本的构建包、同一口径的扫描结论、同一批问题的处置闭环。只要把应用版本命名、扫描类型选择、导出材料与归档目录固定下来，后续无论是客户抽查还是内部复盘，都能快速说明你们做了什么、发现了什么、怎么关单的。

　　一、Veracode怎么做审计

　　审计这一步建议按“先定对象与策略，再跑扫描出结论，最后把阻断项处置到可追溯”来推进。不要一上来就跑很多次Sandbox把结果堆满，因为审计通常需要能给出Policy口径的通过与不通过结论。下面按平台常见操作路径，把一次审计从开始到出结论跑通。

　　1、固定审计对象与版本命名

　　在Veracode首页进入【My Portfolio】找到【Applications】，先确认目标应用名称与业务系统一致，再进入应用设置把版本命名规则统一为发布号加日期或构建号，确保后续导出的报告文件名能与版本号一一对应。

　　2、选择Policy还是Sandbox并写清用途边界

　　审计要出合规结论时优先跑【Policy Scan】，把Sandbox留给开发预演与修复验证；如果团队习惯先预演再审计，就要求同一份构建包先在Sandbox跑通并完成关键修复后，再用同一口径提交Policy扫描，避免两套结果互相解释不清。

　　3、准备上传包并做一次预检查

　　在CI产物目录把需要审计的构建包整理成可上传格式，优先包含实际发布的二进制或打包产物，同时保留构建信息与依赖清单；上传前先确认版本号、分支、构建时间与本次发布一致，避免误把旧包当新包扫。

　　4、在平台发起扫描并完成预扫描选择

　　进入应用后点击【Start a Scan】选择静态分析或上传扫描入口，上传构建包后等待预扫描完成；预扫描阶段如果进入模块选择界面，按审计范围勾选需要纳入的模块并确认，避免把测试样例或无关第三方目录误纳入导致噪声飙升。

　　5、在结果页形成审计结论并锁定阻断项清单

　　扫描结束后进入【Results】，先核对扫描时间、版本号、策略状态，再把阻断项与高严重度项导出为整改清单；同时在审计记录里写明本次结论是通过、未通过或带例外通过，并把结论与版本号绑定，避免同一版本多次扫描后口径漂移。

　　6、把整改闭环纳入审计而不是审计后补材料

　　对阻断项与高风险项，要求每条都有处置路径，能修复的给出修复提交与复扫验证，不能立即修复的必须走例外审批并写清到期日与补偿措施，审计材料里要能看出每条问题的状态与责任人。

　　二、Veracode证据与导出材料怎么归档

　　归档的目标是让任何人在不登录平台的情况下，也能复核你审计的范围、结论与处置证据。建议按版本建立目录，把平台导出文件、整改台账、例外审批与复扫证据放在同一处，做到查一次就能串起全链路。

　　1、按版本建立固定目录结构

　　为每次审计版本建立一个根目录，目录名包含应用名与版本号，目录下建议固定六个子目录，01范围与策略02构建与上传03扫描结果04报告导出05整改闭环06例外与批准，后续每次审计都沿用同一结构便于抽查。

　　2、导出静态分析报告并保留原始文件

　　在【Results】或报告入口点击【Download】导出Summary与Detailed报告，若支持导出XML或机器可读报告也一并导出；导出后不要只保留转换后的文件，建议把原始下载包与解压后的文件同时归档，避免后续工具无法复现解析。

　　3、导出发现项清单作为整改台账基线

　　在结果页把缺陷列表按导出功能导成CSV或XML，作为本次整改台账的基线文件；台账字段至少保留CWE分类、严重度、文件位置、发现时间、当前状态、目标关闭版本、责任人与备注，避免只留截图无法统计与对比。

　　4、SCA材料按数据导出固化并注明生成时间

　　进入SCA结果区域找到数据导出入口，点击【Generate】生成本次导出，再点击【Download】下载导出文件并归档；同时在台账里记录导出生成时间与版本号，避免后续再次导出时覆盖旧文件导致审计证据不可追溯。

　　5、把扫描配置与范围证据一起保存

　　除报告外，把上传的构建包校验信息、模块选择范围、策略名称与策略阈值截图或导出说明一起归档，至少保证别人能回答三件事，你扫了什么，按什么策略判定，哪些模块被纳入与排除。

　　6、把复扫证据与修复提交绑定到同一条记录

　　每条已修复问题在台账里补充修复提交号与合并请求链接，并在复扫后保留结果页截图或报告中可定位的条目编号，做到从台账能追到代码，从代码能追到复扫通过的证据。

　　三、Veracode审计复核与台账闭环怎么做

　　材料归档完成并不代表审计就稳了，后续版本迭代如果缺少复核机制，很容易出现问题数波动却解释不清，或者例外到期无人跟进。把复核节奏与台账管理固定下来，才能让审计从一次性动作变成持续可控的流程。

　　1、建立审计台账并写入导出文件指纹

　　台账除问题清单外，建议增加版本级字段，包括扫描类型、策略结论、阻断项数量、关键CWE分布、导出文件名与文件哈希值，确保同一版本的材料不会被误替换或误覆盖。

　　2、用差异对比解释两次扫描结果变化

　　相邻版本对比时先对导出的CSV或XML做差异对比，明确变化来自修复关闭、新增缺陷、扫描范围变化还是策略阈值变化，再把解释写进版本审计记录，避免只用总数涨跌做结论。

　　3、把Sandbox与Policy的使用边界写进审计说明

　　在审计说明中写清Sandbox用于开发验证与迭代，Policy用于最终合规判定与对外材料，导出材料以Policy为准，Sandbox材料只作为研发过程证据，防止取错口径导致审计结论不可复核。

　　4、例外与到期复审做成强制提醒机制

　　对已批准例外在台账里记录到期日与复审责任人，每周或每迭代固定检查一次到期清单，到期前必须给出处置动作，完成修复复扫或重新评审风险并更新批准记录，避免例外长期挂账。

　　5、发布前做一轮最小复核清单

　　发布冻结前按清单核对版本号一致、Policy结论已确认、关键报告已导出、SCA导出已更新、阻断项已关闭或有有效例外与到期日、归档目录已冻结只读，复核通过后再进入发布流程，减少审计期间补材料的概率。

　　总结

　　Veracode审计要跑通，先把应用与版本口径统一，用Policy扫描形成可对外的结论，再把阻断项整改与例外审批纳入同一条闭环。导出与归档要按版本目录固化报告、缺陷清单、SCA导出、扫描范围与配置证据，并把修复提交与复扫结果绑定到台账里。最后用差异对比、例外到期复审与发布前最小复核，把审计变成可追溯、可复现、可持续的工程流程。