安全测试分静态(SAST)、动态(DAST)、交互式(IAST)和人工渗透/漏洞扫描几类,各有擅长;审计与合规则回答“有没有安全证据、是否满足监管与隐私要求”。组合使用自动测试 + 人工渗透 + 合规审计,才能对系统安全水平做出可信评估,并留下可供留痕的结论。
第七幕收尾讲“拿什么证明你的安全”。前面做了威胁建模、安全编码、上线体检、应急复盘,最后要用实测验证效果,并满足合规留痕。这一节把几类测试工具讲清楚,也让“安全测试 ≠ 只跑一个扫描器”深入人心。

单靠一个工具很危险:只跑自动化扫描器会漏业务逻辑与组合利用,只靠一年两三次渗透又覆盖不了日常变更。推荐组合打法:把 SAST/依赖扫描接进每次提交(早期 + 广覆盖),用 DAST/IAST 在测试与预发布环境持续跑(贴近攻击 + 真实路径),在重大版本或高风险功能上线前做一轮人工渗透(深度补盲)。再用常规漏洞扫描做存量资产基线巡检。
审计与合规回答“你有没有把评测做好、按监管与隐私要求办”:
合规的意义不止“应付检查”:它迫使你把安全动作标准化、留痕化,反过来推动“安全可被审计”的实现。留痕越完整,出问题复盘越容易定位。
背景:给一个订单功能做安全评估。操作:SAST 扫源码、DAST 对着运行环境打注入与越权探测、再由人复核归属校验。结果:SAST 发现一处拼接 SQL,DAST 探测到一处未做归属的只读接口,人工复核确认越权可达。解读:三种手段互为补充,各抓到对方容易漏的。变式:对各类修正做修复并回流规范,再把整套检测编排进 CI 与月检,验证“测试 → 修复 → 回流 → 留痕”在安全测试上闭环成型。
同样是跑了一遍测试,一份流水账式的报告和一份结构化的报告价值完全不同。可信的测试报告至少要说清:测了什么范围(哪些接口/组件)、什么时候测的、发现了什么(含严重级别)、是否已修复、谁修复的、复测结果如何。留痕还应跨测定整个时间线——同类问题反复出现率、不同环境的扫描对比——才谈得上“趋势可见”。合规审计要看的正是这种能回答“改到哪一步了”的证据链。若报告只有“扫了一次没问题”,既无法回应监管追问,也无法支持复盘与改进,等于白测。把留痕质量当成验证结果的一部分,安全测试才真正经得起推敲。
监管与隐私要求常被当成额外负担,其实多数都能映射成前面做过的动作。给一张对照思路:加密要求对应“传输强制 HTTPS、敏感字段加密脱敏”;日志留痕对应“关键事件五要素日志 + 访问控制 + 保留期”;隐私对应“最小化收集、脱敏、用户数据权利响应”。把这些映射成一张“要求 → 技术实现 → 台账”的对照表,合规验收时就逐项核对,不用临时补。更重要的是,合规最终会反向推动内部标准化——因为它要求稳定、可审计、有证据,而这些正是把安全工程做成闭环所必需的底色。把合规从“应付检查”上升为“检验工程是否成体系”的标尺,这一节才算讲透。
安全测试的价值不在“某一次跑得漂亮”,而在能长期、稳定地跑下去。给一条可落地的编排:每次提交跑 SAST 与依赖扫描,命中高危即报警并阻回归;每个测试与预发布环境持续跑 DAST 与 IAST,覆盖真实接口与组合场景;重大版本和高风险变更上线前,由人补一轮渗透与业务逻辑审查;常规资产走漏洞扫描做存量基线。固定的下探要配回流:任何测试发现的问题,不只是这一处改掉,还要看它是“没写对”还是“规范没覆盖”,是后者就把新规则、新测试用例回喂进去,防止同类再生。把这条流水和合规台账、风险账本串起来,安全测试才从一次性的“体检”变成一套拧在研发流程里、随时能证明“我们一直在测、测了都改、改了有据”的持续工程,这正是第七幕把安全推成闭环的最后一环。