安全测试长期以来是研发流程中最容易被推迟的环节——功能能跑、性能达标就先上线，安全问题等出事再说。但随着供应链攻击、API 数据泄露和合规监管的持续升级，把安全左移到开发阶段已经不是加分项，而是底线要求。本文梳理安全测试的方法体系与工程化落地路径。

安全测试的核心手段可以分为四类。SAST（静态应用安全测试）直接扫描源代码与依赖，在编码阶段就能发现 SQL 注入、硬编码密钥、不安全的反序列化等问题，优点是介入早、成本低，缺点是误报率偏高，需要持续调优规则集。DAST（动态应用安全测试）在运行中的系统上模拟攻击，覆盖配置错误、认证绕过、越权访问等运行时问题，误报少但发现得晚。IAST 将探针植入运行环境，结合前两者优势，在功能测试执行的同时被动采集安全问题，是近年来在 CI 环境中增长最快的一类。SCA（软件成分分析）则专门盘点第三方依赖的已知漏洞与许可证风险，在供应链攻击频发的当下几乎是必备项。

具体测什么？OWASP Top 10 仍是最实用的检查清单起点。权限相关的问题长期占据榜首：水平越权（改个 ID 就能看别人订单）、垂直越权（普通用户调用管理员接口）在实际渗透中命中率极高，而这类漏洞自动化工具往往扫不出来，必须靠人工构造用例。注入类问题除了经典 SQL 注入，还要覆盖 NoSQL 注入、命令注入、模板注入。认证与会话方面重点看令牌是否可预测、退出后是否真正失效、多设备登录的处置策略。

API 安全值得单独强调。在微服务架构下，大量接口从未经过前端暴露，团队容易默认"内部接口不会被调用"。实际上只要网关配置有疏漏，这些接口就是完全敞开的。必须逐一验证鉴权中间件是否覆盖全部路由、是否存在批量数据遍历风险、是否对返回字段做了脱敏、是否设置了合理的限流阈值防止撞库和爬取。

敏感数据处理是另一个高频失分点。日志中打印完整身份证号、手机号、令牌，是安全审计中最常见的问题之一。测试时应主动检查日志输出、异常堆栈、接口响应体和缓存内容，确认脱敏规则真实生效。传输层要验证是否强制 HTTPS、证书是否配置正确、是否禁用了过时的加密套件。

工程化落地的关键是把安全检查嵌入流水线。建议分层设置：提交阶段跑增量 SAST 和密钥扫描，秒级反馈；合并阶段跑 SCA 依赖漏洞扫描，高危漏洞直接阻断；每日构建后跑一轮 DAST 基线扫描；每个大版本前安排一次人工渗透测试，专攻业务逻辑漏洞——这是自动化工具的能力盲区。

还有一点常被忽视：安全测试需要建立漏洞的分级与闭环机制。所有发现按 CVSS 评分和业务影响分为高中低三档，高危限时修复并阻断发布，中危纳入迭代排期，低危记录并定期回顾。没有闭环的扫描报告只会变成越堆越厚的技术债清单。

总结：安全测试要做到工具与人工互补、静态与动态结合、左移与常态化并行。工具负责覆盖广度和重复劳动，人工负责挖掘业务逻辑层面的深度漏洞。把安全能力沉淀进流水线和研发规范，才能真正降低系统的整体攻击面。