1. 威胁建模：先问“攻击者如何成功”
威胁建模的价值在于提前看见高风险路径。一个实用流程是： 识别资产（数据、凭据、服务）、画信任边界（内外网、第三方接口、CI runner）、 列出攻击路径（凭据泄露、依赖投毒、权限提升、供应链篡改），最后按影响和可利用性排序。 你不需要一开始就做成厚报告，先抓“高价值资产 + 高可能路径”。
图 1：威胁建模不是“列清单”，而是找出最可能被打穿的通道。
2. DevSecOps 基线：把扫描和门禁嵌入流水线
基础能力通常由四类扫描组成：代码静态扫描（SAST）、依赖漏洞扫描（SCA）、密钥泄露扫描（secret scanning）、 容器镜像扫描（container scanning）。这些扫描本身不等于安全，关键是定义“哪些问题阻断发布、哪些问题进入修复队列”。 没有分级策略，团队要么被噪声淹没，要么被强制门禁拖垮交付节奏。
| Control | Catches | Typical gate policy |
|---|---|---|
| SAST | unsafe code patterns | block on high severity in changed files |
| SCA | vulnerable dependencies | block known exploitable CVEs |
| Secret scan | tokens / keys in repo | always block + rotate immediately |
| Image scan | base image CVEs | block critical in runtime packages |
# Illustrative gate policy
if secret_leak_detected:
block = true
elif critical_cve_in_runtime and exploit_known:
block = true
elif high_sast_in_changed_code:
block = true
else:
block = false
底线：门禁规则必须可解释（why blocked），并提供修复指引与例外审批路径。
3. 供应链与身份：谁构建、谁签名、谁验证
DevSecOps 的核心问题是“你能否证明产物可信”。最少要做到： 构建身份可追踪（build identity）、制品签名（artifact signature）、部署前验证（admission policy）。 这样即使代码仓库或镜像仓库遭到篡改，系统也能在进入生产前拒绝可疑产物。
图 2：可信交付链的关键不在“有签名”，而在“签名被验证并能阻断风险”。
4. 运行时安全与响应：门禁后仍需持续防护
即使通过了所有扫描，运行时仍可能遭遇异常行为：异常网络访问、容器提权、可疑进程注入。 因此你需要运行时检测策略、告警路由、以及应急 playbook。 目标不是“零告警”，而是让每次高风险告警都能快速归因并触发标准处置。
# Runtime incident triage checklist (illustrative)
1. Identify workload + namespace
2. Confirm suspicious behavior signature
3. Isolate pod / revoke token / block egress
4. Collect forensic evidence
5. Trigger incident communication channel
建议：把安全事件分级（SECV1/2/3）并与业务 SEV 体系对齐，避免多套响应流程冲突。
5. 落地清单：把安全能力变成持续机制
- 每个核心服务完成一次最小威胁建模（资产、边界、攻击路径、风险排序）。
- 在 CI 中接入 SAST/SCA/secret/image 四类扫描，并定义可解释门禁。
- 为关键制品建立签名与部署前验证，保证“可疑产物不可上线”。
- 建立运行时检测与应急 playbook，定期演练（table-top 或 game day）。
- 将安全事件审计接入统一可观测平台，确保可追踪、可复盘。
- 预告下一章：供应链安全（SSDF/SLSA）与可信交付链进阶。