静态应用安全测试

为什么需要它

安全漏洞通常不是集成阶段突然出现的，而是代码在提交、合并、依赖引入和配置演进中逐渐积累的。等到运行时告警、渗透测试或生产事故时，定位成本已经很高。这个技能面向的是在不执行应用的前提下审查源码：它不是跑一遍功能测试，而是扫描仓库中的安全模式、数据流和常见反模式，帮助开发者在 PR 阶段就看到 SQL 注入、跨站脚本、硬编码密钥、不安全反序列化、密码滥用等问题。

它如何工作

技能先检测仓库的主要语言、框架与既有分析配置，例如 .semgrep.yml、CodeQL 查询包或 .bandit 文件；这决定后续使用哪些规则集。然后按技术栈选择工具：Semgrep 做多语言模式匹配，CodeQL 做深度语义分析，Bandit 专注 Python，ESLint 安全插件处理 JavaScript/TypeScript。扫描时保留漏洞类型、文件、行号、严重程度、CWE 和描述；多工具可并行，结果再合并、去重，并按真正阳性、假阳性和需人工复核分类。

报告按严重性与类别分组，给出易受攻击片段、风险解释、修正代码、CWE 与 OWASP 映射。最后可把扫描接入 GitHub Actions、GitLab CI、Jenkins 或 Azure DevOps，在受保护分支设置质量门禁，并用 SARIF、JSON、JUnit XML 或 Markdown 输出。

适用边界与注意点

• 自动生成代码、vendor 目录、迁移文件常产生噪音，可用 .semgrepignore 或 CodeQL 路径过滤排除。
• Jinja2、ERB、JSX 等模板语言解析能力有限，可能需插件或补充扫描器。
• 测试代码常包含故意不安全写法，建议为测试目录单独设规则或阈值。
• 大型 monorepo 的完整 CodeQL 可能较慢，PR 可只扫变更文件，夜间再全量扫描。
• 该技能主要看当前工作树；Git 历史中的密钥需配合 Gitleaks 或 TruffleHog 等工具。