security-best-practices 适合明确要求的安全审查或安全默认实现。它先辨认项目的语言、前后端框架，再读取对应参考规则，避免拿一份不分技术栈的检查表套所有项目。已有代码可以产出带位置和优先级的报告，新功能也可以在实现前约定安全要求。
安装与准备
本文介绍 openai/skills 保留的独立 Skill 版本。该仓库已弃用，当前官方示例转至 openai/plugins；这里的步骤对应本页链接的旧仓库版本，不代表最新插件。
在 Codex 对话框输入下面这一行；它不是终端命令。安装后若找不到该 Skill，重启 Codex 再试。
$skill-installer security-best-practices
- 可读取的项目代码与框架依赖信息
- 明确的安全审查范围和实际部署背景
- 该独立版本主要支持 Python、JavaScript/TypeScript 和 Go
第一次怎么用
先挑一个明确范围，例如登录与上传：
$security-best-practices
对当前项目做安全最佳实践审查，范围是登录、会话和文件上传。先确认前后端技术栈及部署假设，再读取适用规则。将有代码依据的问题按严重性整理到 security_best_practices_report.md，包含文件行号、影响和修复方向。先报告，不改代码；没有证据的风险写成待确认问题。
接下来怎样推进
-
确定适用规则。 让 Codex 列出从代码和依赖文件识别的语言、框架，前后端都要覆盖；没有对应参考时说明缺口。
-
写出可定位的问题。 每项指出具体文件、行号和影响，区别已经存在的缺陷与只在某种部署方式下成立的假设。
-
逐项安排修复。 阅读报告后选择优先项；修改时考虑原有行为，补充能验证相关风险的检查，再回顾残余问题。
怎样复核一条安全发现
从报告中挑一条高风险发现，沿“外部入口 → 相关代码 → 已有校验 → 敏感操作”的路径检查。报告要说明攻击者需要的权限、部署条件和可能影响；只有代码位置而没有成立条件，仍不足以决定优先级。缺少线上配置时把风险写成条件性判断，再向负责部署的人确认。修复后除了验证攻击路径被阻断，也要检查正常角色仍能完成原流程。
不要混淆报告与安全结论
“未发现”只表示在本次范围和可见代码里没有发现，不能当作漏洞不存在。第三方服务、运行配置、密钥管理和实际网络边界可能不在仓库中。修复后检查功能是否仍按原权限运行，同时记录未验证的外部条件；独立代码审查不等于渗透测试或合规认证。
另一个场景：同时有前端和后端
一个公开文件分享应用可能前端使用 TypeScript，后端使用 Go。可以输入：“检查分享链接创建和下载两条路径，先确认前后端框架，再分别读取 Skill 中匹配的安全参考。报告只写代码能定位的发现，每项给编号、严重程度、文件行号、触发条件和修复建议；不要把本地开发未开启 TLS 单独判成线上漏洞。” 这能检验 Agent 是否遗漏某一层，也让报告可以逐项复核。该独立 Skill 的报告通常写入 security_best_practices_report.md；验收时抽查高风险项是否真能从入口追到敏感操作，修复时一次处理一项并跑相关测试。
交付后先检查什么
打开报告后，先看最高优先级发现能否定位到实际代码，并确认部署前提与你的系统一致。安全报告需要解释影响，不能只给一个风险标签；修复后也应说明实际验证范围，而不是宣称整个系统绝对安全。
保留语言参考，逐项复核
开始审查时先限定语言和关键入口，例如“只检查 Node API 中的鉴权与输入处理”。安装时保留 Skill 的完整目录，别只复制 SKILL.md：语言参考资料也会影响检查内容。收到发现后，打开涉及代码确认数据是否真能到达敏感操作，再用测试或最小复现实验区分真实风险与泛化建议。
常见卡点
项目语言不在范围内。 改用该语言或框架的专项审查资料，不把此 Skill 的覆盖范围扩大。
建议会破坏业务行为。 让它解释冲突和迁移方案，记录有理由保留的例外。
报告太泛。 要求每项附代码位置与成立条件，删掉无法关联项目的通用条目。