17 质量与安全门禁工具

质量门禁不是“把工具装进 CI”，而是把团队接受什么代码、发现什么风险、由谁处理、什么时候可以例外，变成可复现且可审计的工程规则。规则从开发者本机开始，串联 IDE、Git Hook、构建工具、CI 和共享扫描平台，同一输入在不同执行面必须得到可解释的一致结果。

工具负责发现与阻断，业务 owner 负责判断修复影响，安全团队负责风险处置策略，平台团队负责执行环境和凭证边界。误报、基线、升级、绕过、报告数据和责任人缺少任何一项，红灯都会逐渐退化成被习惯性跳过的噪声。

门禁分层

格式化解决风格差异，Lint 和静态分析发现代码缺陷，SAST 查找安全模式，SCA 对照依赖和镜像漏洞库，Secret 扫描寻找凭证痕迹，提交门禁负责尽早反馈。它们不能互相替代，也不能因为工具数量多就自动形成治理能力。

文章	开发者先跑通	团队继续治理
ESLint、Prettier 与 Stylelint	格式和 Lint 可在本机复现	配置边界、插件升级、历史基线和 IDE/CI 一致性
Checkstyle、SpotBugs 与 PMD	Java 违规样例被构建拦截	规则分层、抑制审查、多模块和升级治理
SonarQube	服务、Scanner 和 Quality Gate 跑通	数据库、权限、Profile/Gate、分支和升级边界
Semgrep 与 CodeQL	测试问题被规则或查询发现	构建模式、SARIF、误报、数据上传和规则 owner
Trivy、Grype 与 Dependency-Check	扫描依赖、文件系统、镜像或 SBOM	漏洞库、离线缓存、VEX/抑制、修复责任和失效时间
Gitleaks、TruffleHog 与 detect-secrets	测试凭据在提交前被发现	基线、验证、轮换、历史清理和事件响应
pre-commit、husky 与 lint-staged	提交前自动运行最小检查	Hook 分发、绕过审计、耗时预算和 CI 兜底
commitlint 与 Changesets	不合规提交和缺失变更声明失败	Monorepo、变更类型、版本影响和发布边界

每条规则至少写清：规则 ID、目的、执行位置、失败证据、默认严重度、owner、修复方式、误报申诉、临时豁免期限和升级策略。没有这些信息的“红灯”只会积累绕过，没有长期约束力。

本机检查用于快速反馈，CI 是不可绕过的最终复核，IDE 只提供辅助提示。三处使用同一份版本锁定和配置源；任何仅存在于个人 IDE 的规则都不算团队门禁，任何只能在 CI 复现的失败也属于工程缺陷。