引言

去年做了一次安全合规审查，结果出来后团队集体沉默了：

• pom.xml 里的 log4j-core 2.14.0——Log4Shell（CVE-2021-44228）在本地躺了 14 个月，无人察觉
• 某个内部工具类里用 Statement 拼接 SQL——一处 SQL 注入，被安全团队用扫描器秒穿
• Git 历史里翻出了 3 套数据库密码和 2 个云厂商 AK/SK——早就换过了，但历史记录里明晃晃躺着
• 线上容器镜像里有 47 个已知 CVE，其中 3 个是 Critical
• 一个内部管理后台，ZAP 跑了 10 分钟报了 12 个安全问题，包括越权访问和 XSS

这些问题没有任何一个是"高深漏洞"，全是通过常规工具可以自动发现的已知问题。我们只是没有把工具接进 CI/CD 流水线。

这不是个例。大部分团队的安全现状是：出了事才人工排查，不出事就当不存在。但攻击者不会等你准备好了再来——自动化扫描器 7×24 小时扫 GitHub、扫 CVE 库、扫暴露的接口。你需要的不是"更努力"，而是"工具化"。

这篇文章介绍 5 个我们接入 CI/CD 后显著提升安全基线的工具，覆盖安全漏洞的五个维度：

每个工具附 Maven/Gradle 配置、命令行用法、CI/CD 集成示例和实际扫描报告解读。文末有完整流水线配置和工具选型对照表。

一、dependency-check：扫描第三方依赖的已知 CVE

1.1 为什么需要它

你的应用代码可能很安全，但你依赖的库不一定。Java 项目动辄上百个第三方依赖（Spring Boot 一个 starter 就引入几十个传递依赖），其中任何一个被发现 CVE 都可能成为攻击入口。Log4Shell、Fastjson 反序列化、Spring4Shell——这些"核弹级"漏洞全部出在第三方依赖里。

手动检查每个依赖的 CVE 是不可能的——NVD（National Vulnerability Database）有超过 20 万条 CVE 记录，每天新增几十条。dependency-check 自动化完成"你的依赖列表 ↔ NVD 数据库"的比对。

1.2 接入方式

Maven 插件（最常用）：

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>9.2.0</version>
    <configuration>
        <!-- CVSS 评分阈值：≥ 7（High/Critical）才让构建失败 -->
        <failBuildOnCVSS>7</failBuildOnCVSS>
        <!-- 误报抑制文件（确认不是真实漏洞的条目） -->
        <suppressionFile>dependency-suppressions.xml</suppressionFile>
        <!-- 缓存 NVD 数据库到本地，加速扫描 -->
        <nvdDatafeedUrl>https://mirror.example.com/nvd/</nvdDatafeedUrl>
    </configuration>
    <executions>
        <execution>
            <goals><goal>check</goal></goals>
        </execution>
    </executions>
</plugin>

执行：

mvn org.owasp:dependency-check-maven:check
# 首次运行会下载完整 NVD 数据库（约 500MB，耗时 5~10 分钟）
# 后续运行增量更新，约 30 秒

1.3 报告解读

扫描完成后在 target/dependency-check-report.html 生成报告：

┌─────────────────────────┬──────────┬──────────┬──────────────────────────┐
│ 依赖                      │ CVSS    │ 严重程度  │ CVE 编号                  │
├─────────────────────────┼──────────┼──────────┼──────────────────────────┤
│ log4j-core 2.14.0        │ 10.0    │ Critical │ CVE-2021-44228 (Log4Shell)│
│ spring-core 5.3.18       │ 7.5     │ High     │ CVE-2022-22965 (Spring4)  │
│ jackson-databind 2.9.10  │ 8.1     │ High     │ CVE-2020-25649            │
│ commons-collections 3.1  │ 9.8     │ Critical │ CVE-2015-7501             │
└─────────────────────────┴──────────┴──────────┴──────────────────────────┘

处理优先级：

1.4 误报处理

dependency-check 有误报（比如同名不同包的库匹配到错误 CVE）。确认是误报后写抑制文件：

<!-- dependency-suppressions.xml -->
<suppressions>
    <suppress>
        <packageUrl regex="true">^pkg:maven/com.fasterxml.jackson.core/jackson-databind@.*$</packageUrl>
        <cve>CVE-2020-25649</cve>
        <cve>CVE-2018-7489</cve>
        <!-- 确认已升级到安全版本，这些 CVE 不再适用 -->
    </suppress>
</suppressions>

关键纪律：每次抑制都要写注释说明理由，并定期复审——抑制文件不是垃圾桶，堆积太多就成了安全隐患的遮羞布。

二、SpotBugs + Find Security Bugs：静态代码分析

2.1 两个工具的关系

• SpotBugs：FindBugs 的继承者，Java 字节码静态分析工具，找空指针、资源泄漏等通用缺陷
• Find Security Bugs（FSB）：SpotBugs 的安全专用插件，专注安全缺陷模式——SQL 注入、XSS、硬编码密码、不安全的加密、路径遍历等

两者配合 = 通用代码质量 + 安全专项扫描。

2.2 Maven 配置

<plugin>
    <groupId>com.github.spotbugs</groupId>
    <artifactId>spotbugs-maven-plugin</artifactId>
    <version>4.8.6.2</version>
    <dependencies>
        <!-- 挂载 Find Security Bugs 插件 -->
        <dependency>
            <groupId>com.h3xstream.findsecbugs</groupId>
            <artifactId>findsecbugs-plugin</artifactId>
            <version>1.13.0</version>
        </dependency>
    </dependencies>
    <configuration>
        <effort>Max</effort>              <!-- 分析深度：Max 最深 -->
        <threshold>Low</threshold>        <!-- 报告 Low 级别以上（全报） -->
        <failOnError>true</failOnError>
        <!-- 安全规则集，可自定义 -->
        <includeFilterFile>spotbugs-security-include.xml</includeFilterFile>
    </configuration>
    <executions>
        <execution>
            <goals><goal>check</goal></goals>
        </execution>
    </executions>
</plugin>

2.3 FSB 能发现的安全缺陷

2.4 实际扫描报告解读

mvn spotbugs:check
# 报告在 target/spotbugsXml.xml 和 target/spotbugs.html

HTML 报告按类别分组，安全缺陷在 "Security" 目录下：

Security (12 issues)
├── SQL_INJECTION (3)
│   ├── OrderDao.java:45    → "SQL 查询使用字符串拼接，存在注入风险"
│   ├── ReportDao.java:78   → "SQL 查询使用字符串拼接，存在注入风险"
│   └── UserDao.java:112    → "SQL 查询使用字符串拼接，存在注入风险"
├── HARD_CODE_PASSWORD (2)
│   ├── JdbcConfig.java:18  → "硬编码密码：'root123'"
│   └── RedisConfig.java:22 → "硬编码密码：'redis_pwd'"
├── PREDICTABLE_RANDOM (1)
│   └── TokenUtil.java:31   → "使用 java.util.Random 生成 Token，应改用 SecureRandom"
├── XSS_REQUEST (2)
│   └── ...
└── DESERIALIZATION (4)
    └── ...

2.5 修复对照

以最高频的 SQL 注入为例：

// ❌ SpotBugs 报 SQL_INJECTION
public Order findById(String id) {
    Statement stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery("SELECT * FROM orders WHERE id = " + id);
    // 用户传入 "1 OR 1=1" → 全表数据被拖
    return map(rs);
}

// ✅ 修复：PreparedStatement 参数化
public Order findById(String id) {
    PreparedStatement stmt = conn.prepareStatement("SELECT * FROM orders WHERE id = ?");
    stmt.setString(1, id);   // 参数化，注入被消除
    ResultSet rs = stmt.executeQuery();
    return map(rs);
}

2.6 误报与排除

SpotBugs 也有误报（比如 ORM 框架内部的安全用法被误报）。排除方式：

<!-- spotbugs-exclude.xml -->
<Match>
    <!-- 排除 MyBatis 生成的代码 -->
    <Class name="~.*\.generated\..*"/>
</Match>
<Match>
    <!-- 排除特定 Bug Pattern -->
    <Bug pattern="SQL_INJECTION"/>
    <Class name="com.example.SafeQueryHelper"/>
</Match>

同样，排除项要有注释说明理由，定期复审。

三、ZAP：自动化渗透测试

3.1 静态扫描的盲区

dependency-check 和 SpotBugs 都是静态分析（看代码不运行），它们发现不了运行时才暴露的问题：

• 越权访问：代码没有 SQL 注入，但接口本身没做权限校验——换个 userId 就能查别人的订单
• 信息泄露：异常堆栈直接返回给前端、Debug 模式没关、Swagger 暴露在生产
• 业务逻辑漏洞：验证码可重放、密码重置链接不过期

这些问题需要运行时渗透测试来发现。ZAP（Zed Attack Proxy）是 OWASP 出品的开源 Web 应用安全扫描器，能自动化执行大部分 OWASP Top 10 的检测。

3.2 两种扫描模式

3.3 CI/CD 集成：自动化扫描

ZAP 官方提供 Docker 镜像，在 CI 中拉起测试环境后自动扫描：

#!/bin/bash
# CI 流水线脚本：启动应用 → ZAP 扫描 → 生成报告 → 判断是否通过

# 1. 启动测试环境的应用
java -jar target/app.jar &
APP_PID=$!
sleep 15  # 等应用就绪

# 2. ZAP 基线扫描（被动 + 主动，适合 CI）
docker run -t --rm \
    -v $(pwd)/zap-reports:/zap/wrk \
    --network=host \
    ghcr.io/zaproxy/zaproxy:stable \
    zap-baseline.py -t http://localhost:8080 \
    -g zap.conf \
    -r zap-report.html \
    -J zap-report.json

# 3. 解析报告，HIGH 级别问题 > 0 则失败
HIGH_COUNT=$(jq '[.site[0].alerts[]? | select(.riskcode >= 2)] | length' zap-report.json)
if [ "$HIGH_COUNT" -gt 0 ]; then
    echo "ZAP 扫描发现 $HIGH_COUNT 个高危问题，构建失败"
    cat zap-report.html
    kill $APP_PID
    exit 1
fi

kill $APP_PID
echo "ZAP 扫描通过"

3.4 ZAP 报告解读

ZAP Baseline Scan Report
─────────────────────────
Target: http://localhost:8080

High (3):
  1. SQL Injection - /api/users?id=1
     → 测试 payload: id=1; DROP TABLE users-- 
     → 服务器响应异常，疑似 SQL 注入

  2. Path Traversal - /api/files?name=../../../etc/passwd
     → 服务器返回了 /etc/passwd 内容

  3. X-Frame-Options Header Missing
     → 所有页面缺失防点击劫持头

Medium (7):
  4. Content-Type Header Missing
  5. Information Disclosure - Debug Mode
  6. ...

3.5 ZAP vs 专业渗透测试

| | ZAP 自动扫描 | 人工渗透测试 |
|--|-------------|------------|
| 覆盖面 | OWASP Top 10 的自动化检测 | 深度业务逻辑漏洞 |
| 成本 | 免费、CI 集成 | 昂贵、按次计费 |
| 误报 | 中等（需人工确认） | 低 |
| 频率 | 每次发版 | 每年/每季度 |
| 定位 | 日常基线检查 | 深度安全审计 |

ZAP 不替代人工渗透测试，但它能在 CI 中自动发现 80% 的低级安全问题，让人工精力集中在业务逻辑漏洞上。

四、Trivy：容器镜像漏洞扫描

4.1 为什么镜像扫描必不可少

你的代码安全了，依赖也安全了，但Docker 镜像里的基础层可能有 CVE：

FROM openjdk:11-jre-slim
# 这个基础镜像可能包含已知漏洞的 Debian 包
# 比如 libssl、zlib、curl 等系统库的 CVE

镜像扫描检查的是镜像内的所有层次：操作系统包（apt/yum 安装的）、语言依赖（jar/npm 包）、配置文件（明文密钥）。Trivy 是 CNCF 项目的镜像扫描利器，速度快（秒级）、误报低、CI 友好。

4.2 使用方式

# 扫描本地镜像
trivy image --severity HIGH,CRITICAL myapp:latest

# 扫描 Dockerfile（构建前检查基础镜像）
trivy config Dockerfile

# 扫描 Git 仓库（找依赖文件里的 CVE）
trivy repo https://github.com/myorg/myapp

输出示例：

myapp:latest (debian 11.8)
==========================
Total: 47 (HIGH: 12, CRITICAL: 3)

┌──────────────────┬────────────────┬──────────┬───────────────────┬───────────────┐
│ Library           │ Vulnerability  │ Severity │ Installed Version │ Fixed Version │
├──────────────────┼────────────────┼──────────┼───────────────────┼───────────────┤
│ libssl1.1         │ CVE-2023-0286  │ CRITICAL │ 1.1.1n-0+deb11u3  │ 1.1.1n-0+deb11u4│
│ zlib1g            │ CVE-2022-37434 │ HIGH     │ 1:1.2.11.dfsg-2  │ 1:1.2.11.dfsg-3│
│ curl              │ CVE-2023-27535 │ HIGH     │ 7.74.0-1.3+deb11u1│ 7.74.0-1.3+deb11u7│
│ log4j-core        │ CVE-2021-44228 │ CRITICAL │ 2.14.0            │ 2.17.1         │
└──────────────────┴────────────────┴──────────┴───────────────────┴───────────────┘

4.3 CI/CD 集成

#!/bin/bash
# 构建镜像后立即扫描，CRITICAL 漏洞阻止发布

docker build -t myapp:${CI_COMMIT_SHA} .

trivy image \
    --severity CRITICAL \
    --exit-code 1 \
    --ignore-unfixed \
    myapp:${CI_COMMIT_SHA}

if [ $? -eq 0 ]; then
    echo "镜像扫描通过，推送"
    docker push myapp:${CI_COMMIT_SHA}
else
    echo "镜像存在 Critical 漏洞，阻止发布"
    exit 1
fi

--ignore-unfixed 只报有修复版本的 CVE——没有修复方案的问题报了也白报，等上游修复即可。

4.4 降低漏洞数的三个实践

# 多阶段构建：最终镜像只含 JRE + jar，不含编译工具
FROM maven:3.9 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

# 运行阶段：distroless 无 shell，攻击面最小
FROM gcr.io/distroless/java17-debian12
COPY --from=builder /app/target/app.jar /app.jar
EXPOSE 8080
CMD ["/app.jar"]

五、Gitleaks：Git 历史中泄露的密钥检测

5.1 Git 是密钥泄漏的重灾区

你现在的代码可能很干净，但 Git 历史里呢？ 每一次 commit 都被永久记录，除非 rewrite history。我们真实碰到过：

• 第 23 号 commit 里写了数据库密码，后来改成环境变量了，但历史还在
• 某次调试把 application-prod.yml 提交了，里面有 Redis 密码和 JWT secret
• 一段测试代码里硬编码了云厂商 AK/SK，"只测试一下"结果留在了历史

攻击者 clone 你的仓库后跑一遍 git log -p | grep -i password 就能扒出所有历史泄漏。Gitleaks 自动化这个过程，用规则引擎扫描全部历史提交。

5.2 使用方式

# 扫描当前仓库的全部 Git 历史
gitleaks detect --source . --report-path leaks.json

# 只扫描未提交的变更（作为 pre-commit hook）
gitleaks protect --staged

# 扫描某个 commit 范围
gitleaks detect --source . --log-opts="--all --since=2024-01-01"

5.3 报告解读

[
  {
    "Description": "AWS Access Key",
    "StartLine": 18,
    "EndLine": 18,
    "StartColumn": 15,
    "EndColumn": 35,
    "Match": "AKIAIOSFODNN7EXAMPLE",
    "Secret": "AKIAIOSFODNN7EXAMPLE",
    "File": "src/main/resources/application-prod.yml",
    "Commit": "a1b2c3d4e5f6...",
    "Author": "dev1",
    "Date": "2024-03-15 10:30:00",
    "RuleID": "aws-access-key-id"
  },
  {
    "Description": "Database Password",
    "Match": "password: root123456",
    "File": "src/main/resources/application.yml",
    "Commit": "f6e5d4c3b2a1...",
    "Date": "2023-11-08 14:22:00"
  }
]

Gitleaks 内置 100+ 规则，覆盖 AWS Key、Google API Key、GitHub Token、数据库密码、私钥等常见密钥模式。也支持自定义规则。

5.4 CI/CD 集成

# GitLab CI 示例
gitleaks:
  stage: security
  image:
    name: zricethezav/gitleaks:latest
    entrypoint: [""]
  script:
    - gitleaks detect --source . --report-path leaks.json --exit-code 1
  artifacts:
    when: on_failure
    paths:
      - leaks.json
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"

5.5 pre-commit hook：在泄漏发生前拦截

最佳防线是提交前拦截——密钥根本不进仓库：

# 安装 pre-commit hook
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/bash
gitleaks protect --staged --verbose
if [ $? -ne 0 ]; then
    echo "⚠️  检测到密钥泄漏！提交被拦截。"
    echo "如确认是误报，用 --no-verify 跳过（需代码评审确认）"
    exit 1
fi
EOF
chmod +x .git/hooks/pre-commit

5.6 发现泄漏后的处理

千万不要只改当前代码——历史记录里的密钥仍然暴露。正确步骤：

1. 立刻轮换泄漏的密钥（改密码/换 Key）——比删历史更重要，爬虫已经抓到了
2. 从 Git 历史中删除（git filter-repo 或 BFG Repo-Cleaner）
3. 通知有仓库访问权限的人重新 clone（历史 rewrite 后本地仓库需重新同步）
4. 审查泄漏窗口期该密钥是否被恶意使用

六、完整 CI/CD 流水线配置

把五个工具串进一条流水线，每次 push 自动执行：

# .gitlab-ci.yml（GitLab CI 示例，GitHub Actions 类似）

stages:
  - build
  - security
  - test
  - package

# ── 第 1 关：Gitleaks（提交期，最早执行） ──
gitleaks:
  stage: build
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --report-path leaks.json --exit-code 1
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"

# ── 第 2 关：dependency-check（编译期） ──
dependency-check:
  stage: security
  image: maven:3.9-eclipse-temurin-17
  script:
    - mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7
  artifacts:
    when: always
    paths:
      - target/dependency-check-report.html

# ── 第 3 关：SpotBugs + FSB（编译期） ──
spotbugs:
  stage: security
  image: maven:3.9-eclipse-temurin-17
  script:
    - mvn spotbugs:check
  artifacts:
    when: always
    paths:
      - target/spotbugs.html

# ── 第 4 关：ZAP（测试环境运行时） ──
zap-scan:
  stage: test
  image: ghcr.io/zaproxy/zaproxy:stable
  services:
    - name: myapp:${CI_COMMIT_SHA}
      alias: app
  script:
    - zap-baseline.py -t http://app:8080 -r zap-report.html -J zap.json
    - |
      HIGH=$(jq '[.site[0].alerts[]? | select(.riskcode >= 2)] | length' zap.json)
      [ "$HIGH" -gt 0 ] && exit 1
  artifacts:
    when: always
    paths:
      - zap-report.html

# ── 第 5 关：Trivy（构建期，镜像扫描） ──
trivy-scan:
  stage: package
  image: aquasec/trivy:latest
  script:
    - docker build -t myapp:${CI_COMMIT_SHA} .
    - trivy image --severity CRITICAL --exit-code 1 --ignore-unfixed myapp:${CI_COMMIT_SHA}
  dependencies:
    - build

流水线全景图

git push
  │
  ├─① Gitleaks ──────── Git 历史密钥扫描 ───── 发现密钥 → 阻断
  │
  ├─② dependency-check ─ 第三方依赖 CVE 扫描 ── CVSS≥7 → 阻断
  │
  ├─③ SpotBugs+FSB ──── 静态代码安全分析 ──── 安全缺陷 → 阻断
  │
  ├─④ ZAP ───────────── 运行时渗透测试 ────── HIGH → 阻断
  │
  ├─⑤ Trivy ─────────── 容器镜像 CVE 扫描 ──── CRITICAL → 阻断
  │
  └─ 全部通过 → 镜像推送 → 部署

七、常见问题

7.1 这五个工具全上了 CI 会很慢吗？

分阶段并行后增量可控：Gitleaks（~10s）、SpotBugs（~30s）、dependency-check（首次 ~5min，后续 ~30s）在编译阶段并行；Trivy（~20s）在构建后；ZAP（~10min）在测试环境。总增量约 12 分钟（并行后约 6 分钟），相比安全事件造成的损失，完全可以接受。

7.2 误报太多怎么办？

三个策略：① 配置抑制/排除文件（每个排除项写理由 + 定期复审）；② 调高阻断阈值（dependency-check 先只阻 Critical，习惯后再收紧到 High）；③ 给团队适应期——前两周只出报告不阻断，让大家看懂报告再开始卡。

7.3 已经有 Snyk / Fortify / Checkmarx 等商业工具了，还需要这些吗？

商业工具功能更全、误报更低，但成本高（按代码行数/开发人数计费）。本文五个工具全部开源免费，覆盖了 80% 的常规安全检查。小团队和初创项目用开源组合足够；大型企业可以商业工具替代其中几项（如 Snyk 替代 dependency-check，Checkmarx 替代 SpotBugs）。

7.4 ZAP 扫描需要登录态的接口怎么办？

ZAP 支持配置认证：在 ZAP UI 中录制登录流程（用户名密码 → 提取 Session Token → 后续请求自动带上）。CI 集成时用 zap-baseline.py -c zap.context 加载预配置的 context 文件（含认证信息）。

7.5 Trivy 扫描 distroless 镜像为什么报 0 漏洞？

distroless 没有 shell、没有包管理器、没有系统工具——攻击面极小，所以系统包 CVE 几乎为零。但 Java 依赖的 CVE 仍需 Trivy 扫描（Trivy 会扫 jar 包里的 pom 信息）。distroless 是降低系统级漏洞的最佳实践，但不能替代依赖扫描。

7.6 Gitleaks 发现历史泄漏，但密钥已经轮换了，还需要处理吗？

需要。即使密钥已轮换，历史记录里的明文密钥会造成合规审计问题（PCI-DSS、SOC2 要求密钥不能出现在版本控制中）。用 git filter-repo 清理历史 + 强制全团队重新 clone。如果仓库曾公开过（GitHub 公开仓库），还要假设密钥已被爬取，确认轮换是否彻底。

八、总结

五大工具速查卡

┌──────────────────┬───────────────┬──────────────────────────────┐
│ 工具              │ 扫描维度       │ 关键能力                      │
├──────────────────┼───────────────┼──────────────────────────────┤
│ dependency-check  │ 第三方依赖     │ NVD 数据库比对，CVSS 阈值阻断 │
│ SpotBugs + FSB    │ 源码静态分析   │ SQL注入/XSS/硬编码/反序列化   │
│ ZAP               │ 运行时渗透     │ 越权/注入/信息泄露自动化检测  │
│ Trivy             │ 容器镜像       │ 系统包+语言依赖 CVE，秒级扫描 │
│ Gitleaks          │ Git 历史       │ 100+规则检测密钥泄漏          │
└──────────────────┴───────────────┴──────────────────────────────┘

接入优先级

一句话

安全不是"出了事再补"，而是"工具化地持续发现"。五个开源工具覆盖依赖、代码、运行时、镜像、历史五个维度，接入 CI 后每次 push 自动扫描——攻击者在用自动化工具找你的漏洞，你也该用自动化工具找到它们先。

给团队的建议

互动话题：你们团队 CI 里跑了哪些安全工具？有没有被 Log4Shell / Fastjson 这类依赖漏洞"教育"过？Gitleaks 翻出来的历史泄漏最尴尬的是啥？

参考资料

• OWASP Dependency-Check 官方文档
• SpotBugs 官方文档
• Find Security Bugs 规则列表
• OWASP ZAP 官方文档
• Trivy 官方文档
• Gitleaks 官方仓库
• NVD 国家漏洞数据库
• OWASP Top 10