SDL 与 DevSecOps
覆盖题库四.47（SDL 概念与七阶段流程、威胁建模、代码审计在 SDL 中的位置）、四.50（DevSecOps 安全左移、CI/CD 安全卡点、甲方落地视角）。
前面所有篇讲的是”怎么找漏洞”（技术），本篇讲”怎么让漏洞少产生、早被发现”（体系）。一句话概括：单个漏洞靠技术，成批漏洞靠流程。这篇解决的是——如何把代码审计嵌进研发流程，让安全从”事后救火”变成”过程内建”。
先修知识
- 软件开发生命周期（SDLC）：一个软件从”想做个东西”到”下线退役”的完整过程：需求→设计→开发→测试→发布→运维。本篇所有概念都挂在这条线上。
- 威胁建模：设计阶段做的”纸上攻防推演”——架构图画出来，先假设自己是攻击者，把能想到的攻击路径列出来，提前设计对策。类比：盖楼前先在图纸上推演”小偷会从哪里翻进来”，而不是等入住后再装防盗网。
- DFD（数据流图）：一种只画四样东西的架构草图——进程（圆圈）、数据存储（两条平行线）、外部实体（方框）、数据流（箭头）。威胁建模的输入材料。
- 信任边界：数据从”不可信区域”流入”可信区域”的分界线，比如用户浏览器→你的服务器。类比：小区的大门——威胁都集中在门口，不会出现在客厅内部。
- CI/CD 流水线：代码从提交到上线的自动化流水线：git push → 自动构建 → 自动测试 → 自动部署。DevSecOps 就是往这条流水线上加安全检查点。
- 卡点 / 质量门禁（Quality Gate）：流水线上的”检查站”，检查不通过就不放行（阻断构建/发布）。类比：机场安检，带水就拦下。
- SLA（服务等级协议）：这里指漏洞修复的时限承诺，比如”高危 24 小时内修完”。
- PoC（概念验证）：证明漏洞真实存在的一段可复现的输入/脚本。甲方推动修复时的”证据”。
- 0day / Nday：0day=厂商还没出补丁就被利用的漏洞；Nday=补丁已发布但很多人没打的漏洞（Log4Shell 爆出后的头几周，打的都是 Nday 时间差）。
一、SDL（Security Development Lifecycle，安全开发生命周期）
1.1 概念
- 是什么：一句话——把安全活动嵌入软件开发每个阶段的流程框架，微软 2002 年”可信计算”备忘录后启动、2004 年起正式全面推行。类比：不是等楼盖完再请消防验收，而是让消防监理从打地基那天起就天天在工地盯着。
- 为什么会出现（动机）：微软在 2000 年代初被 Windows 漏洞搞怕了——Blaster、Slammer 蠕虫连环爆发，全是”写完再测、测完再补”模式的恶果。事后补丁成本极高还伤口碑，于是把安全动作拆进每个开发阶段，从源头减少漏洞产生。
- 核心思想三句话：
- 安全不是测试阶段才做的事，而是从需求到退役的全流程责任；
- 越早发现修复，成本越低——设计期修一个漏洞的成本约为发布后的 1/100（业界常用数据，具体倍数因研究而异）；
- SDL 是流程 + 角色 + 工具 + 度量的组合，不是买一个工具就完事。
微软官方文档：https://www.microsoft.com/en-us/securityengineering/sdl（Microsoft SDL Practices）。
1.2 微软 SDL 七阶段流程与安全动作
微软 SDL 经典划分为七个阶段：培训（Training）→ 需求（Requirements）→ 设计（Design）→ 实施（Implementation）→ 验证（Verification）→ 发布（Release）→ 响应（Response）。
逐阶段理解（每阶段都问自己一个问题）：
| 阶段 | 核心问题 | 安全动作（必背） |
|---|---|---|
| 0 培训 Training | 人先懂安全 | 全员安全意识培训（OWASP Top 10、注入/XSS 成因）；针对开发的安全编码规范培训；针对测试的漏洞挖掘培训。为什么排第一：工具拦不住”开发者根本不知道危险”——人会写出工具规则库之外的错法。 |
| 1 需求 Requirements | 要建什么安全目标 | 制定安全需求与隐私需求（数据分类、合规要求如等保/GDPR）；建立 Bug Bar（漏洞分级门槛）：明确什么级别的漏洞必须修复才能发布；任命安全顾问/安全负责人 |
| 2 设计 Design | 架构上怎么防 | 威胁建模（Threat Modeling）：数据流图（DFD）+ STRIDE 枚举威胁；攻击面分析/缩减（Attack Surface Reduction）；识别信任边界；输出设计级安全决策（认证方案、加密方案、权限模型） |
| 3 实施 Implementation | 写代码时怎么防 | 安全编码规范落地；使用批准的工具链与函数白名单（禁用危险 API，如 C 的 strcpy/gets、Java 的不安全反序列化配置）；SAST 静态扫描；SCA 组件扫描（第三方依赖 CVE 排查）；代码评审 |
| 4 验证 Verification | 做出来对不对 | DAST 动态测试/渗透测试；模糊测试（Fuzzing）；攻击面复核；人工代码审计（重点业务逻辑、鉴权、加密）；威胁建模结果回验 |
| 5 发布 Release | 能不能上线 | 发布前最终安全评审（FSR，Final Security Review）；制定**事件响应计划（IR Plan）**与回滚预案；安全文档归档；批准/不批准上线（质量门禁） |
| 6 响应 Response | 出事了怎么办 | 安全事件响应流程（PSIRT）；漏洞披露与补丁管理；根因分析与复盘，把新漏洞类型回灌到培训与检查项（闭环） |
Warning
面试常问”SDL 七个阶段”，顺序别记错：培需设实验发响（谐音助记）。每个阶段答 2~3 个代表性安全动作即可，重点说清设计阶段的威胁建模和实施/验证阶段的静态扫描与代码审计——这两块是代码审计的主战场。
二、威胁建模与 STRIDE
2.1 威胁建模是什么
- 是什么：一句话——在写代码之前，用攻击者视角审视架构图，把威胁列成清单并提前设计缓解措施。它是 SDL 设计阶段的核心活动。类比：开店前先蹲在门口观察——“收银台靠窗容易被砸窗抢、后门没锁、监控有死角”，然后针对每条装对策。
- 为什么会出现：开发者的本能是”实现功能”，不会天然去想”这个功能会被怎么滥用”。没有威胁建模，安全对策就是开发完后的打补丁——改架构的成本这时候已经高了一个量级。
标准动作五步：
- 绘制 DFD（数据流图）：画出进程、数据存储、外部实体、数据流；
- 识别信任边界（Trust Boundary）：用户→前端、前端→后端、应用→数据库、内网→外网的跨越点——威胁集中在边界上（客厅里不会有小偷，小偷都在门窗处）；
- 用 STRIDE 逐元素枚举威胁；
- 评估风险并设计缓解措施（认证、加密、审计、限速等）；
- 输出威胁清单，纳入开发任务。
2.2 STRIDE 六类威胁（必背）
- 是什么：微软提出的威胁分类法，取六个英文单词首字母，保证你枚举威胁时不漏类。类比：体检的六大科室——挂号时按科室走一遍，哪科有病查哪科，不会漏查。
| 威胁 | 含义 | 对抗的安全属性 | 典型例子 | 缓解措施 |
|---|---|---|---|---|
| Spoofing 伪装/欺骗 | 冒充他人身份 | 认证 | 盗用 session、伪造 JWT、钓鱼 | 强认证、MFA、签名 token |
| Tampering 篡改 | 修改数据或代码 | 完整性 | 中间人改包、参数篡改价格、文件替换 | 签名、哈希校验、TLS、输入校验 |
| Repudiation 抵赖 | 否认做过的操作 | 不可抵赖性 | 转账后否认、删库后声称没干过 | 审计日志、数字签名、日志保护 |
| Information Disclosure 信息泄露 | 数据被未授权读取 | 机密性 | 越权读他人订单、.git 泄露、报错回显堆栈 | 加密、访问控制、最小化输出 |
| Denial of Service 拒绝服务 | 使服务不可用 | 可用性 | 资源耗尽、正则 ReDoS、慢速攻击 | 限流、配额、超时、资源隔离 |
| Elevation of Privilege 提权 | 获得不该有的权限 | 授权 | 水平/垂直越权、普通用户改 admin 字段 | 服务端鉴权、最小权限、参数白名单 |
记忆技巧：六个字母分别对应六种安全属性的”反面”（S→认证失效、T→完整性失效、R→不可抵赖失效、I→机密性失效、D→可用性失效、E→授权失效）。答题时给一个字母配一个例子最稳。
2.3 案例带读：给一个”登录+下单”系统做威胁建模
光背表没用，走一遍真实流程。假设系统很简单：用户浏览器 → 前端 Web 服务器 → 后端应用 → 数据库，外加一个管理员后台。
第 1 步：画 DFD + 标信任边界
[用户浏览器] ──HTTP──▶ [Web 前端] ──内网API──▶ [后端应用] ──SQL──▶ [(数据库)]
▲ │ │
└──── 信任边界① ─────┘ │
└── 信任边界② ──────────┘
[管理员] ──HTTPS──▶ [管理后台] ────────────────────┘
信任边界①：互联网→你的服务器（最危险）；信任边界②：应用→数据库（数据越界读写都发生在这）。
第 2~4 步：用 STRIDE 逐元素枚举 + 设计缓解（节选，实际要逐个元素过完六类）：
| 元素 | STRIDE | 具体威胁 | 缓解措施 |
|---|---|---|---|
| 浏览器→Web 的数据流 | T 篡改 | 下单请求里的 price 参数被改成 0.01 | 价格以后端数据库为准，不信前端传值 |
| 浏览器→Web 的数据流 | S 伪装 | 攻击者拿别人的 session cookie 冒充登录 | cookie 加 HttpOnly/Secure、绑定过期时间、登录态服务端校验 |
| 后端→数据库 | I 信息泄露 | SQL 注入拖库读走全部用户数据 | 参数化查询、数据库账号最小权限 |
| 管理后台 | E 提权 | 普通用户直接访问 /admin 路径 | 后台不暴露公网 + 服务端逐接口鉴权（不靠前端隐藏菜单） |
| 登录接口 | R 抵赖 | 用户异地登录后声称”不是我干的” | 登录日志记录 IP/时间/设备，日志防篡改 |
| Web 前端 | D 拒绝服务 | 短信轰炸接口被无限调用打爆短信通道 | 单手机号限频、图形验证码 |
第 5 步：这张表直接转成开发任务——“价格后端取值""后台接口鉴权”排进迭代。威胁建模的产出物不是一份好看的文档，而是一张张开发工单。
为什么在设计期做？ 看表里”管理后台不暴露公网”这条——这是架构决策。如果实施完再发现，意味着重新部署网络拓扑，成本翻十倍；设计期改，只是图纸上挪一根线。
2.4 STRIDE 在设计阶段的位置
- 威胁建模发生在 SDL 的第二阶段（Design），产出物是威胁模型文档 + 设计级安全措施；
- 设计阶段消除的威胁成本最低；
- 后续阶段与威胁建模联动：实施期按威胁清单验证对应控制是否落地，验证期按威胁清单做针对性渗透测试，响应期发现新威胁类型回灌威胁模型——威胁模型是活文档，不是一次性作业。
三、代码审计在 SDL 中的位置与角色
3.1 代码审计处于哪个阶段
面试陷阱题：别说”代码审计在验证阶段”——它横跨多个阶段，不是单一阶段动作：
| SDL 阶段 | 代码审计的角色 |
|---|---|
| 需求/设计 | 参与评审，提供”攻击者视角”（历史漏洞模式库、业务逻辑风险点） |
| 实施（Implementation） | 主战场之一：SAST/SCA 自动化扫描 + 关键模块人工审计（鉴权、加密、反序列化、文件操作） |
| 验证（Verification） | 主战场之二：发布前全量/增量白盒审计，配合 DAST 交叉验证，复核业务逻辑漏洞（自动化扫不出的：越权、支付逻辑、竞态） |
| 响应（Response） | 漏洞根因分析（为什么没被拦住）、编写检测规则、把新模式回灌到 SAST 规则与编码规范 |
3.2 为什么自动化扫描替代不了人工审计
四类自动化天然搞不定的事：
- 业务逻辑漏洞：工具不懂”这个接口应该先扣款再发货”——它看到的每一行代码都”语法正确”，但流程本身是错的；
- 越权/IDOR：工具不知道”订单 1001 属于用户 A 不属于用户 B”这个归属关系，改个 ID 读到别人订单，每一行代码看起来都没问题；
- 上下文依赖：一条数据流跨服务/跨异步队列时 SAST 追踪中断（数据进了 Kafka，静态分析就断了）；
- 误报过滤：工具报 500 条，人工确认可能只有 20 条真漏洞，还要判断可利用性——这个判断本身就是审计。
结论（背）：SAST 做广度（地毯式覆盖 Sink），人工做深度（业务逻辑 + 调用链确认），两者互补，不是替代。
3.3 企业安全体系建设：制度 + 流程 + 工具
面试问”代码审计在 SDL 中的位置”通常延伸到”如何落地”，三层答法：
| 层面 | 内容 | 例子 |
|---|---|---|
| 制度 | 管理层背书的红线规范 | 安全编码规范、漏洞修复 SLA（高危 24h/中危 7d）、发布安全红线（存在高危漏洞禁止上线）、漏洞责任与奖惩 |
| 流程 | 安全活动嵌入研发流程 | 需求评审带安全项、设计评审必做威胁建模、代码评审 Checklist 含安全项、发布前 FSR、事件后复盘 |
| 工具 | 把流程自动化 | SAST（Semgrep/CodeQL/SonarQube）、SCA（Trivy/OWASP Dependency-Check/Snyk）、Secret 扫描（Gitleaks/TruffleHog）、DAST（OWASP ZAP/Burp）、IAST、漏洞管理平台（DefectDojo） |
Warning
关键论述句（背下来）：“代码审计不是 SDL 的某个孤立环节，而是贯穿需求→验证的技术能力；落地靠制度定红线、流程定动作、工具提效率，三者缺一不可——只有工具没有制度，漏洞没人修；只有制度没有工具，效率撑不起迭代速度。“
四、DevSecOps：安全左移与 CI/CD 安全卡点
4.0 SDL 与 DevSecOps 是什么关系
初学者最容易把这两个词搞混，先理清：
- SDL 回答”做什么”：一套阶段化的安全活动框架（培训、威胁建模、扫描、评审、响应），诞生于瀑布开发时代，节奏以”月”为单位；
- DevSecOps 回答”怎么自动化地做”：在敏捷/持续交付时代，发布节奏以”天”甚至”小时”为单位，SDL 里那些靠人排队的动作（安全评审、渗透测试）根本排不过来，于是把 SDL 的安全活动改造成流水线里的自动化检查点。
一句话：DevSecOps 不是推翻 SDL，而是 SDL 在 CI/CD 时代的落地形态——七阶段的安全活动一个没少，只是从”人跑流程”变成”流水线跑脚本”。面试被问区别时，答这句就够。
4.1 概念与安全左移（Shift Left）
- 是什么：一句话——把安全检查做成自动化脚本塞进 CI/CD 流水线，让”提交代码”这个动作自动触发安全检测，安全成为每个流水线参与者的共同责任（“Security as Code”）。类比：工厂流水线每道工序装上传感器自动质检，而不是等产品下线后集中送质检部。
- 为什么会出现：SDL 时代安全评审靠人排队——开发两周，安全团队评审再花一周，业务等不起，最后要么绕过安全直接上线，要么安全沦为”盖章部门”。DevSecOps 的解法是：不靠人盯，把检查点做成流水线的自动化关卡。
安全左移是核心思想（“左”指时间线靠前）：
- 传统（右移）：开发完 → 安全团队测试 → 打回返工。问题：反馈慢、返工贵、阻塞发布，安全和开发天然对立；
- DevSecOps（左移）：安全检查尽可能前移到开发者写代码的当下——IDE 里刚写完
executeQuery("..."+id)，插件立刻标红。越靠左，修复成本越低、反馈越快； - 三条原则（背）：自动化（卡点全进流水线，不靠人肉）、分层防御（每个卡点拦一类问题，不指望一个工具包打天下）、不阻塞为原则（误报治理好，卡点才不会沦为噪音被绕过）。
4.2 CI/CD 各阶段安全卡点（重点，必背）
按代码生命周期”从写到跑”，六个卡点：
开发者本机 提交 构建/CI 部署 运行时
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
① IDE 插件 → ② 提交钩子 → ③ SAST/SCA/Secret 扫描 → ⑤ 制品扫描 → ⑥ 运行时 RASP
(实时提示) (pre-commit) + ④ DAST/IAST(测试环境) (镜像/包) (监控+阻断)
| 卡点 | 位置 | 工具举例 | 拦截什么 |
|---|---|---|---|
| ① IDE 安全插件 | 写代码时 | SonarLint、Semgrep VS Code 插件 | 危险函数调用、明显注入模式、硬编码密码——毫秒级反馈，成本最低 |
| ② 提交钩子（pre-commit/pre-receive） | git commit/push 时 | Gitleaks、pre-commit 框架 | 私钥/AK/SK 等密钥泄露（进历史记录就难清除，必须在此拦截）；服务端 GitLab/GitHub 再做一道 pre-receive 兜底 |
| ③ CI 阶段静态扫描 | MR/构建流水线 | SAST：Semgrep、CodeQL、SonarQube；SCA：Trivy、OWASP Dependency-Check、Snyk；IaC 扫描：Checkov、tfsec；Secret：Gitleaks/TruffleHog | 代码级漏洞模式（SQLi/XSS/反序列化 Sink）、第三方依赖已知 CVE、Dockerfile/K8s 配置错误、遗漏的密钥 |
| ④ DAST/IAST | 部署到测试环境后 | DAST：OWASP ZAP、Burp Suite、xray；IAST：插桩 Agent（洞态 IAST 等） | 运行态可触发的漏洞（鉴权绕过、反射 XSS、配置问题）；IAST 在功能测试时顺带收集数据流，误报率低于 SAST/DAST |
| ⑤ 制品扫描 | 镜像/包推送仓库前 | Trivy、Grype、Harbor 内置扫描 | 容器镜像 OS 包 CVE、基础镜像漏洞、恶意包、许可证合规 |
| ⑥ 运行时防护 RASP | 生产环境 | OpenRASP（百度开源）、商业 RASP、WAF（长亭雷池等） | 真实攻击流量：RASP 插桩在应用内部，能看到完整上下文，可阻断 0day 利用（如 Log4Shell 的 JNDI lookup） |
每个卡点的”为什么在这”（理解比死记重要）：
- 密钥扫描为什么必须在 ② 提交钩子？因为密钥一旦进 git 历史，
git rm删掉也留痕，攻击者翻历史照样拿到——只能拦在进历史之前； - SAST 为什么在 ③ CI？因为需要完整项目代码做数据流分析，IDE 里只看到单个文件；
- DAST 为什么在 ④？因为它要打真实的 HTTP 请求，必须等应用跑起来；
- RASP 为什么在 ⑥ 生产？因为前五个卡点再严也只能拦”已知模式”，真实 0day 攻击只发生在生产流量里。
Warning
答题时按”写→提→扫→测→包→跑”六步背，每步说一个工具 + 拦一类问题。重点记住：SAST 在 CI、DAST 在测试环境、RASP 在生产；密钥扫描必须前置到提交钩子。
落地长什么样（一段带注释的 GitLab CI 示例，看懂即可）：
stages: [security-scan, build, deploy]
secret-scan: # 卡点②+③的密钥扫描
stage: security-scan
script: gitleaks detect --source . --exit-code 1 # 发现密钥直接非零退出 → 流水线失败
sast: # 卡点③ SAST
stage: security-scan
script: semgrep scan --config=p/owasp-top-ten --error # 命中规则即报错
sca: # 卡点③ SCA
stage: security-scan
script: trivy fs --severity HIGH,CRITICAL --exit-code 1 .
image-scan: # 卡点⑤ 制品扫描
stage: build
script: trivy image --severity CRITICAL --exit-code 1 myapp:$CI_COMMIT_SHA注意每条的 --exit-code 1——这就是”门禁”的物理实现：检查不通过，命令返回非零，流水线自动中止，代码走不到部署。
4.3 质量门禁（Quality Gate）与误报运营
- 质量门禁是什么：流水线中”不达标即阻断”的阈值规则，是安全卡点能否真正生效的关键。没有门禁的扫描只是”出了份没人看的报告”。
- 为什么会失败：门禁设计最常见的死法不是拦不住漏洞，而是误报太多把开发逼疯——天天被拦，最后所有人学会怎么绕过卡点，体系名存实亡。
| 设计点 | 实践 |
|---|---|
| 分级阻断 | 高危/严重（如硬编码私钥、命令注入 Sink 确认、SCA 高危且有公开 exploit）→ 阻断构建；中低危 → 告警不阻断，记工单限期修复 |
| 增量门禁 | 只对本次变更的增量代码设门禁（“新代码不产生新高危”），存量问题走专项治理——避免一刀切全量拦截导致业务停摆 |
| 例外机制 | 误报/不可利用的走安全团队审批的豁免流程，带过期时间，防止豁免变永久后门 |
| 基线与趋势 | 记录漏洞总数趋势，要求”只减不增” |
误报运营（SAST 落地的最大痛点，四步闭环）：
- 规则调优：关掉低价值规则、为项目自定义规则（Semgrep 自定义规则成本低）；结合项目框架做白名单（如全项目用参数化 ORM，则该模块 SQLi 规则降权）；
- 去重聚合：同一 Sink 多处报告合并；按文件/模块聚类派单，别给开发刷 50 条同根告警；
- 确认率度量：跟踪”工具报告数 → 人工确认数 → 修复数”漏斗，确认率长期低于阈值的规则下线；
- 反馈闭环：开发者标注误报 → 安全团队修规则 → 规则库迭代，让工具越用越准。
金句（面试收尾用）：“门禁的敌人不是漏洞而是误报——误报率高到一定程度，开发者会集体学会绕过门禁，整个体系就失效了。“
五、甲方落地视角：审计团队如何运转
5.1 与研发的协作模式
| 协作点 | 做法 |
|---|---|
| 嵌入而非对立 | 安全人员参加需求/设计评审（security champion 模式：每个团队设安全接口人，安全团队做赋能而不是警察） |
| 说话用研发语言 | 报告漏洞给可复现 PoC + 数据流链路 + 修复建议代码，而不是甩一句”这里有个高危”；能用单元测试/复现脚本证明的最好 |
| 修复建议分级 | 给”立即修复方案”和”长期架构方案”两档，允许业务在风险接受下选短期缓解 |
| 培训赋能 | 把高频漏洞（本项目反复出现的越权、注入）做成内部培训 case，比讲 OWASP 通用课有效——用自己项目的真实代码讲，开发者最有体感 |
“说话用研发语言”到底长什么样？ 对比两份报告：
差的报告（会被开发怼回来）：
用户中心模块存在 SQL 注入漏洞，高危，请尽快修复。
好的报告（开发看完直接能改）：
漏洞：订单查询接口 SQL 注入（高危） 位置：
OrderDao.java:47，find()方法中order参数拼接到ORDER BY数据流：GET /order?order=→OrderController.list()→OrderService.query()→OrderDao.find()，全程无过滤 复现 PoC：curl 'https://test.internal/order?order=(IF(1=1,SLEEP(5),1))'，响应耗时 5 秒即确认 修复建议：order走白名单校验——if (!Arrays.asList("id","time").contains(order)) order = "id";，长期方案是全项目 ORDER BY 场景统一收口到公共方法 影响面：该接口未做参数校验，任何登录用户可拖库
差报告让开发自己找、自己猜、自己复现，一来一回三天没了；好报告把开发要做的每一步都铺平，修复意愿和速度完全不同——这就是”赋能”和”警察”的区别。
5.2 修复推动（漏洞闭环）
一个漏洞从发现到关闭的标准流水线，四步：
- 定级与 SLA：按可利用性 + 影响面定级（不能只信 CVSS 基础分——内网未认证 RCE 和需管理员权限的 XSS 不能同级）；高危 24h~72h、中危一周、低危排期；
- 派单到人：漏洞进缺陷管理系统（Jira/DefectDojo），有明确 owner、deadline、状态机（待确认→待修复→待验证→已关闭）；
- 复测验证：修复后安全团队复测（不是开发说修了就关了），验证 PoC 失效 + 检查是否引入绕过变种（常见剧情：开发把
'过滤了，攻击者换宽字节//**/绕过——复测就是抓这个）； - 升级机制：超 SLA 未修的自动升级到研发负责人，高危超期可触发发布冻结。
5.3 复盘指标（度量安全体系有效性）
| 指标 | 说明 |
|---|---|
| 千行代码漏洞率 / 漏洞密度趋势 | 总体应下降；按团队/项目横比找出薄弱点 |
| 漏洞逃逸率 | 上线后被外部（SRC/渗透/攻击）发现的漏洞占比——衡量流水线卡点有效性，是最真实的”考试成绩” |
| MTTR（平均修复时长） | 按级别统计，衡量修复推动效率 |
| 卡点拦截分布 | 各卡点拦截量：若 90% 问题都在 DAST 阶段才发现，说明左移失败，IDE/SAST 卡点形同虚设 |
| 误报率 / 确认率 | 衡量工具运营健康度 |
| 重复漏洞率 | 同类漏洞反复出现 → 培训/规范/规则没跟上，需要根因治理 |
复盘闭环（背）：每个高危漏洞做根因分析 → 归类到”规范缺失 / 培训缺失 / 工具漏报 / 门禁失效”四类 → 对应补齐动作——这是”体系”区别于”救火队”的标志。救火队灭火，体系改易燃物。
六、面试题眼/速答
| 题目 | 一句话答案 | 展开两三句 |
|---|---|---|
| 四.47 什么是 SDL？微软 SDL 七阶段？ | SDL 是把安全嵌入软件开发生命周期每个阶段的流程框架；七阶段：培训→需求→设计→实施→验证→发布→响应 | 培训做安全意识教育；需求定安全需求和 Bug Bar；设计阶段做威胁建模（DFD+STRIDE）和攻击面缩减；实施落地编码规范、危险 API 禁用、SAST/SCA；验证做 DAST/Fuzzing/人工审计；发布做最终安全评审 FSR；响应做事件处置并把新漏洞模式回灌体系。口诀：培需设实验发响。 |
| 四.47 STRIDE 是什么？ | 威胁建模的威胁分类法：S 伪装、T 篡改、R 抵赖、I 信息泄露、D 拒绝服务、E 提权 | 分别对抗认证、完整性、不可抵赖性、机密性、可用性、授权六大安全属性。用法是在设计阶段对 DFD 的每个元素逐类枚举威胁，保证不漏类；答题时每类配一个例子（如 T=中间人改包、E=越权改 admin 字段）。 |
| 四.47 代码审计在 SDL 中的位置？ | 贯穿多阶段：实施期 SAST/SCA+关键模块人工审计，验证期发布前白盒审计，响应期根因分析与规则回灌 | 自动化扫描做广度、人工审计做深度（业务逻辑/越权工具扫不出）。落地靠**制度（修复 SLA、发布红线）+ 流程（评审/FSR/复盘）+ 工具（SAST/SCA/DAST 平台）**三层，缺一不可。 |
| 四.50 什么是 DevSecOps / 安全左移？ | 把安全自动化嵌入 DevOps 流水线，让安全成为全员责任；左移=检查尽可能前移到开发早期 | IDE 即告警是左移的极限形态，越早修复成本越低、对发布阻塞越小。三原则：卡点全自动化、每卡点拦一类问题的分层防御、以不阻塞业务为原则（误报必须治理）。 |
| 四.50 CI/CD 有哪些安全卡点？ | 六卡点：IDE 插件→提交钩子→CI 静态扫描→测试环境 DAST/IAST→制品扫描→运行时 RASP | ①SonarLint 实时提示；②Gitleaks 拦密钥（必须前置，密钥进 git 历史就清不干净）；③SAST: Semgrep/CodeQL，SCA: Trivy/Snyk，IaC: Checkov；④ZAP/xray/IAST 插桩；⑤Trivy/Grype 扫镜像；⑥OpenRASP 拦真实攻击含 0day。口诀：写→提→扫→测→包→跑。 |
| 四.50 质量门禁怎么设计？误报怎么治理？ | 分级阻断：高危可利用的阻断构建、中低危告警限期修；增量门禁只卡新代码；豁免需审批带过期时间 | 误报治理四步：规则调优与项目自定义、去重聚合派单、跟踪”报告→确认→修复”漏斗下线低确认率规则、误报反馈驱动规则迭代。核心认知：门禁的敌人是误报不是漏洞，误报失控则开发者集体绕过，体系失效。 |
| 四.50 甲方怎么推动漏洞修复？ | 定级设 SLA→派单到人→安全复测才关闭→超期升级/冻结发布 | 定级按可利用性+影响面而非只信 CVSS；复测要验证 PoC 失效+检查绕过变种；复盘用漏洞密度趋势、逃逸率、MTTR、卡点拦截分布、误报率、重复漏洞率六个指标，每个高危做根因归类（规范/培训/工具/门禁）并补齐动作。 |
附：速查卡片
- 七阶段口诀：培需设实验发响（Training/Requirements/Design/Implementation/Verification/Release/Response）。
- STRIDE：伪装、篡改、抵赖、信息泄露、拒绝服务、提权。
- 六卡点口诀：写（IDE）→ 提（钩子）→ 扫（SAST/SCA/Secret）→ 测（DAST/IAST）→ 包（制品）→ 跑（RASP）。
- 三层体系：制度定红线、流程定动作、工具提效率。
- 核心矛盾：门禁有效性 = 拦截力 × 低误报；误报失控则门禁名存实亡。