DevSecOps 概览
vs DevOps、纵深防御与脚本。
DevSecOps 概览
这一课你将能做到
- 说清楚 DevSecOps 与传统 DevOps、传统安全的本质区别，以及「安全左移」到底左移到哪里
- 在一个 Spring Boot 项目的 CI 流水线中加入至少 3 个自动化安全检查（依赖扫描、SAST、密钥泄漏检测）
- 画出一张「纵深防御」分层图，并指出本站（Spring Boot + MySQL + Redis + Nginx）每一层对应哪些控制措施
为什么要学
传统模式下，安全团队像「上线前的门卫」：开发三个月，安全测三天，发现一堆漏洞，要么延期、要么带病上线。DevSecOps 把这件事反过来：安全不再是最后一道闸，而是每一行代码提交时就自动跑的检查。
人话：DevSecOps = 把安全从「毕业考试」变成「随堂测验」。每次 git push 都自动跑一遍漏洞扫描、密钥检测、依赖审计，问题在写得最便宜的时候就被拦住。
对 Java 后端工程师来说，这不是「安全团队的事」：Log4Shell（2021 年 Log4j2 远程代码执行漏洞）让一个依赖就能打穿全网。你的 pom.xml 里每一个坐标，都是攻击面的一部分。
先建立图像
DevSecOps 流水线中的安全关卡：
开发机 CI 流水线 生产环境
│ │ │
├─ pre-commit ├─ ① SAST 静态扫描 ├─ WAF / Nginx 限流
│ (gitleaks ├─ ② 依赖扫描 ├─ 运行时监控
│ 密钥检测) │ (OWASP Dependency-Check) ├─ 入侵检测
│ ├─ ③ 单元测试+安全测试 ├─ 日志审计
└─ IDE 插件 ├─ ④ 镜像扫描 (Trivy) └─ 定期渗透测试
(SonarLint) └─ ⑤ DAST 动态扫描
纵深防御（Defense in Depth）分层：
| 层 | 本站对应组件 | 典型控制 |
|---|
| 边界层 | Nginx | HTTPS、限流、IP 白名单 |
| 应用层 | Spring Boot | 认证授权、输入校验、CORS 白名单 |
| 数据层 | MySQL / Redis | 加密存储、最小权限账号、密码哈希 |
| 基础设施层 | 服务器 / 容器 | 防火墙、镜像扫描、补丁管理 |
| 人员流程层 | 团队 | Code Review、安全培训、应急响应 |
跟着做
步骤 1：装 pre-commit 密钥检测（gitleaks）
密钥误提交到 git 是最常见的事故。在仓库根目录装 gitleaks，每次 commit 自动扫：
# Windows 用 scoop 或直接下载 release 二进制
scoop install gitleaks
# 在仓库根目录执行，生成 pre-commit 钩子
cd h:\work\java-nav
gitleaks protect --staged --verbose
也可以手动跑一次全量历史扫描：
gitleaks detect --source . --report-path gitleaks-report.json
发现泄漏的处理：不要简单删掉文件再提交——git 历史里还在。必须轮换该密钥（换新的），再用 git filter-repo 清历史。
步骤 2：给 Spring Boot 项目加依赖漏洞扫描
在 pom.xml 加 OWASP Dependency-Check 插件：
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>9.0.9</version>
<configuration>
<!-- CVSS 7 分以上构建失败，逼着你修 -->
<failBuildOnCVSS>7</failBuildOnCVSS>
</configuration>
<executions>
<execution>
<goals><goal>check</goal></goals>
</execution>
</executions>
</plugin>
mvn org.owasp:dependency-check:check
# 报告输出在 target/dependency-check-report.html
打开报告能看到每个依赖的 CVE 编号、严重级别、修复版本建议。
步骤 3：CI 里加 SAST 静态扫描
GitHub Actions 示例（GitLab CI 同理），在 .github/workflows/security.yml：
name: Security Checks
on: [push, pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run gitleaks
uses: gitleaks/gitleaks-action@v2
- name: Dependency Check
run: mvn org.owasp:dependency-check:check
- name: SpotBugs + FindSecBugs
run: mvn compile com.github.spotbugs:spotbugs-maven-plugin:check
这样每次 push 都会跑密钥检测 + 依赖扫描 + Java 静态安全分析，任何一关失败 PR 就合不进去。
步骤 4：建立安全检查清单
把下面这张表贴进团队 Wiki，每次发版前过一遍：
[ ] 依赖扫描无 CVSS ≥ 7 的未修复漏洞
[ ] 配置文件无明文密码（用环境变量或 Vault）
[ ] Nginx 已启用 HTTPS，HTTP 强制跳转
[ ] 接口有限流和鉴权，无匿名写接口
[ ] 日志不打印密码、token、身份证等敏感字段
[ ] 数据库账号非 root，权限最小化
讲清楚要点
-
安全左移（Shift Left）：把安全活动从「上线前测试」提前到「编码、提交、构建」阶段。越早发现，修复成本越低——编码阶段修一个 SQL 注入只要改一行，上线后被利用可能就是一次数据泄露事故。
-
纵深防御（Defense in Depth）：不依赖单一防线。Nginx 被绕过还有 Spring Security，Spring Security 有漏洞还有数据库最小权限托底。任何一层失守都不等于全局失守。
-
安全是流程不是工具：装 10 个扫描器但报告没人看，等于没装。关键是把检查结果接入流水线门禁（fail the build），让问题无法被忽略。
-
自动化优先：人工检查不可靠、不可持续。能写进 CI 的检查全部写进 CI，让机器做「坏人」，人做架构决策。
-
安全文化：不追责文化（blameless）才能让问题浮出来。谁提交了密钥就轮换密钥、复盘流程，而不是批斗个人——否则下次有人犯错会藏着掖着。
你可能会懵的地方
-
DevSecOps 是不是就是 DevOps 加个扫描器？
不是。工具只是表象，核心是责任转移：开发对安全负责（你写的代码你修漏洞），安全团队从「警察」变「教练」——提供工具链、定标准、做培训，而不是人肉审代码。
-
小公司没有安全团队，DevSecOps 从何做起？
从最便宜的三件事做起：依赖扫描（免费）、gitleaks（免费）、HTTPS + 安全响应头（半天工作量）。这三件能挡住 80% 的自动化攻击。
-
扫描报告一堆漏洞，都要修吗？
看三个维度：CVSS 评分（≥7 必修）、是否可达（你的代码真的调用了漏洞函数吗）、是否有 exploit 公开。先用 failBuildOnCVSS 卡住高危，中低危排期修。
-
DevSecOps 会拖慢发布速度吗？
短期会（修存量漏洞），长期反而快——因为不用在上线前被安全测试卡住返工。关键是扫描要快（分钟级），误报要少，否则开发会想办法绕过。
-
和传统渗透测试什么关系？
互补。自动化扫描抓已知漏洞（CVE、配置错误），渗透测试抓业务逻辑漏洞（越权、薅羊毛）。前者每次提交都跑，后者每年做 1-2 次。
错法对照
| 错法 | 问题 | 正解 |
|---|
| 上线前才做安全测试 | 发现问题太晚，要么延期要么带病上线 | CI 每次提交自动扫描 |
数据库密码写在 application.yml 提交进 git | 任何人克隆仓库即拿到生产密码 | 环境变量 / Vault，gitleaks 拦截 |
| 扫描器只跑不设门禁 | 报告没人看，形同虚设 | failBuildOnCVSS=7，高危直接构建失败 |
| 所有依赖永远锁死不升级 | 已知 CVE 一直暴露 | Dependabot 自动提升级 PR |
| 安全只是安全团队的 KPI | 开发觉得「与我无关」 | 漏洞归属到代码作者，修复进 sprint |
卡点急救
-
Dependency-Check 首次运行极慢、下载 NVD 数据库超时：它需要下载全量 CVE 库（几个 GB）。解法：公司内部搭 NVD 镜像，或配置 nvd.api.key（去 NVD 官网免费申请）加速增量更新，CI 里缓存 ~/.m2 下的 NVD 数据目录。
-
gitleaks 报历史提交里有密钥，但文件早删了：git 历史永久保留。解法：立即轮换该密钥（当作已泄漏处理），再用 git filter-repo --invert-paths --path 敏感文件 重写历史，强推远端，通知所有协作者重新克隆。
-
扫描误报太多，开发集体无视：误报是安全门禁的杀手。解法：为每个误报在配置里加显式 suppression（写明原因和复查日期），保持门禁「宁缺毋滥」——宁可只卡 CVSS≥9，也要保证报警即真问题。
面试常问
-
什么是安全左移？为什么重要？
把安全测试、审计活动从上线前移到开发早期（编码、提交、构建阶段）。重要性在于修复成本随阶段指数增长：编码期修漏洞成本是 1，生产期可能是 100（含事故损失）。同时避免「上线前安全卡壳」造成的交付延期。
-
DevSecOps 和传统安全审核的区别？
三个维度：时机（每次提交 vs 上线前）、责任（开发负责 vs 安全团队负责）、方式（自动化流水线门禁 vs 人工评审）。DevSecOps 中安全团队的角色从执行者变为平台和标准的提供者。
-
如果让你在 CI/CD 里落地安全，你会加哪些环节？
至少答出：pre-commit 密钥扫描（gitleaks）、构建期依赖漏洞扫描（OWASP Dependency-Check / Snyk）、SAST 静态代码分析（SpotBugs+FindSecBugs / SonarQube）、镜像扫描（Trivy）、部署后 DAST（OWASP ZAP）。并说明高危漏洞 fail build 的门禁机制。
自测三问
- 安全左移具体移到了哪些阶段？每个阶段对应什么工具？
- 纵深防御的五层分别是什么？本站技术栈每层举一个控制措施。
- 为什么密钥泄漏后「删掉文件重新提交」是错误处理？
小结一句话
DevSecOps 是把安全变成每次提交都自动运行的流水线门禁，让漏洞在修复最便宜的时候被拦住，而不是上线前的突击检查。
延伸