mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
4531 字
12 分钟
安全工程实践
2026-04-27

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 威胁建模流程#

graph TB ASSET["资产识别"] --> DIAGRAM["绘制数据流图"] DIAGRAM --> THREAT["威胁识别<br/>(STRIDE)"] THREAT --> RISK["风险评估"] RISK --> MITIGATE["缓解措施"] MITIGATE --> VERIFY["验证"]
步骤说明输出
资产识别确定需要保护的资产资产清单
数据流图绘制系统交互图DFD
威胁识别用 STRIDE 逐组件分析威胁列表
风险评估评估威胁的可能性和影响风险矩阵
缓解措施设计安全控制安全设计

1.3 STRIDE 详细演练:在线支付系统#

以一个在线支付系统为例,完整走一遍 STRIDE 威胁建模流程。这是安全工程中最核心的实践——不是纸上谈兵,而是真正能发现设计缺陷的方法论。

第一步:绘制数据流图(DFD)#

数据流图是威胁建模的基础。它描述了系统中的数据如何在各组件之间流动,每个外部实体、处理过程、数据存储和信任边界都需要标注。

graph LR USER[" 用户<br/>(外部实体)"] -->|HTTPS 请求| GW[" API 网关<br/>(信任边界)"] GW -->|认证请求| AUTH[" 认证服务"] AUTH -->|Token| GW GW -->|业务请求| PAY[" 支付服务"] PAY -->|加密卡号| VAULT[" 卡号保险库"] PAY -->|交易记录| DB[" 交易数据库"] PAY -->|结算请求| BANK[" 银行网关<br/>(外部实体)"] style USER fill:#fff3e0,stroke:#e65100 style BANK fill:#fff3e0,stroke:#e65100 style GW fill:#e8f5e9,stroke:#2e7d32 style VAULT fill:#fce4ec,stroke:#880e4f

第二步:逐组件 STRIDE 分析#

对 DFD 中的每个组件,逐一检查六类威胁。以下是对支付服务的完整分析:

组件威胁类型具体威胁严重性缓解措施
API 网关欺骗伪造 API Key 绕过认证mTLS + API Key 轮换
API 网关拒绝服务大量请求耗尽连接池限流 + 熔断 + WAF
认证服务欺骗JWT 伪造(alg=none)严重严格校验 alg 字段
认证服务权限提升普通用户获取 admin Token严重RBAC + 最小权限
支付服务篡改修改交易金额严重数字签名 + 幂等校验
支付服务信息泄露日志中记录明文卡号脱敏 + PCI DSS 合规
卡号保险库信息泄露数据库拖库泄露卡号严重AES-256-GCM + HSM
交易数据库否认商户否认已完成的交易不可抵赖签名 + 审计日志
银行网关欺骗伪造银行回调通知回调签名验证 + IP 白名单

第三步:风险矩阵与优先级#

quadrantChart title 威胁风险矩阵 x-axis 影响低 --> 影响高 y-axis 可能性低 --> 可能性高 quadrant-1 立即处理 quadrant-2 计划处理 quadrant-3 监控 quadrant-4 接受 JWT伪造: [0.9, 0.8] 卡号泄露: [0.95, 0.4] 金额篡改: [0.9, 0.3] DDoS: [0.6, 0.9] 银行回调伪造: [0.7, 0.5] 审计日志缺失: [0.4, 0.3]
Warning

威胁建模最大的陷阱是”一次做完就不管了”。系统在演进,威胁也在变化——每次架构变更、新功能上线、外部依赖更新时,都应该更新威胁模型。建议将威胁建模纳入设计评审(Design Review)的必经环节。

二、安全开发生命周期#

2.1 安全设计原则#

原则说明实践
纵深防御多层安全TLS + 应用加密 + 磁盘加密
最小权限只授予必要权限RBAC、短有效期 Token
失败安全失败时拒绝访问默认拒绝
安全默认默认配置安全禁用不安全算法
不信任输入验证所有输入参数化查询、输入校验

2.2 微软 SDL 流程#

微软的安全开发生命周期(Security Development Lifecycle, SDL)是业界最成熟的安全开发框架。它不是”上线前做一次安全测试”,而是将安全嵌入开发的每个阶段:

graph LR T1[" 培训"] --> T2[" 需求分析<br/>安全需求+隐私评估"] T2 --> T3[" 设计<br/>威胁建模+攻击面分析"] T3 --> T4[" 实现<br/>安全编码+静态分析"] T4 --> T5[" 验证<br/>模糊测试+渗透测试"] T5 --> T6[" 发布<br/>最终安全审查+事件响应计划"] T6 --> T7[" 响应<br/>漏洞响应+安全更新"] style T1 fill:#e3f2fd,stroke:#1565c0 style T3 fill:#fff3e0,stroke:#e65100 style T4 fill:#e8f5e9,stroke:#2e7d32 style T5 fill:#fce4ec,stroke:#880e4f style T7 fill:#ffebee,stroke:#c62828
SDL 阶段安全活动输出物关键工具
培训安全意识培训、安全编码规范培训记录内部培训平台
需求安全需求分析、隐私影响评估安全需求文档、PIA 报告需求追踪系统
设计威胁建模、攻击面缩减威胁模型文档、DFDSTRIDE、Attack Trees
实现安全编码、编译器安全选项、静态分析安全代码、SAST 报告Semgrep、SonarQube
验证模糊测试、动态分析、渗透测试测试报告、漏洞清单Burp Suite、AFL
发布最终安全审查(FSR)、事件响应计划FSR 报告、IRP 文档检查清单
响应安全响应、漏洞修补安全公告、补丁CVE 追踪系统

2.3 Shift-Left Security:安全左移#

“安全左移”的核心思想是:安全问题发现得越早,修复成本越低。IBM 的研究数据显示,生产阶段修复一个安全漏洞的成本是设计阶段的 100 倍。

发现阶段相对修复成本典型缺陷示例
需求/设计1x缺少认证机制
编码6xSQL 注入、硬编码密钥
测试15x权限绕过、XSS
预发布30x配置错误、证书过期
生产100x数据泄露、服务中断
graph LR subgraph 传统方式["传统方式:安全右移"] D1[设计] --> C1[编码] --> T1[测试] --> R1[发布] --> S1[" 安全测试<br/>(太晚了!)"] end subgraph 左移方式["Shift-Left:安全左移"] D2[" 威胁建模"] --> C2[" SAST+SCA"] --> T2[" DAST+渗透测试"] --> R2[" 安全审查"] --> P2[发布] end style 传统方式 fill:#ffebee,stroke:#c62828 style 左移方式 fill:#e8f5e9,stroke:#2e7d32
Note

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 os
from kms_client import get_secret
app.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 bcrypt
def 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)定义了渗透测试的七个阶段,是业界最完整的渗透测试方法论:

graph TB P1["1⃣ 前期交互<br/>确定范围、目标、规则"] --> P2["2⃣ 情报收集<br/>OSINT、DNS、子域名"] P2 --> P3["3⃣ 威胁建模<br/>识别攻击路径"] P3 --> P4["4⃣ 漏洞分析<br/>自动化扫描+手工测试"] P4 --> P5["5⃣ 渗透利用<br/>利用漏洞获取访问"] P5 --> P6["6⃣ 后渗透<br/>权限维持+数据获取"] P6 --> P7["7⃣ 报告编写<br/>发现+风险+建议"] style P1 fill:#e3f2fd,stroke:#1565c0 style P4 fill:#fff3e0,stroke:#e65100 style P5 fill:#ffebee,stroke:#c62828 style P7 fill:#e8f5e9,stroke:#2e7d32
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 伪造
会话管理会话固定、CSRFCookie 安全属性
输入验证SQL 注入、XSS、命令注入
错误处理堆栈跟踪泄露密钥信息泄露
密码学弱算法、硬编码密钥、IV 复用核心测试项
业务逻辑竞态条件、价格篡改签名绕过
客户端DOM XSS、Open Redirect
APIIDOR、批量赋值、速率限制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 test
npm audit
工具类型检测内容
SemgrepSAST代码模式匹配
SonarQubeSAST代码质量+安全
SnykSCA依赖漏洞
gitLeaks密钥硬编码密钥

4.2 SAST / DAST / SCA 工具详解#

安全测试工具按分析方式分为三大类,各有优劣,需要组合使用:

graph TB subgraph SAST[" SAST — 静态应用安全测试"] S1["分析源码/字节码"] S2["无需运行程序"] S3["早期发现漏洞"] end subgraph DAST[" DAST — 动态应用安全测试"] D1["运行时黑盒测试"] D2["模拟真实攻击"] D3["发现运行时漏洞"] end subgraph SCA[" SCA — 软件成分分析"] A1["扫描依赖树"] A2["比对 CVE 数据库"] A3["许可证合规检查"] end SAST --> COMBO["组合使用<br/>覆盖全生命周期"] DAST --> COMBO SCA --> COMBO style SAST fill:#e3f2fd,stroke:#1565c0 style DAST fill:#fff3e0,stroke:#e65100 style SCA fill:#e8f5e9,stroke:#2e7d32 style COMBO fill:#fce4ec,stroke:#880e4f
维度SASTDASTSCA
分析对象源码/字节码运行中的 HTTP 接口第三方依赖
分析时机编码/构建阶段测试/预发布阶段构建/部署阶段
误报率较高(20-30%)较低(5-10%)低(基于 CVE)
漏洞覆盖代码逻辑漏洞运行时漏洞已知依赖漏洞
是否需要代码否(需依赖清单)
典型工具Semgrep、SonarQube、CodeQLZAP、Burp Suite、NucleiSnyk、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 ./project
trivy image --severity HIGH,CRITICAL myapp:latest
# Snyk 扫描依赖漏洞
snyk test --severity-threshold=high
snyk monitor # 持续监控
# npm audit 检查 Node.js 依赖
npm audit --audit-level=high
npm audit fix # 自动修复
# Python 依赖安全检查
pip audit # PyPA 官方工具
safety check --json # Safety CLI

4.3 安全审计清单#

审计项检查内容
密码学使用算法选择、密钥管理、随机数
认证授权MFA、Token 安全、RBAC
数据保护加密、脱敏、访问控制
网络安全TLS、CORS、CSP
日志监控审计日志、异常检测
依赖安全漏洞扫描、版本管理

安全审计清单详细版#

审计域检查项通过标准检测方法
密码学对称加密算法使用 AES-256-GCM 或 ChaCha20-Poly1305SAST 规则匹配
密码学密钥长度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 pickle
data = pickle.loads(request.data) # 远程代码执行!
# 安全:使用 JSON 或安全的序列化
import json
data = json.loads(request.data)
# 危险:SSRF — 直接请求用户提供的 URL
import requests
resp = requests.get(request.json['url']) # 可访问内网!
# 安全:URL 白名单 + 域名校验
from urllib.parse import urlparse
ALLOWED_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)
Note

安全工程不是”上线前做一次渗透测试”——它是贯穿整个开发生命周期的持续实践:设计时威胁建模、编码时安全检查、测试时渗透测试、运行时持续监控。

五、安全事件响应#

5.1 事件响应生命周期#

当安全事件发生时,系统化的响应流程比”救火式”处理有效得多。NIST SP 800-61 定义了事件响应的四个阶段:

graph TB P1[" 准备阶段<br/>预案、团队、工具"] --> P2[" 检测与分析<br/>监控、告警、分类"] P2 --> P3[" 遏制与根除<br/>隔离、修补、恢复"] P3 --> P4[" 后期活动<br/>复盘、改进、报告"] P4 -.->|"持续改进"| P1 style P1 fill:#e3f2fd,stroke:#1565c0 style P2 fill:#fff3e0,stroke:#e65100 style P3 fill:#ffebee,stroke:#c62828 style P4 fill:#e8f5e9,stroke:#2e7d32
阶段关键活动输出
准备建立事件响应团队(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
Caution

密钥泄露后,仅更换密钥是不够的——用旧密钥加密的所有数据都应视为已泄露。必须:(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 泄露。

技术链条

graph LR A[" WAF 上的 SSRF 漏洞"] --> B["获取 EC2 元数据"] B --> C["窃取 IAM 临时凭证"] C --> D["访问 S3 存储桶"] D --> E["下载 700+ 数据文件"] style A fill:#ffebee,stroke:#c62828 style E fill:#ffebee,stroke:#c62828
失败环节问题正确做法
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 管道中,实现自动化安全检查:

graph LR COMMIT[" 代码提交"] --> PRE[" Pre-commit<br/>gitLeaks 密钥检测"] PRE --> PR[" PR 检查<br/>Semgrep SAST"] PR --> BUILD[" 构建<br/>SCA 依赖扫描"] BUILD --> TEST[" 测试<br/>DAST 动态扫描"] TEST --> SCAN[" 镜像扫描<br/>Trivy 容器扫描"] SCAN --> DEPLOY[" 部署<br/>IaC 安全检查"] DEPLOY --> MONITOR[" 运行时<br/>监控与告警"] style PRE fill:#e3f2fd,stroke:#1565c0 style PR fill:#e3f2fd,stroke:#1565c0 style BUILD fill:#fff3e0,stroke:#e65100 style TEST fill:#fff3e0,stroke:#e65100 style SCAN fill:#fce4ec,stroke:#880e4f style MONITOR fill:#e8f5e9,stroke:#2e7d32

7.2 GitHub Actions 安全管道配置#

.github/workflows/security.yml
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: false

7.3 Pre-commit 安全钩子#

.pre-commit-config.yaml
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-commit
pre-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 到运行时监控
Warning

安全工程最大的敌人不是攻击者,而是”安全债务”——那些”以后再说”的安全决策。每一次跳过威胁建模、每一次忽略 SAST 告警、每一次推迟依赖升级,都在累积安全债务。和金融债务一样,安全债务的利息是复利——越晚还,代价越高。


参考#

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

安全工程实践
https://blog.souloss.com/posts/cryptography/security-engineering-practice/
作者
Souloss
发布于
2026-04-27
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时