AES-GCM 理论上不可破解,但 nonce 重复一次就完蛋。RSA 签名数学上安全,但 PKCS#1 v1.5 的填充方案被 ROBOT 攻击打穿。TLS 1.3 协议设计完美,但 OpenSSL 的 Heartbleed 让 17% 的互联网服务器泄露了私钥。算法安全 ≠ 系统安全——安全工程要解决的是:如何在实现层面保证密码学算法的安全性,如何在系统层面发现和防御威胁。
一、威胁建模
1.1 STRIDE 模型
| 威胁 | 安全属性 | 密码学对策 | 示例 |
|---|---|---|---|
| 欺骗(Spoofing) | 认证 | 数字签名、证书 | 伪造身份 |
| 篡改(Tampering) | 完整性 | MAC、数字签名 | 修改数据 |
| 否认(Repudiation) | 不可抵赖 | 数字签名 | 否认操作 |
| 信息泄露(Info Disclosure) | 机密性 | 加密 | 数据泄露 |
| 拒绝服务(DoS) | 可用性 | 限流、冗余 | 服务不可用 |
| 权限提升(EoP) | 授权 | 访问控制 | 越权访问 |
1.2 威胁建模流程
| 步骤 | 说明 | 输出 |
|---|---|---|
| 资产识别 | 确定需要保护的资产 | 资产清单 |
| 数据流图 | 绘制系统交互图 | DFD |
| 威胁识别 | 用 STRIDE 逐组件分析 | 威胁列表 |
| 风险评估 | 评估威胁的可能性和影响 | 风险矩阵 |
| 缓解措施 | 设计安全控制 | 安全设计 |
1.3 STRIDE 详细演练:在线支付系统
以一个在线支付系统为例,完整走一遍 STRIDE 威胁建模流程。这是安全工程中最核心的实践——不是纸上谈兵,而是真正能发现设计缺陷的方法论。
第一步:绘制数据流图(DFD)
数据流图是威胁建模的基础。它描述了系统中的数据如何在各组件之间流动,每个外部实体、处理过程、数据存储和信任边界都需要标注。
第二步:逐组件 STRIDE 分析
对 DFD 中的每个组件,逐一检查六类威胁。以下是对支付服务的完整分析:
| 组件 | 威胁类型 | 具体威胁 | 严重性 | 缓解措施 |
|---|---|---|---|---|
| API 网关 | 欺骗 | 伪造 API Key 绕过认证 | 高 | mTLS + API Key 轮换 |
| API 网关 | 拒绝服务 | 大量请求耗尽连接池 | 高 | 限流 + 熔断 + WAF |
| 认证服务 | 欺骗 | JWT 伪造(alg=none) | 严重 | 严格校验 alg 字段 |
| 认证服务 | 权限提升 | 普通用户获取 admin Token | 严重 | RBAC + 最小权限 |
| 支付服务 | 篡改 | 修改交易金额 | 严重 | 数字签名 + 幂等校验 |
| 支付服务 | 信息泄露 | 日志中记录明文卡号 | 高 | 脱敏 + PCI DSS 合规 |
| 卡号保险库 | 信息泄露 | 数据库拖库泄露卡号 | 严重 | AES-256-GCM + HSM |
| 交易数据库 | 否认 | 商户否认已完成的交易 | 中 | 不可抵赖签名 + 审计日志 |
| 银行网关 | 欺骗 | 伪造银行回调通知 | 高 | 回调签名验证 + IP 白名单 |
第三步:风险矩阵与优先级
威胁建模最大的陷阱是”一次做完就不管了”。系统在演进,威胁也在变化——每次架构变更、新功能上线、外部依赖更新时,都应该更新威胁模型。建议将威胁建模纳入设计评审(Design Review)的必经环节。
二、安全开发生命周期
2.1 安全设计原则
| 原则 | 说明 | 实践 |
|---|---|---|
| 纵深防御 | 多层安全 | TLS + 应用加密 + 磁盘加密 |
| 最小权限 | 只授予必要权限 | RBAC、短有效期 Token |
| 失败安全 | 失败时拒绝访问 | 默认拒绝 |
| 安全默认 | 默认配置安全 | 禁用不安全算法 |
| 不信任输入 | 验证所有输入 | 参数化查询、输入校验 |
2.2 微软 SDL 流程
微软的安全开发生命周期(Security Development Lifecycle, SDL)是业界最成熟的安全开发框架。它不是”上线前做一次安全测试”,而是将安全嵌入开发的每个阶段:
| SDL 阶段 | 安全活动 | 输出物 | 关键工具 |
|---|---|---|---|
| 培训 | 安全意识培训、安全编码规范 | 培训记录 | 内部培训平台 |
| 需求 | 安全需求分析、隐私影响评估 | 安全需求文档、PIA 报告 | 需求追踪系统 |
| 设计 | 威胁建模、攻击面缩减 | 威胁模型文档、DFD | STRIDE、Attack Trees |
| 实现 | 安全编码、编译器安全选项、静态分析 | 安全代码、SAST 报告 | Semgrep、SonarQube |
| 验证 | 模糊测试、动态分析、渗透测试 | 测试报告、漏洞清单 | Burp Suite、AFL |
| 发布 | 最终安全审查(FSR)、事件响应计划 | FSR 报告、IRP 文档 | 检查清单 |
| 响应 | 安全响应、漏洞修补 | 安全公告、补丁 | CVE 追踪系统 |
2.3 Shift-Left Security:安全左移
“安全左移”的核心思想是:安全问题发现得越早,修复成本越低。IBM 的研究数据显示,生产阶段修复一个安全漏洞的成本是设计阶段的 100 倍。
| 发现阶段 | 相对修复成本 | 典型缺陷示例 |
|---|---|---|
| 需求/设计 | 1x | 缺少认证机制 |
| 编码 | 6x | SQL 注入、硬编码密钥 |
| 测试 | 15x | 权限绕过、XSS |
| 预发布 | 30x | 配置错误、证书过期 |
| 生产 | 100x | 数据泄露、服务中断 |
Shift-Left 不是让开发人员变成安全专家,而是通过自动化工具和安全模板降低安全实践的门槛。目标是让”做安全的事”成为”最容易的事”——自动化的 SAST 扫描比手动代码审查更容易执行,预置的安全组件模板比从零实现更不容易出错。
2.4 安全编码检查清单
| 检查项 | 要求 |
|---|---|
| 输入验证 | 白名单校验,参数化查询 |
| 输出编码 | 防 XSS,HTML 转义 |
| 认证 | MFA,安全密码存储 |
| 授权 | 最小权限,RBAC |
| 加密 | AES-GCM,不使用 ECB |
| 密钥管理 | KMS,不硬编码密钥 |
| 日志 | 不记录敏感数据 |
| 错误处理 | 不泄露内部信息 |
安全编码实践示例
# 危险:SQL 注入def get_user(user_id): query = f"SELECT * FROM users WHERE id = '{user_id}'" return db.execute(query)
# 安全:参数化查询def get_user(user_id): query = "SELECT * FROM users WHERE id = %s" return db.execute(query, (user_id,))# 危险:硬编码密钥SECRET_KEY = "my-super-secret-key-12345"app.config['SECRET_KEY'] = SECRET_KEY
# 安全:从环境变量/KMS 获取import osfrom kms_client import get_secretapp.config['SECRET_KEY'] = os.environ.get('APP_SECRET_KEY') or get_secret('app/secret-key')# 危险:明文存储密码def store_password(password): db.execute("INSERT INTO users (password) VALUES ('%s')" % password)
# 安全:bcrypt + 盐import bcryptdef store_password(password): salt = bcrypt.gensalt(rounds=12) # 工作因子 12,约 250ms hashed = bcrypt.hashpw(password.encode('utf-8'), salt) db.execute("INSERT INTO users (password_hash) VALUES (%s)", (hashed,))三、渗透测试
3.1 渗透测试类型
| 类型 | 说明 | 时间 | 成本 |
|---|---|---|---|
| 黑盒 | 无内部信息 | 长 | 高 |
| 白盒 | 有源码和架构 | 短 | 中 |
| 灰盒 | 部分内部信息 | 中 | 中 |
3.2 PTES 渗透测试执行标准
PTES(Penetration Testing Execution Standard)定义了渗透测试的七个阶段,是业界最完整的渗透测试方法论:
| PTES 阶段 | 关键活动 | 常用工具 | 输出 |
|---|---|---|---|
| 前期交互 | 确定范围、授权书、RoE | — | 渗透测试协议 |
| 情报收集 | 被动侦察、DNS 枚举、社会工程 | theHarvester、Shodan、Amass | 攻击面地图 |
| 威胁建模 | 识别高价值目标、攻击路径 | STRIDE、Attack Trees | 攻击树 |
| 漏洞分析 | 端口扫描、服务识别、漏洞扫描 | Nmap、Nessus、Burp Suite | 漏洞清单 |
| 渗透利用 | 漏洞利用、权限提升 | Metasploit、SQLMap | 访问权限 |
| 后渗透 | 横向移动、数据获取、持久化 | Cobalt Strike、BloodHound | 影响评估 |
| 报告编写 | 发现汇总、风险评级、修复建议 | — | 渗透测试报告 |
3.3 OWASP 测试方法论
OWASP Web 安全测试指南(WSTG)是 Web 应用渗透测试的事实标准。它将测试分为 11 个类别:
| WSTG 类别 | 测试项 | 密码学相关 |
|---|---|---|
| 信息收集 | WSDL、API 文档暴露 | — |
| 配置管理 | 默认配置、目录遍历 | TLS 配置错误 |
| 身份认证 | 暴力破解、默认密码、记住我 | 密码存储、JWT 安全 |
| 授权 | 越权访问、RBAC 绕过 | Token 伪造 |
| 会话管理 | 会话固定、CSRF | Cookie 安全属性 |
| 输入验证 | SQL 注入、XSS、命令注入 | — |
| 错误处理 | 堆栈跟踪泄露 | 密钥信息泄露 |
| 密码学 | 弱算法、硬编码密钥、IV 复用 | 核心测试项 |
| 业务逻辑 | 竞态条件、价格篡改 | 签名绕过 |
| 客户端 | DOM XSS、Open Redirect | — |
| API | IDOR、批量赋值、速率限制 | API Key 泄露 |
OWASP 密码学测试实战
# 1. 检测 TLS 配置testssl.sh --protocols --ciphers --vulnerabilities target.com
# 2. 检测弱加密算法nmap --script ssl-enum-ciphers -p 443 target.com
# 3. 检测证书问题echo | openssl s_client -connect target.com:443 2>/dev/null | \ openssl x509 -noout -text | grep -E "Signature Algorithm|Not After|Issuer"
# 4. 检测 HTTP 安全头curl -sI https://target.com | grep -iE "strict-transport|content-security|x-frame|x-content-type"
# 5. 检测 Cookie 安全属性curl -sI https://target.com | grep -i "set-cookie" | \ grep -cE "Secure|HttpOnly|SameSite"3.4 常见测试项
| 类别 | 测试项 | 工具 |
|---|---|---|
| 注入 | SQL/NoSQL/命令注入 | SQLMap |
| 认证 | 暴力破解、会话固定 | Burp Suite |
| 加密 | 弱算法、硬编码密钥 | testssl.sh |
| 配置 | 默认密码、开放端口 | Nmap |
| 逻辑 | 越权、竞态条件 | 手工测试 |
四、安全审计
4.1 代码审计
# 静态分析工具# SAST: 检测源码中的安全漏洞semgrep --config auto src/
# 密钥泄露检测gitleaks detect --source .
# 依赖漏洞扫描snyk testnpm audit| 工具 | 类型 | 检测内容 |
|---|---|---|
| Semgrep | SAST | 代码模式匹配 |
| SonarQube | SAST | 代码质量+安全 |
| Snyk | SCA | 依赖漏洞 |
| gitLeaks | 密钥 | 硬编码密钥 |
4.2 SAST / DAST / SCA 工具详解
安全测试工具按分析方式分为三大类,各有优劣,需要组合使用:
| 维度 | SAST | DAST | SCA |
|---|---|---|---|
| 分析对象 | 源码/字节码 | 运行中的 HTTP 接口 | 第三方依赖 |
| 分析时机 | 编码/构建阶段 | 测试/预发布阶段 | 构建/部署阶段 |
| 误报率 | 较高(20-30%) | 较低(5-10%) | 低(基于 CVE) |
| 漏洞覆盖 | 代码逻辑漏洞 | 运行时漏洞 | 已知依赖漏洞 |
| 是否需要代码 | 是 | 否 | 否(需依赖清单) |
| 典型工具 | Semgrep、SonarQube、CodeQL | ZAP、Burp Suite、Nuclei | Snyk、Trivy、Dependabot |
| CI/CD 集成 | 容易 | 需要运行环境 | 容易 |
SAST 工具配置示例
# .semgrep.yml — Semgrep 自定义规则rules: - id: hardcoded-secret patterns: - pattern: | $KEY = "..." - metavariable-regex: metavariable: $KEY regex: "(?i)(password|secret|api_key|token|private_key)" message: "检测到硬编码密钥,请使用环境变量或 KMS" severity: ERROR languages: [python, javascript, java]
- id: insecure-random pattern: random.random() message: "使用不安全的随机数生成器,请使用 secrets 模块" severity: WARNING languages: [python]
- id: ecb-mode pattern: AES.new($KEY, AES.MODE_ECB, ...) message: "ECB 模式不安全,请使用 AES-GCM" severity: ERROR languages: [python]SCA 扫描与依赖管理
# Trivy 扫描容器镜像和文件系统trivy fs --severity HIGH,CRITICAL ./projecttrivy image --severity HIGH,CRITICAL myapp:latest
# Snyk 扫描依赖漏洞snyk test --severity-threshold=highsnyk monitor # 持续监控
# npm audit 检查 Node.js 依赖npm audit --audit-level=highnpm audit fix # 自动修复
# Python 依赖安全检查pip audit # PyPA 官方工具safety check --json # Safety CLI4.3 安全审计清单
| 审计项 | 检查内容 |
|---|---|
| 密码学使用 | 算法选择、密钥管理、随机数 |
| 认证授权 | MFA、Token 安全、RBAC |
| 数据保护 | 加密、脱敏、访问控制 |
| 网络安全 | TLS、CORS、CSP |
| 日志监控 | 审计日志、异常检测 |
| 依赖安全 | 漏洞扫描、版本管理 |
安全审计清单详细版
| 审计域 | 检查项 | 通过标准 | 检测方法 |
|---|---|---|---|
| 密码学 | 对称加密算法 | 使用 AES-256-GCM 或 ChaCha20-Poly1305 | SAST 规则匹配 |
| 密码学 | 密钥长度 | RSA ≥ 2048,ECDSA ≥ P-256 | 证书检查 |
| 密码学 | 随机数生成 | 使用 CSPRNG(如 os.urandom) | SAST 规则匹配 |
| 密码学 | 密钥存储 | 使用 KMS/HSM,无硬编码 | gitLeaks + SAST |
| 认证 | 密码存储 | bcrypt/Argon2,工作因子 ≥ 12 | 代码审查 |
| 认证 | MFA | 关键操作强制 MFA | 功能测试 |
| 认证 | Token 有效期 | Access Token ≤ 15min,Refresh Token ≤ 7d | 配置审查 |
| 授权 | 权限模型 | RBAC/ABAC,最小权限 | 代码审查 |
| 授权 | IDOR 防护 | 资源访问校验所有权 | 渗透测试 |
| 数据 | 传输加密 | TLS 1.2+,HSTS 启用 | testssl.sh |
| 数据 | 存储加密 | 敏感数据 AES-256 加密 | 配置审查 |
| 数据 | 日志脱敏 | PII 字段掩码处理 | 日志审查 |
| 依赖 | 漏洞扫描 | 无 HIGH/CRITICAL 未修复漏洞 | Trivy/Snyk |
| 依赖 | 许可证合规 | 无 GPL 等传染性许可证 | SCA 工具 |
4.4 代码审查中的安全关注点
安全代码审查与普通代码审查不同,需要关注特定的安全模式。以下是按 OWASP Top 10 分类的审查要点:
| OWASP Top 10 | 代码审查关注点 | 危险模式 |
|---|---|---|
| A01 权限控制失效 | 缺少鉴权中间件、直接对象引用 | @app.route('/user/<id>') 无权限检查 |
| A02 密码学失败 | 弱算法、ECB 模式、硬编码密钥 | AES.new(key, AES.MODE_ECB) |
| A03 注入 | 字符串拼接 SQL/命令 | f"SELECT * FROM t WHERE id={id}" |
| A04 不安全设计 | 缺少威胁建模、业务逻辑漏洞 | 无速率限制的密码重置 |
| A05 安全配置错误 | 调试模式开启、默认密码 | app.run(debug=True) |
| A06 过时组件 | 已知漏洞的依赖版本 | lodash@4.17.15(原型污染) |
| A07 身份认证失败 | 弱密码策略、会话管理不当 | session['user'] = user_id 无验证 |
| A08 数据完整性失败 | 不安全的反序列化 | pickle.loads(user_input) |
| A09 日志监控不足 | 未记录安全事件 | 缺少登录失败日志 |
| A10 SSRF | 未验证的用户 URL 请求 | requests.get(user_url) |
# 危险:不安全的反序列化import pickledata = pickle.loads(request.data) # 远程代码执行!
# 安全:使用 JSON 或安全的序列化import jsondata = json.loads(request.data)
# 危险:SSRF — 直接请求用户提供的 URLimport requestsresp = requests.get(request.json['url']) # 可访问内网!
# 安全:URL 白名单 + 域名校验from urllib.parse import urlparseALLOWED_DOMAINS = {'api.example.com', 'cdn.example.com'}url = request.json['url']parsed = urlparse(url)if parsed.hostname not in ALLOWED_DOMAINS: raise ValueError("域名不在白名单中")resp = requests.get(url, timeout=5)安全工程不是”上线前做一次渗透测试”——它是贯穿整个开发生命周期的持续实践:设计时威胁建模、编码时安全检查、测试时渗透测试、运行时持续监控。
五、安全事件响应
5.1 事件响应生命周期
当安全事件发生时,系统化的响应流程比”救火式”处理有效得多。NIST SP 800-61 定义了事件响应的四个阶段:
| 阶段 | 关键活动 | 输出 |
|---|---|---|
| 准备 | 建立事件响应团队(CSIRT)、制定预案、部署监控 | IRP 文档、通讯录 |
| 检测与分析 | SIEM 告警、日志分析、威胁情报、事件分类 | 事件报告、严重性评级 |
| 遏制与根除 | 隔离受影响系统、修补漏洞、清除后门、恢复服务 | 遏制措施记录、恢复验证 |
| 后期活动 | 根因分析(RCA)、改进措施、合规报告 | RCA 报告、改进计划 |
5.2 安全事件严重性分级
| 级别 | 定义 | 响应时间 | 示例 |
|---|---|---|---|
| P0 严重 | 大规模数据泄露、核心服务完全不可用 | 15 分钟内响应 | 数据库拖库、勒索软件 |
| P1 高危 | 单点数据泄露、核心功能受损 | 1 小时内响应 | JWT 密钥泄露、API 被滥用 |
| P2 中危 | 潜在数据泄露风险、非核心功能异常 | 4 小时内响应 | XSS 发现、配置暴露 |
| P3 低危 | 信息泄露、安全配置不合规 | 24 小时内响应 | HTTP 头缺失、日志级别错误 |
5.3 密钥泄露事件响应流程
密钥泄露是密码学安全中最严重的事件之一,需要特殊的响应流程:
# 1. 立即隔离 — 撤销泄露的密钥aws kms schedule-key-deletion --key-id alias/app-secret-key --pending-window-in-days 7
# 2. 轮换密钥 — 生成新密钥并更新所有服务aws kms generate-data-key --key-id alias/app-secret-key-new --key-spec AES_256
# 3. 审计影响 — 检查泄露期间的访问日志aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=ResourceName,AttributeValue=alias/app-secret-key \ --start-time 2026-04-20T00:00:00Z
# 4. 通知受影响方 — 如果涉及用户数据# 触发数据泄露通知流程(GDPR 72 小时要求)
# 5. 修复根因 — 清理 Git 历史git filter-branch --force --index-filter \ 'git rm --cached --ignore-unmatch config/production.yml' \ --prune-empty --tag-name-filter cat -- --all密钥泄露后,仅更换密钥是不够的——用旧密钥加密的所有数据都应视为已泄露。必须:(1) 识别所有用该密钥加密的数据;(2) 用新密钥重新加密;(3) 评估数据泄露的影响范围;(4) 按法规要求通知监管机构和用户。Git 历史中的密钥即使删除了文件也会保留在历史中,必须使用 git filter-branch 或 BFG Repo-Cleaner 清理。
六、真实世界安全工程案例
6.1 案例:Equifax 数据泄露(2017)
事件:1.47 亿美国人的个人信息被泄露,包括姓名、SSN、地址、出生日期。
根因分析:
| 失败环节 | 具体问题 | SDL 对应阶段 |
|---|---|---|
| 漏洞管理 | Apache Struts CVE-2017-5638 补丁发布后 2 个月未修复 | 验证阶段 |
| 资产发现 | 不知道受影响系统运行了 Struts | 需求阶段 |
| 流量监控 | 数据外泄持续 76 天未被发现 | 响应阶段 |
| 网络隔离 | 攻击者从 Web 服务器横向移动到数据库 | 设计阶段 |
| 加密 | SSN 明文存储,未加密 | 设计阶段 |
教训:安全工程不是单一环节的失败,而是多个环节同时失效的系统性问题。
6.2 案例:Capital One 数据泄露(2019)
事件:1.06 亿信用卡申请数据通过 SSRF 漏洞从 AWS S3 泄露。
技术链条:
| 失败环节 | 问题 | 正确做法 |
|---|---|---|
| SSRF 防护 | WAF 允许访问 169.254.169.254 | 阻止对元数据服务的请求 |
| IAM 权限 | WAF 角色有过宽的 S3 读取权限 | 最小权限,仅限必要存储桶 |
| 数据分类 | 敏感数据与普通数据在同一存储桶 | 分层存储 + 加密 |
| 监控 | 大量 S3 下载未触发告警 | 异常数据访问检测 |
6.3 案例:SolarWinds 供应链攻击(2020)
事件:攻击者在 SolarWinds Orion 构建管道中植入后门,影响 18,000+ 组织。
安全工程启示:
| 维度 | 攻击手法 | 防御措施 |
|---|---|---|
| 供应链安全 | 污染构建环境注入恶意代码 | 构建管道签名验证、可重现构建 |
| 代码完整性 | 后门代码绕过代码审查 | 强制双人审查 + 自动化分析 |
| 发布验证 | 恶意更新被签名发布 | 构建产物哈希比对 |
| 运行时检测 | 后门使用 DNS 隧道通信 | 网络流量异常检测 |
| 零信任 | 后门获取 SAML Token | 条件访问策略 + 持续验证 |
七、CI/CD 安全实践
7.1 安全 CI/CD 管道架构
将安全工具集成到 CI/CD 管道中,实现自动化安全检查:
7.2 GitHub Actions 安全管道配置
name: Security Pipeline
on: push: branches: [main] pull_request: branches: [main]
jobs: # 1. 密钥泄露检测 gitleaks: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # 完整历史扫描 - name: GitLeaks Scan uses: gitleaks/gitleaks-action@v2 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# 2. SAST 静态分析 semgrep: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Semgrep SAST uses: returntocorp/semgrep-action@v1 with: config: >- p/owasp-top-ten p/cryptography p/jwt p/sql-injection
# 3. SCA 依赖扫描 snyk: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Snyk Dependency Scan uses: snyk/actions/node@master env: SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }} with: args: --severity-threshold=high --fail-on=all
# 4. 容器镜像扫描 trivy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build Image run: docker build -t myapp:scan . - name: Trivy Image Scan uses: aquasecurity/trivy-action@master with: image-ref: 'myapp:scan' severity: 'HIGH,CRITICAL' exit-code: '1'
# 5. IaC 安全检查 checkov: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Checkov IaC Scan uses: bridgecrewio/checkov-action@master with: framework: terraform,kubernetes output_format: cli soft_fail: false7.3 Pre-commit 安全钩子
repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.18.0 hooks: - id: gitleaks
- repo: https://github.com/returntocorp/semgrep rev: v1.52.0 hooks: - id: semgrep args: ['--config', 'auto', '--error']
- repo: https://github.com/Yelp/detect-secrets rev: v1.4.0 hooks: - id: detect-secrets args: ['--baseline', '.secrets.baseline']# 安装 pre-commit 钩子pip install pre-commitpre-commit install
# 对所有文件运行检查pre-commit run --all-files
# 更新钩子版本pre-commit autoupdate八、总结
上一章探讨了后量子密码学。
| 维度 | 关键要点 |
|---|---|
| 威胁建模 | STRIDE 六类威胁,数据流图驱动,每次架构变更需更新 |
| 安全设计 | 纵深防御、最小权限、失败安全 |
| SDL | 安全嵌入开发全生命周期,不是附加活动 |
| Shift-Left | 安全左移,设计阶段修复成本是生产的 1/100 |
| 渗透测试 | PTES 七阶段 + OWASP WSTG,覆盖注入/认证/加密/配置 |
| 安全审计 | SAST+DAST+SCA 组合使用,覆盖全生命周期 |
| 事件响应 | NIST 四阶段,密钥泄露需重新加密所有数据 |
| CI/CD 安全 | 自动化安全门禁,从 Pre-commit 到运行时监控 |
安全工程最大的敌人不是攻击者,而是”安全债务”——那些”以后再说”的安全决策。每一次跳过威胁建模、每一次忽略 SAST 告警、每一次推迟依赖升级,都在累积安全债务。和金融债务一样,安全债务的利息是复利——越晚还,代价越高。
参考
支持与分享
如果这篇文章对你有帮助,欢迎支持作者或分享给更多人
部分信息可能已经过时






