把AI代码安全要求变成可执行检查

把「不要泄露个人信息」「修改数据要记审计日志」写进提示词，能提醒 AI，却不能保证它每次都执行。作者做的 Secure & Private by Design，把这些要求变成代码规则：由 sbd 确定检查结果，AI 负责解释和建议修复。

这套方案的价值，是把安全检查接入提交和构建流程。但确定性也有边界：规则每次给出相同答案，不代表它能发现所有风险，更不代表项目已经合规。

安全要求怎样从提醒变成检查

sbd 提供 CLI、pre-commit hooks、GitHub Action 和 MCP server，四种入口共用一套规则。项目以 Apache-2.0 开源，开头宣布发布 0.2.0，文中演示实际运行的是 v0.2.1。

检查围绕 privacy-security-manifest.yaml 展开。清单记录数据分类、适用制度、保留要求和同意要求，再据此检查代码与配套文件。每条发现都有稳定规则 ID、严重程度、位置，以及对应的制度控制项。

作者在 mcp-server/test/fixtures/clinic-app 示例项目运行 sbd check，使用 schemaVersion 0.2，启用了 nist-ssdf-1.1、iso-27001-2022、dpdp-2023。共发现 17 项：2 critical、11 high、3 medium、1 low、0 info。

下面这条结果说明，它会把清单里的敏感字段分类用于代码检查：

 12. [HIGH] SBD-CODE-002 src/routes/patients.ts:19 — Log call references a field the manifest classifies as personal or sensitive.
       console.log('loaded patient', patient.email);
       → Route the value through the redacting logger in src/security/audit_log.

要看的是 patient.email：问题来自字段分类与日志调用的关联，不只是搜索 console.log。

其他规则包括：SBD-SCAF-001 检查缺失的同意模块；SBD-FIELD-001 查找未登记的数据字段；SBD-CODE-003 检查模型推理调用附近 15 行内是否有决策日志；SBD-CODE-001 检查修改数据的处理函数附近 40 行内是否有 auditLog()。

这些距离阈值是检查线索，并不能证明日志覆盖了正确的业务路径。

接入流程比再加一段提示词更关键

sbd 提供预构建文件，只需要 Node.js 20+，但尚未发布到 npm registry。原文通过 git clone --branch v0.2.1 获取仓库，再进入业务仓库，运行 node /path/to/ai-secure-by-design/dist/sbd.mjs check。

初始化与部署分成四步，便于先检查将要生成的文件：

sbd init --non-interactive --regime nist-ssdf-1.1,iso-27001-2022
sbd validate
sbd deploy --dry-run
sbd deploy

第一行决定启用哪些制度。init 生成清单草稿，但让 dataCategories 保持为空，把疑似个人信息字段写成 TODO(user): 注释，分类仍由人确认。deploy 复制清单要求的脚手架，默认保留用户修改过的文件，传入 --force 才会覆盖。

提交时可固定 rev: v0.2.1，接入 sbd-secrets、sbd-check、sbd-provenance 三个 hook。不过 git commit --no-verify 能绕过本地阻断，所以作者建议把 GitHub Action 设为必需检查。模板位于 templates/.github/workflows/secure-by-design.yml。

输出支持文本、JSON 和 SARIF 2.1.0，Action 会上传 SARIF。退出码 0 表示没有达到 --fail-on 阈值的问题，默认阈值为 high；1 表示发现问题；2 表示用法或运行错误。

让检查决定构建能否通过，规则才有持续执行的落点。

它能查到什么，又会漏掉什么

不写清单也能运行 sbd scan。作者向 stdin 输入四个假值，分别触发 AWS access key ID、PAN、印度手机号和个人邮箱规则，对应 SBD-SECRET-001、SBD-PII-002、SBD-PII-003、SBD-PII-004。报告会遮蔽匹配值，Aadhaar 使用校验和匹配，@example.com 等占位值会跳过。

这些都是代码与数据文件上的模式匹配。它不检测姓名、邮寄地址、临床自由文本，也不检查生产数据库或日志中的个人数据。没有 Node.js 时，备用 hook 脚本只覆盖 secrets。

生成的普通代码包含同意、数据权利、保留、泄露通知、儿童数据门禁、RBAC、审计日志、安全响应头、PHI 脱敏、AI 决策日志和人工监督门禁。目前覆盖 TypeScript + Express、Python + FastAPI，Next.js 仍在计划中。

制度检查只执行清单中列出的内容，包括 NIST SSDF 1.1、ISO 27001:2022 Annex A 的开发与 SDLC 范围，以及印度 DPDP Act 2023。DPDP 脚手架尚未经过法律审查。

加入 ai-security-wiki 后，还会检查模型输出流向 eval、shell、HTML、SQL，不安全模型加载、trust_remote_code、未固定版本的模型与 MCP server、通过 HTTP 连接远程 MCP、自动批准工具及关闭审批的 agent。

sbd evidence 为 Wiki 的 46 项 AI 控制规划审计证据，标记为 gap、checked 或 manual。其中 checked 仅代表自动检查没有发现问题。

我的判断

作者把规则判断与模型解释分开，这个方向成立。相比只靠提示词，固定规则更便于复现、审查和接入构建；相比单独扫描 secrets，它又增加了清单与业务代码之间的关联。

但原文展示的是示例项目和假值测试，没有误报率、漏报率，也没有与其他扫描工具的对照数据，实际效果仍需验证。仓库测试覆盖四种入口，能支持入口行为经过测试，不能证明规则覆盖充分。

另一个前提是清单准确。字段分类遗漏，相关检查就可能失去依据；15 行、40 行的邻近检查，也可能被封装或代码组织方式影响。所有内容本地运行、没有遥测和托管服务，便于控制数据流向，但不能替代团队对规则的维护。

能拿来做什么

• 对维护 Express 或 FastAPI 服务的团队，可以先用 sbd scan 检查仓库，再确认数据分类清单，逐步启用依赖清单的规则。
• 在 AI 编程流程里，可以让助手读取检查结果并提出修复建议，再运行同一套规则复查，把通过条件固定下来。
• 接入提交检查时，应同步设置必需的 CI 检查，并明确 --fail-on 阈值，避免检查只在部分开发者机器上生效。
• 评估 Next.js 项目时，应先核对可用检查范围；原文只承诺后续支持，不能直接套用 Express 脚手架。