security-devsecops

安全 / DevSecOps

此技能涵盖安全编码实践、依赖项与机密信息管理、身份验证与授权，以及安全软件开发生命周期（SSDLC）中应包含的安全工具——从本地编码习惯到 CI/CD 门禁，再到生产环境监控。

安全地添加新功能的工作流

1. 识别信任边界 — 标出新代码接受用户、其他服务或文件输入的所有位置，以及输出内容（HTML、日志、其他服务）的所有位置。
2. 在边界处验证和清理 — 在入口处验证所有不可信输入；根据输出目标上下文（HTML、JS、SQL、shell）对输出进行转义。
3. 使用现有安全机制 — 优先使用项目既有的身份验证框架、ORM 和机密信息管理方案，而不是另行编写。
4. 确保机密信息不进入代码和日志 — 从环境变量或机密信息保管库读取凭据；确认敏感信息不会进入日志或错误消息。
5. 推送前运行本地安全检查 — 在可用时运行 lint、SAST 和机密信息扫描工具（gitleaks、semgrep、npm audit、pip-audit 等）。
6. 让 CI 门禁运行 — 每个 PR 都应运行 SAST、SCA、机密信息扫描和 IaC 扫描；将失败视为阻断条件，而不是可以忽略的建议。
7. 记录与安全相关的决策 — 在 PR 描述中注明任何身份验证 / 授权变更、新增依赖项，或偏离默认安全模式的情况，以便日后审计。

通用安全原则

• 切勿在源代码中硬编码机密信息、凭据或 API 密钥。敏感数据应使用环境变量或安全保管库（例如 AWS Secrets Manager、HashiCorp Vault、Doppler）。
• 切勿将 .env 文件、机密配置文件或无法识别的令牌提交到源代码管理中。应在暂存之前将它们添加到 .gitignore。
• 切勿在应用日志中记录敏感数据、机密信息或会话令牌——应在记录时脱敏或省略，而不是事后处理。
• 在用户输入进入系统时对其进行验证和清理。根据上下文对输出进行适当转义：对 HTML 进行 HTML 编码，对内联脚本进行 JS 编码，对 SQL 使用参数化查询。
• 避免使用不安全的动态执行函数，例如 exec、eval、Function()、对不可信数据使用 pickle.loads，或将用户输入插入 shell 命令。

# Unsafe — string interpolation into a query
query = f"SELECT * FROM users WHERE email = '{email}'"
cursor.execute(query)

# Safe — parameterized query
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

机密信息处理

• 从环境变量（process.env.API_KEY、os.environ["API_KEY"]）或保管库客户端加载机密信息，绝不将其写成字面值。
• 轮换任何曾提交到版本控制中的凭据，即使后来删除了相关提交也不例外——历史记录仍会保留它。
• 在合并前使用 gitleaks、trufflehog 或 CI 提供商内置的机密信息扫描功能等工具，扫描是否意外提交了机密信息。
• 严格限定凭据的权限范围：CI 部署密钥应只能执行部署，而不能管理整个云账户。

数据库安全

• 所有数据库访问都应使用参数化查询或 ORM。切勿通过字符串拼接或使用含用户输入的 f-string 构造查询。
• 确保数据库用户仅拥有其角色所需的最低权限（报表服务不应拥有 DROP TABLE 权限）。
• 随着团队成员和服务职责的变化，定期审查并更新数据库访问策略。

依赖项管理

• 只添加来自经过验证、信誉良好的来源的包——添加新依赖项前，检查其下载量、维护活跃度和已知 CVE 记录。
• 未经明确批准和简要安全审查，不要添加新依赖项，尤其是会以提升的权限运行或处理不可信输入的包。
• 定期更新依赖项，并使用 Software Composition Analysis（SCA）工具扫描已知漏洞，例如 npm audit、pip-audit、Dependabot、Snyk 或 Trivy。

# Node.js
npm audit --audit-level=high

# Python
pip-audit

# Container image
trivy image myapp:latest

身份验证与授权

• 使用成熟且经过审计的身份验证框架（例如 Auth0、Passport、Devise、ASP.NET Identity）——切勿从头实现自定义加密身份验证。
• 使用强盐值和自适应哈希存储密码：Argon2id 或 bcrypt，切勿使用 MD5、SHA1 或无盐 SHA256。
• 对敏感操作实施基于角色的访问控制（RBAC），或采用更精细的基于属性的访问控制。
• 对 API 端点和 UI 操作都要遵循最小权限原则：在服务端检查每个请求的授权，绝不能将隐藏的 UI 元素视为访问控制机制。
• 即使先前已允许某项操作，也要对每个请求重新检查授权——会话状态和角色可能在会话期间发生变化。

// Missing authorization check — any authenticated user can access any order
app.get("/orders/:id", requireAuth, async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order);
});

// Correct — verify the resource belongs to the requester
app.get("/orders/:id", requireAuth, async (req, res) => {
  const order = await Order.findById(req.params.id);
  if (!order || order.userId !== req.user.id) {
    return res.status(404).end();
  }
  res.json(order);
});

安全 SDLC 实践

将以下实践集成到 CI/CD 流水线中，而不是作为手动的发布前检查清单：

• SAST（静态应用安全测试）——在每个 PR 中扫描源代码，查找已知的不良模式（例如 Semgrep、CodeQL、SonarQube）。
• SCA（软件成分分析）——扫描依赖项中的已知漏洞和许可证问题（例如 Snyk、Dependabot、OWASP Dependency-Check）。
• 机密扫描——在合并前扫描每次提交和 PR 差异，查找意外提交的凭据（例如 Gitleaks、GitHub secret scanning、TruffleHog）。
• IaC 扫描——在应用前扫描 Terraform/CloudFormation/Kubernetes 清单中的错误配置（例如 Checkov、tfsec、Trivy config scan）。
• DAST（动态应用安全测试）——在 CD 流水线中扫描已部署应用的运行实例，查找可被利用的行为（例如 OWASP ZAP、Burp Suite）。
• 策略即代码（PaC）——将安全和合规策略编写为受版本控制且自动执行的规则（例如 OPA/Rego、Sentinel），而不是放在无人重读的文档中。

监控与反馈

• 启用持续漏洞监控，并针对依赖项和运行中的基础设施配置警报。
• 根据部署目标和流量特征，在适用时集成运行时应用自我保护（RASP）和 Web 应用防火墙（WAF）。
• 定期安排漏洞评估和渗透测试，而不仅仅是在重大版本发布前进行一次性审计。
• 建立反馈闭环：在生产环境或渗透测试中反复发现的漏洞类型，应促使更新 lint 规则、SAST 策略和代码审查清单，而不只是修补一次。

合规与文档

• 根据项目的监管背景，采用公认的行业标准制定控制措施：OWASP Top 10、OWASP ASVS、NIST SSDF、ISO 27001。
• 在做出安全决策时记录控制措施和决策（威胁模型说明、批准例外的原因、用于抵消已知风险的补偿性控制），以便之后能够审计决策依据，而不是在审计期间凭记忆还原。

需要关注的常见漏洞类型

类型	关注点
注入（SQL/NoSQL/命令）	使用用户输入拼接构建查询或 shell 命令
访问控制失效	缺少逐请求授权检查、通过可预测 ID 进行 IDOR 攻击
加密失效	弱哈希、硬编码密钥、缺少 TLS、自定义加密
不安全的反序列化	pickle、在可执行上下文中未经检查就调用 JSON.parse、不安全的 YAML 加载器
安全配置错误	默认凭据、生产环境中详细的错误页面、过于宽松的 CORS
易受攻击的依赖项	含有已知 CVE 的过期软件包、未固定的版本
日志记录不足	身份验证事件没有审计跟踪、以明文记录敏感数据