安全开发生命周期（SSDLC）

🔧 “安全不是加功能，是改流程”

很多团队的做法：先写代码 → 上线前找安全团队”扫一下” → 发现一堆漏洞 → 延期上线修复。

这是错的——安全的理念应该从需求阶段就融入开发流程，而不是最后加一道”安检”。

SSDLC（Secure Software Development Lifecycle，安全开发生命周期） 就是把”安全”植入软件开发的每一个阶段。

🏪 **类比：盖房子”

不安全的方式：房子盖完了再检查——“承重墙不够结实，拆了重砌”

SSDLC 的方式：打地基时就考虑防震（需求阶段）、设计图纸时标注承重要求（设计阶段）、施工时用合格材料（编码阶段）、验收时做承重测试（测试阶段）

---

📋 SSDLC 各阶段

阶段	安全活动	问题：如果不做
需求	威胁建模、安全需求定义	上线了才发现安全需求没考虑
设计	安全架构评审、攻击面分析	架构缺陷后期极难修复
编码	安全编码规范、静态代码扫描	漏洞被引入代码库
测试	渗透测试、SAST/DAST	漏洞被带到生产环境
部署	安全配置、密钥管理	默认配置泄露敏感信息
运维	漏洞扫描、事件响应	被攻击了才发现

---

🔍 威胁建模——“做个黑客”提前想攻击路径

威胁建模是 SSDLC 需求阶段最关键的活动——在写代码之前，站在攻击者角度思考”怎么攻击这个系统”。

最常用的威胁建模框架——STRIDE（微软提出）：

Spofing（伪装）— 冒充他人身份
Tampering（篡改）— 修改数据
Repudiation（否认）— 否认自己做过的事
Information Disclosure（信息泄露）— 暴露敏感信息
Denial of Service（拒绝服务）— 让系统不可用
Elevation of Privilege（权限提升）— 获得更高权限

对每个组件，问自己”这个组件会不会被 STRIDE 中的哪种方式攻击？“

安全测试

方法	含义	工具举例
SAST（静态分析）	扫描源代码找漏洞	SonarQube、ESLint 安全规则
DAST（动态分析）	运行中扫描应用	OWASP ZAP、Burp Suite
渗透测试	人工模拟攻击	专业安全测试员
依赖扫描	检查第三方库是否已知漏洞	npm audit、Trivy

# npm 依赖安全扫描
npm audit                    # 检查依赖中的已知漏洞
npm audit fix                # 自动修复可修复的漏洞

# OWASP ZAP——DAST 工具
# 自动扫描 Web 应用，检测 SQL 注入、XSS 等

---

📝 小结

概念	一句话
SSDLC	安全融入全生命周期——从需求到运维
威胁建模	提前想”攻击者会怎么搞这个系统”
STRIDE	六类威胁的框架——伪装/篡改/否认/泄露/拒绝/提权
SAST	静态度量扫描源代码
DAST	动态运行中扫描应用
渗透测试	人工安全测试——模拟真实攻击

为什么先学这个？ SSDLC 是”主动防御”——在被攻击前就防范。但如果已经被攻击了怎么办？——数字取证。