engineering-security-engineer

安全工程指南

概述

本指南涵盖应用安全、基础设施加固、威胁建模、漏洞管理和安全运营。在设计身份验证系统、审查代码中的安全问题、在 CI/CD 中设置安全扫描、响应事件、管理密钥或确保符合安全框架要求时，请使用本指南。

前 10 分钟

• 在建议修复方案前，先梳理攻击面：公开路由、身份验证入口、管理路径、文件上传／下载流程、第三方回调以及密钥加载路径。
• 先运行技能目录中附带的脚本，而不是待审查的仓库中的脚本：engineering-security-engineer/scripts/scan_secrets.sh 和 engineering-security-engineer/scripts/audit_auth_surface.py。
• 对于大型移动端／Web 仓库，先检查 src、app、server、api、config 和 scripts 等高信号目录；只有在必要时才扫描整个仓库。
• 首先使用 scripts/scan_secrets.sh。密钥暴露会立即改变处理优先级。
• 接着使用 scripts/audit_auth_surface.py，在审查登录或授权变更前，盘点身份验证相关文件以及会话／令牌模式。
• 确定任务中风险最高的信任边界：浏览器到 API、API 到服务、服务到数据库，或 CI 到云。

拒绝或升级处理

• 拒绝批准跳过授权检查、输入验证或审计日志并声称“以后再处理”的安全敏感变更。
• 如果任务涉及凭据暴露、生产环境中的不安全直接对象访问或疑似遭到入侵，请立即升级处理。
• 除非记录了具体的故障情况和范围最小的安全例外，否则不要建议弱化 CSP、CORS 或 Cookie 设置。
• 如果请求的解决方案与系统中已列明的法律或合规义务相冲突，请升级处理。

威胁建模

何时进行威胁建模

• 构建任何涉及用户数据、身份验证、授权、支付或文件上传的新功能之前。
• 添加新的外部依赖、第三方集成或 API 端点时。
• 更改数据流（新增数据库、缓存或队列）或访问模式时。
• 每季度审查一次现有威胁模型，涵盖处理 PII、金融数据或健康数据的系统。

STRIDE 框架

对系统中的每个组件进行以下评估：

• 欺骗：攻击者能否冒充合法用户或服务？缓解措施：使用强身份验证（MFA、双向 TLS、支持轮换的 API 密钥）。
• 篡改：数据在传输中或静态存储时能否被修改？缓解措施：传输时使用 TLS 1.2+，静态存储时使用 AES-256／KMS，并使用 HMAC 签名验证完整性。
• 抵赖：用户能否否认执行过某项操作？缓解措施：使用不可变审计日志，记录时间戳、用户 ID、操作和 IP。将日志发送到应用程序无法修改的独立日志存储。
• 信息泄露：敏感数据能否通过日志、错误消息、API 响应或旁路信道泄露？缓解措施：从日志中清除 PII，向客户端返回通用错误消息，并对密钥使用恒定时间比较。
• 拒绝服务：系统能否被压垮？缓解措施：实施速率限制、请求大小限制和超时控制，并设置成本上限进行自动扩缩容。
• 权限提升：用户能否获得未经授权的访问权限？缓解措施：在每一层实施 RBAC/ABAC、遵循最小权限原则，并在所有信任边界进行输入验证。

DREAD 风险评分

针对每个已识别的威胁，按以下维度评 1～10 分：

• 损害程度：遭利用时的严重程度如何？（10 = 完全数据泄露，1 = 外观问题）
• 可复现性：复现有多容易？（10 = 每次都能复现，1 = 需要罕见条件）
• 可利用性：需要多少技能／工具？（10 = 脚本小子，1 = 国家级攻击者）
• 受影响用户：会影响多少用户？（10 = 所有用户，1 = 单个用户）
• 可发现性：有多容易发现？（10 = 公开可见，1 = 需要内部人员权限）

平均分决定优先级：>7 = 严重（发布前修复），5-7 = 高（在当前迭代内修复），3-5 = 中（在当前季度内修复），<3 = 低（列入待办事项）。

OWASP Top 10 决策规则

A01：访问控制失效

• 每个 API 端点都必须检查身份验证和授权。仅在网关进行身份验证并不足够，必须在服务中再次检查。
• 使用默认拒绝策略：如果没有明确授权，则拒绝请求。
• 测试 BOLA（对象级授权失效）：请求 ID 属于其他用户的资源。必须返回 403 或 404，绝不能返回其他用户的数据。
• 测试 BFLA（功能级授权失效）：使用普通用户令牌调用管理端点。必须返回 403。
• 对所有端点实施速率限制：默认每分钟 100 个请求，身份验证端点每分钟 10 个请求，密码重置每分钟 5 个请求。

A02：加密失效

• 使用 bcrypt（成本因子 12+）或 Argon2id 对密码进行哈希处理。绝不能使用 MD5、SHA-1 或 SHA-256 对密码进行哈希处理。
• 使用 AES-256-GCM 对所有静态 PII 进行加密，或使用服务提供商管理的 KMS（AWS KMS、GCP KMS）。绝不能将加密密钥与加密数据存放在一起。
• 对所有连接强制使用 TLS 1.2+。拒绝 TLS 1.0/1.1。使用 HSTS 标头：max-age=31536000; includeSubDomains; preload。
• 绝不能在 API 响应或错误消息中记录或返回密钥、令牌、密码或完整信用卡号。仅显示末尾 4 位数字。

A03：注入

• 所有数据库操作一律使用参数化查询。绝不能通过将用户输入与字符串拼接来构造 SQL/NoSQL 查询。
• 在 API 边界验证和清理所有用户输入。使用具有严格类型的架构验证器（Zod、Joi、Pydantic），而不只是解析字符串。
• 对于 HTML 输出，使用默认启用自动转义的模板引擎（React JSX、启用自动转义的 Jinja2、Go html/template）。
• 执行 OS 命令时，使用语言原生库（而非 exec/system）。如果无法避免执行 shell 命令，则使用允许列表而非禁止列表来限定可用字符。

A04：不安全设计

• 采用纵深防御：身份验证 + 授权 + 输入验证 + 输出编码 + 加密 + 日志记录。任何单一层都不足以保障安全。
• 限制每位用户的资源消耗：最大文件上传大小（默认 10MB）、最大请求体大小（默认 1MB）、最大查询结果数（默认 100，最多 1000）。
• 在 15 分钟内登录失败 5 次后锁定账户。使用逐步延迟（1s、2s、4s、8s、16s），而非硬性锁定，以提供更好的用户体验。

A05：安全配置错误

• 在生产环境中禁用目录列表、调试端点和堆栈跟踪。使用以下命令检查：curl -v https://yourapp.com/debug、curl https://yourapp.com/.env。
• 在所有响应中设置安全标头：

  Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.yourapp.com; frame-ancestors 'none'
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  

• 部署前移除默认凭据、示例数据和未使用的端点。使用 scripts/check_security_headers.sh 扫描。

A06：易受攻击和过时的组件

• 在 CI 中运行 npm audit / pip audit / bundle audit。发现严重或高危问题时，使构建失败。
• 每月更新依赖项。对于安全补丁，在公告发布后 48 小时内更新。
• 添加新依赖项前，检查：最后提交日期（<12 个月）、下载量（JS 每周 >1k，Python 每周 >500）、未修复的 CVE（严重级别为零）和维护状态（>1 位活跃维护者）。
• 在锁定文件中固定确切的依赖版本。使用 Renovate 或 Dependabot 创建自动升级 PR，并运行测试。

A07：身份识别和身份验证失败

• 所有管理员账户，以及任何可访问个人身份信息（PII）或财务数据的账户，都必须启用多因素身份验证（MFA）。
• 签发短期访问令牌（15 分钟 JWT），并在服务端存储不透明的刷新令牌。刷新令牌必须可轮换和撤销。
• 实施密码要求：至少 8 个字符；通过泄露密码列表检查（Have I Been Pwned API 或本地 k-匿名性检查）；最大长度不得少于 128 个字符。
• 会话管理：登录后重新生成会话 ID；为所有 Cookie 设置 Secure、HttpOnly、SameSite=Strict。敏感应用的空闲会话应在 30 分钟后过期。

A08：软件和数据完整性失败

• 验证所有 CI/CD 构件的完整性：为 Docker 镜像签名（cosign/Notary），验证下载二进制文件的校验和，并使用锁定文件确保依赖项完整性。
• 将 CI/CD 操作版本固定到 SHA，而不是标签：uses: actions/checkout@a81bbbf，而不是 uses: actions/checkout@v4。标签可以移动，SHA 不会。
• 对从 CDN 加载的任何第三方脚本实施子资源完整性（SRI）。

A09：安全日志记录和监控失败

• 记录所有以下事件：身份验证事件（登录、注销、失败尝试、MFA 挑战）、授权失败（403）、输入验证失败（400）、管理员操作，以及对个人身份信息（PII）的访问。
• 切勿记录：密码、令牌、会话 ID、完整信用卡号或其他机密。对敏感字段进行遮蔽。
• 将日志发送到独立于应用的集中式只追加系统（CloudWatch、Datadog、Splunk）。合规留存期限：热存储 90 天，冷存储 1 年。
• 对以下情况发出警报：同一 IP 在 5 分钟内登录失败超过 10 次、任何非工作时间的管理员操作、任何批量导出个人身份信息（PII）的访问，以及 5xx 错误率超过 1%。

A10：服务端请求伪造（SSRF）

• 验证用户提供的所有 URL，并使用允许列表。阻止对内部 IP 范围的请求：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8、169.254.169.254（云元数据）。
• 如果应用需要获取外部 URL，请使用专用 HTTP 客户端，并设置：DNS 解析仅限公共 IP、请求超时（5 秒）和响应大小上限（10MB）。
• 对于云环境，禁用 IMDS v1，并要求使用 IMDSv2（AWS）或等效方案。元数据端点是最常见的 SSRF 提权途径。

机密管理

规则

• 切勿将机密提交到源代码管理中。使用 .gitignore 忽略 .env 文件，并在 CI 中运行 git-secrets 或 trufflehog，以发现意外提交。
• 将机密存储在：HashiCorp Vault、AWS Secrets Manager、GCP Secret Manager 或 Azure Key Vault 中。通过环境变量或 sidecar 在运行时注入。
• 按计划轮换机密：API 密钥每 90 天轮换一次，数据库密码每 90 天轮换一次，加密密钥每 365 天轮换一次。自动执行轮换——手动轮换容易被遗漏。
• 如果机密遭到泄露（提交到 git、记录到日志或发送给未授权方）：立即撤销并轮换；审计泄露期间的访问日志；如果个人身份信息（PII）可能被访问，则通知受影响用户。

CI 中的机密检测

• 对每个 PR 运行 trufflehog 或 gitleaks。发现任何问题都应阻止合并。
• 扫描 Docker 镜像中嵌入的机密：运行 docker history --no-trunc <image>，并检查是否有包含机密的 ENV/ARG。
• 检查 Terraform 状态文件中的机密：对所有机密变量使用 sensitive = true。将状态加密存储在 S3 中，并限制访问。

供应链安全

• 使用锁定文件（package-lock.json、poetry.lock、go.sum），并验证完整性哈希。
• 将 GitHub Actions 固定到提交 SHA，而不是标签。使用前先审查 Action 的源代码。
• 在 CI 中运行 SCA（软件组成分析）：Snyk、Grype 或 npm audit --audit-level=high。发现严重或高危问题时，阻止合并。
• 对于 Docker 基础镜像，使用指定版本标签（而非 latest）、验证摘要，并每月重建镜像以应用安全补丁。
• 为生产应用维护软件物料清单（SBOM）。使用 syft 或 trivy sbom 生成。

API 安全决策规则

• 对每次 API 调用进行身份验证。公共端点仍必须进行速率限制和滥用检测。
• 面向用户的 API 使用 OAuth 2.0 + PKCE。服务间调用使用带 HMAC 签名的 API 密钥。内部高安全性服务使用双向 TLS。
• 使用严格的架构验证请求正文。拒绝未知字段（禁止批量赋值）。强制限制最大负载大小。
• 返回一致的错误响应，不泄露实现细节。{"error": "invalid_request", "message": "Validation failed"} — 绝不返回堆栈跟踪或 SQL 错误。
• 为 Webhook 实现请求签名：使用共享密钥进行 HMAC-SHA256 签名。在签名中包含时间戳以防止重放攻击（时间戳超过 5 分钟则拒绝）。

自我验证协议

实施安全控制后，验证以下各项：

• 身份验证：进行以下测试：无令牌（预期为 401）、令牌过期（预期为 401）、令牌有效但角色错误（预期为 403）、令牌有效且角色正确（预期为 200）。测试每个端点，而不只是你修改过的端点。
• 输入验证：向每个输入字段发送 OWASP 测试负载：' OR '1'='1、<script>alert(1)</script>、../../../etc/passwd、; ls -la、{{7*7}}。所有负载都必须被拒绝或安全转义。
• 标头：运行 curl -I https://yourapp.com，并确认所有安全标头均存在且值正确。
• 密钥：搜索整个仓库：git log --all -p | grep -iE '(password|secret|api.key|token).*=.*[A-Za-z0-9]{8,}'。真实密钥的匹配结果必须为零。
• 依赖项：运行 npm audit / pip audit / trivy image。严重或高危漏洞必须为零。
• 日志记录：分别执行登录、登录失败、授权失败和数据访问操作。确认日志系统中出现全部四个事件，且字段正确。
• 速率限制：在 1 分钟内向受速率限制的端点发送 200 个请求。确认达到配置阈值后出现 429 响应。

故障恢复

• 报告了安全漏洞：在 1 小时内使用 DREAD 评估严重程度。严重（>7）：在 24 小时内修复，并通知受影响的用户。高（5-7）：在 7 天内修复。中（3-5）：在 30 天内修复。低（<3）：加入待办事项。
• Git 中暴露了密钥：立即执行：(1) 轮换密钥，(2) 撤销旧密钥，(3) 搜索日志，检查暴露期间是否存在未经授权的使用，(4) 使用 git filter-branch 或 BFG 从历史记录中移除，(5) 强制推送。如果可能发生了数据访问，则通知受影响的用户。
• 检测到 DDoS 攻击：启用 CDN 级别的 DDoS 防护（Cloudflare Under Attack Mode、AWS Shield）。提高速率限制阈值。如果攻击来自特定地区，则启用地理封锁。只有在不得已时才扩展基础设施规模——这很昂贵，而且攻击者也能扩大攻击规模。
• 凭据遭到泄露：立即执行：(1) 禁用遭到泄露的账户，(2) 轮换该账户可访问的所有密钥，(3) 检查审计日志，查看账户在泄露期间执行的操作，(4) 通知用户，并要求其重置密码和重新注册 MFA。如果遭到泄露的是服务账户，还要检查其可访问的所有系统是否存在横向移动迹象。
• 安全扫描失败导致部署受阻：绝不要绕过扫描。阅读扫描结果。如果结果属实，则修复问题。如果是误报，则添加明确的抑制规则，并附上说明原因的注释和复查日期（最多 90 天后）。如果扫描工具出现故障，则修复工具，不要将其禁用。

现有系统安全审计

评估现有系统的安全性时：

1. 绘制攻击面图（30 分钟）——列出所有：公开端点、身份验证机制、数据存储、外部集成、文件上传／下载功能以及管理界面。
2. 检查身份验证（15 分钟）——令牌如何签发、验证和撤销？是否支持 MFA？会话管理是否妥当？在 5 个端点上测试 BOLA。
3. 检查密钥（15 分钟）——在代码库上运行 trufflehog。检查环境变量管理方式。确认密钥未存放在 Docker 镜像、日志或 Terraform 状态中。
4. 检查依赖项（10 分钟）——运行 npm audit / pip audit / trivy。统计严重和高危问题的数量。
5. 检查标头（5 分钟）——针对生产 URL 运行 scripts/check_security_headers.sh。标记缺失的标头。
6. 检查日志记录（10 分钟）——是否记录身份验证事件？日志是否发送到集中式系统？应用程序能否修改自己的日志？
7. 检查数据处理（10 分钟）——PII 是否经过静态加密？所有流量是否都通过 TLS 传输？备份是否加密？谁有权访问生产数据？
8. 确定调查结果的优先级——使用 DREAD 为每项调查结果评分。按风险评分列出前 5 项，并提供具体的修复步骤和工作量估算。

交付物

• 威胁摘要，列出信任边界、可能的滥用途径以及按 DREAD 评分排序的主要风险。
• 修复计划，包含优先级、利用前提条件和负责人。
• 验证清单，涵盖授权、密钥、标头、依赖项和审计日志。
• 如果任务是事件响应：时间线、遏制措施、密钥轮换状态以及后续验证步骤。

合规性速查

SOC 2

• 访问控制：使用 RBAC，并按季度进行访问审查。记录谁有权访问哪些内容以及原因。
• 变更管理：所有变更都通过纳入版本控制并经过审查的 PR。不得直接访问生产环境。
• 监控：集中式日志保留 1 年。针对未经授权的访问尝试发出警报。
• 事件响应：制定书面流程，并每年进行测试。对所有安全事件进行事后复盘。

GDPR

• 数据清单：记录收集的所有个人身份信息（PII）、存储位置、收集原因和保留期限。
• 同意：处理数据前须获得明确同意。提供退订的方式应与提供订阅的方式同样简便。
• 删除权：实现数据删除流程，从所有存储位置删除用户数据（包括保留期内的备份）。
• 数据泄露通知：在 72 小时内通知监管机构。应“毫不无故拖延”地通知受影响用户。

HIPAA

• 所有静态和传输中的受保护健康信息（PHI）均须加密（静态数据使用 AES-256，传输中数据使用 TLS 1.2+）。不得例外。
• 访问控制：遵循最低必要原则。记录所有 PHI 访问，包括用户、时间戳和目的。
• 与所有处理 PHI 的供应商签订业务伙伴协议（BAA）。
• 每年进行风险评估，并为所有可访问 PHI 的人员提供安全培训。

脚本

scripts/check_security_headers.sh

检查指定 URL 的 HTTP 安全标头。测试以下标头：Content-Security-Policy、X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security、Referrer-Policy 和 Permissions-Policy。报告缺失、配置错误和已存在的标头，并给出评级。

scripts/check_security_headers.sh https://yourapp.com
scripts/check_security_headers.sh --json https://api.yourapp.com

scripts/scan_secrets.sh

扫描目录或 git 仓库，查找意外提交的机密信息。检查以下内容：API 密钥、AWS 凭据、私钥、数据库连接字符串、JWT 密钥、通用令牌赋值以及常见凭据模式。默认跳过 www/、platforms/、Pods/、dist/ 和 build/ 等生成文件或第三方依赖目录，以减少干扰。

scripts/scan_secrets.sh .
scripts/scan_secrets.sh --git-history /path/to/repo
scripts/scan_secrets.sh --format json /path/to/project

scripts/audit_auth_surface.py

扫描仓库，查找身份验证、会话、令牌、Cookie 和中间件相关的热点。默认跳过 www/、platforms/、Pods/、dist/ 和 build/ 等生成文件或第三方依赖目录。审查登录流程、RBAC 变更或会话安全前，请先运行此脚本。

scripts/audit_auth_surface.py .
scripts/audit_auth_surface.py /path/to/repo --top 20

参考资料

• 身份验证模式 -- JWT + 刷新令牌流程、OAuth 2.0 PKCE、会话管理、MFA 实现、RBAC/ABAC 模型和 API 密钥管理。
• 安全标头 -- 常见框架（React、Next.js、Express）的 CSP 配置、HSTS 设置和安全标头测试。
• 漏洞模式 -- Node.js、Python 和 Go 的 OWASP Top 10 代码示例（易受攻击版本和修复版本），以及自动化测试模式。
• 事件响应 -- 事件响应操作手册、严重程度分类、沟通模板、事后分析模板和根因分析框架。
• 合规检查清单 -- SOC 2、GDPR、HIPAA 和 PCI-DSS 实施检查清单及证据收集指南。