secure-code-review

用途

secure-code-review 用于对源代码执行结构化的安全审查。它围绕 10 个安全领域逐项检查，将发现的问题映射到 CWE 标识和严重级别，并输出带修复指导与概念验证说明的报告。该技能定位为手动安全审查，补充但不替代自动化 SAST/DAST 工具。

主要能力

审查覆盖以下 10 个领域：

输入验证
认证与会话管理
授权与访问控制
注入防护
密码学
错误处理与日志
数据保护
依赖安全
配置安全
竞态条件

每个检查项标记为通过（[x]）、失败/发现（[ ]）或不适用（[-]）。每个失败项生成一条发现记录，包含文件、行号、CWE、影响、PoC 与修复建议，并分配 CRITICAL / HIGH / MEDIUM / LOW / INFO 严重级别。最终报告包含发现数量汇总表、正面观察与建议部分。

使用方式

前置条件

无需外部工具（基于清单，需配合源代码访问）
对受审源代码的读取权限
可选：Semgrep、CodeQL、Bandit 等静态分析工具的输出，用于补充手动审查
CWE 参考：https://cwe.mitre.org

输入项

项目	说明	示例
REPO_PATH	受审源代码路径	/src/api/
LANGUAGE	代码库主要语言	Python, TypeScript, Go
REVIEW_SCOPE	要审查的文件、模块或 PR diff	auth/, payments/handler.py, PR #342
APP_TYPE	应用类型	web-api / cli / library / mobile
DATA_SENSITIVITY	处理的最高数据分级	PII / PCI / internal / public

工作流程

步骤 1：定义审查范围。 在开始清单前限定审查边界，避免范围蔓延。记录仓库/路径、语言、审查文件、审查日期、审查者、审查总行数。优先审查顺序为：认证与授权代码、外部输入处理（HTTP 请求解析、文件上传、反序列化）、数据库访问与查询构造、密码学操作、配置加载与密钥处理，最后是范围内其余文件。

步骤 2：应用 10 领域安全检查清单。 系统性地逐领域检查，标记每项为通过、失败或不适用。每个失败项在步骤 3 中创建发现记录。完整清单、CWE 参考、严重级别分类表与发现详情示例见 REFERENCE.md。

步骤 3：按严重级别分类发现。 严重级别分类表（CRITICAL/HIGH/MEDIUM/LOW/INFO 及标准与示例）见 REFERENCE.md。

步骤 4：生成报告。 使用模板输出最终报告，包含系统/PR、审查文件数、审查日期、审查者，以及按严重级别统计的发现数量表。发现详情示例与正面观察/建议模板见 REFERENCE.md。

完成标准

对定义的审查范围完成全部 10 个领域
每个清单失败项都有对应的发现记录，含文件、行号、CWE、影响、PoC 与修复建议
所有发现均分配严重级别
汇总表准确反映发现数量
正面观察与建议部分完整
报告已保存或交付给请求团队

适用场景

对安全敏感代码变更（认证、支付、文件处理、密码学）进行 PR 审查时
生产发布前验证安全控制是否到位
接手无安全审查历史的遗留代码库时
漏洞赏金报告或漏洞披露涉及代码级缺陷、需要根因分析时

限制与注意事项

该技能用于手动安全审查，补充但不替代自动化 SAST/DAST 工具。
依赖相关发现应使用 dependency-audit 技能获取详细 CVE 数据与升级路径。
标记为 CRITICAL 的发现应阻止合并或部署，直至修复；HIGH 发现应在下一版本发布前解决，除非有记录在案、有时间限制的例外获批。
CWE ID 提供稳定参考，可映射到 NVD/CVE 数据、OWASP 指南及许多 SAST 工具输出，与开发团队共享发现时应始终包含。
审查认证或密码学代码时，建议安排第二位审查者，这些领域对细微错误的后果最严重。

失败模式

问题	原因	解决方案
审查范围过大，无法一次完成	大型代码库或 PR	优先处理领域 1–5（风险最高），其余领域安排后续跟进
CWE 映射不清晰	不熟悉 CWE 分类法	用漏洞关键词搜索 https://cwe.mitre.org；无精确匹配时使用最接近的父级 CWE
发现严重级别难以校准	可利用性不明确	存疑时默认采用较高严重级别，并在发现中记录不确定性
静态分析工具误报过多	规则集过于宽泛	调整规则集；用人工审查确认或排除每个标记项
源代码不可用（黑盒场景）	审查编译或混淆后的产物	改用 owasp-check 技能进行行为测试，并在报告中注明该限制