SecureAI-Scan

离线 CLI 工具，用于扫描 TypeScript、JavaScript 和 Python 中的 LLM、MCP、Agent Skill 及 RAG 风险——基于 import 解析的数据流证据，默认零误报，并映射至 OWASP LLM/ASI/MCP Top 10。

该领域的多数扫描器只是匹配关键词便将其视为发现项。SecureAI-Scan 则通过真实、经 import 解析的代码，追踪实际的 来源 → 流向 → 汇点 路径——默认扫描仅展示其能够证明的内容。无需账户、无需云端上传，一切都不会离开你的机器。

覆盖官方 OWASP Top 10 for LLM Applications 2026、Top 10 for Agentic Applications (2026) 以及发布周即纳入的 MCP Top 10。

30 秒快速上手```bash

npx --yes [email protected] scan .

无需账户、云上传、Python 解释器或配置。TypeScript、JavaScript、Python、MCP 配置和 Agent Skill 包会自动检测。

**实测 `0.9.0` 候选版本：** 136/136 项测试 · 88.08% 语句覆盖率 · 覆盖 9 个公共仓库中的 12,676 个文件 · 与已审查基线相比，0 个新增默认层级指纹。[证据](https://github.com/akanthed/secureai-scan/blob/main/docs/benchmarks/v0.9.0.json) · [方法论与限制](https://github.com/akanthed/secureai-scan/blob/main/docs/ReleaseAssurance.md)```
  ▌ HIGH  AI001  Prompt injection via user input
    PROVEN  LLM01:2026 Prompt Injection

    source src/chat.ts:8   request data `req.body.input`
    flow   src/chat.ts:13  passed as `systemPrompt`
    sink   src/chat.ts:10  openai.chat.completions.create — system role (OpenAI)

    fix    Keep system prompts static; pass user input as a user-role message.

这适合你吗？ SecureAI-Scan 刻意将范围限定在 LLM、MCP 和 RAG/代理风险——提示注入、工具投毒、不安全的输出处理、向量存储访问控制、代理技能投毒。它不是通用的 SAST 或密钥扫描器，也不试图成为其中之一；一个已知的恶意包如果没有 LLM 形态的载荷（例如电子邮件 API 调用中硬编码的泄露地址），会由离线公告列表（DEP003）捕获，而不是由模式规则捕获。如果你的代码库与 LLM、MCP 服务器、向量存储通信，或附带 Agent Skills，这就是为你构建的。

_{新增：针对 LiteLLM Proxy（config.yaml）的静态配置扫描——硬编码密钥、明文提供商端点、缺失护栏。参见 规则（LLC001–LLC003）。}

目录

• 为什么这个扫描器与众不同
• 它如何比较
• 30 秒快速上手
• 查看实际效果
• 命令
• GitHub Action
• Pre-commit 钩子
• 规则
• 架构
• MCP 服务器（从 Claude 使用）
• Claude 技能
• 信任与发布保障
• 精度契约
• 测试与基准测试
• 路线图
• 贡献

为什么这个扫描器与众不同

• 证据分级，而非噪音。 每个发现都是 proven（追踪数据流或解析的配置事实）、likely（已解析的接收器，一次启发式跳跃）或 heuristic。默认扫描仅显示 proven + likely。 启发式结果通过 --paranoid 选择启用。
• 导入解析的检测。 只有当调用解析到真实的 SDK 导入（openai、@anthropic-ai/sdk、ai、@google/genai、LangChain、Bedrock 等）时，它才是“LLM 调用”。你的 Google Maps 客户端永远不会再被标记为 LLM。
• 精度门控，并针对真实仓库进行基准测试。 测试套件断言每个易受攻击的测试夹具都会触发并且每个安全的测试夹具保持干净——安全语料库上的误报会导致构建失败。除此之外，npm run regression 会扫描真实的公共仓库（OpenAI/Anthropic/Vercel AI SDK、官方 MCP 服务器、LlamaIndex），对照已提交且经人工审查的基线，并且在任何新的 proven/likely 发现上失败。参见 测试与基准测试 了解实际的对比数字，或参见 扫描真实仓库的发现 了解背后的故事——在标记的恶意技能语料库上 6/6 的捕获率，以及为什么我们不因为一个诚实的库级发现而称 llama_index 为“易受攻击”。

它如何比较

SecureAI-Scan 不是通用 SAST 工具或容器/IaC 扫描器的替代品——请与它并行运行，而不是替代它。它是为 LLM/MCP/RAG 攻击面专门构建的，强调数据流证据而非扁平的关键词发现。

如果你已经在运行 Semgrep 或 GHAS，请保留它们——为它们完全未建模的风险面添加 SecureAI-Scan。

想先提问？试试免费的 SecureAI-Scan AI 安全顾问（ChatGPT 版）。

即将运行你在 GitHub 或 Twitter 上找到的 MCP 服务器？先将它的工具描述粘贴到 MCP X-Ray——在浏览器中检查隐藏的 Unicode、注入指令和已知恶意包，无需安装。

查看实际效果

secureai-scan scan . 端到端运行，针对一个真实（小型、故意易受攻击的）文件的真实输出——源代码：

扫描器端到端追踪的攻击形态：

MCP 工具投毒数据流	RAG 上下文注入数据流

命令

你 95% 的时间需要的那个：```bash secureai-scan scan .

其他内容在你需要时都会显示。`secureai-scan scan . --help` 会在终端中显示所有这些选项，并按相同方式分组：

**日常使用**

| 标志 | 作用 |
|------|---------------|
| *(无)* | `proven` + `likely` 级别的发现——默认选项，无需任何标志 |
| `--paranoid` | 同时包含 `heuristic` 级别的发现 |
| `-s, --severity <level>` | 仅显示达到/高于 `low`\|`medium`\|`high`\|`critical` 级别的发现 |
| `--output <file>` | 写入完整报告——`.sarif`（GitHub 代码扫描）、`.json`、`.md` 或 `.html` |

**限定运行哪些规则**

| 标志 | 作用 |
|------|---------------|
| `-r, --rules <list>` | 仅运行这些规则 ID，例如 `AI001,MCP007` |
| `--only-ai` / `--only-mcp` / `--only-vec` / `--only-skl` | 仅运行一个规则类别 |
| `--check-dependencies` | 同时将 `package.json`/`requirements.txt` 与 npm/PyPI 注册表比对，检查拼写错误和幻觉包（`DEP001`/`DEP002`）。如果你通过 `-r` 直接选择这些规则，会自动启用——你无需记得同时传递两者。`DEP003`（已知恶意包）不需要此选项，它始终离线运行 |

**CI / 工作流**

| 标志 | 作用 |
|------|---------------|
| `--fail-on <severity>` | 如果存在达到/高于此严重级别的发现，则退出并返回 `1` |
| `--baseline <file>` | 对照已保存的基线，仅跟踪新增/变更的问题 |
| `--policy <file>` | 从 `.secureai-policy.json` 加载阈值、跳过的路径和被阻止的规则（若存在则自动检测——`secureai-scan init` 会创建一个） |

**高级**

| 标志 | 作用 |
|------|---------------|
| `--min-confidence <0-1>` | 比 `--paranoid` 更精细：隐藏低于精确置信度分数的发现（`0.9` proven / `0.65` likely / `0.35` heuristic） |
| `--limit <n>` | 终端中显示的最大规则组数（默认 `10`）——完整详情始终写入 `--output` |
| `--debug` | 打印每个扫描的文件以及运行了哪些规则 |

**安装前先扫描——无需克隆，无需配置：**```bash
secureai-scan skill anthropics/skills          # a GitHub "owner/repo" shorthand
secureai-scan skill https://github.com/…       # or a full git URL
secureai-scan skill ./some/local/skill-dir     # or a local path
secureai-scan mcp some-mcp-server-package      # a bare npm package name
secureai-scan mcp owner/mcp-server-repo        # or git, same as `skill`

skill 和 mcp 会获取目标并对其进行扫描，然后删除获取到的副本（使用 --keep 可改为检查它）。获取到的任何内容都不会被执行：npm 目标通过 npm pack 下载——仅下载 tarball，不执行 install，也不运行生命周期脚本——而 git 目标只是普通的 git clone --depth 1。这是最关键的时机：在技能落入 ~/.claude/skills/ 或服务器落入 .mcp.json 之前，而不是之后。

其他命令：```bash secureai-scan bom . --output AI_BOM.md # AI Bill of Materials secureai-scan explain AI001 # why + exploit + fix example, for any rule secureai-scan threat-model . # THREAT_MODEL.md with the OWASP coverage matrix — example: docs/examples/THREAT_MODEL.example.md secureai-scan init # policy file + CI workflow, one-time setup

抑制代码中已审阅的发现：```ts
// secureai-ignore AI001: reviewed, input sanitized via allowlist

GitHub Action```yaml

name: SecureAI-Scan on: [pull_request] permissions: contents: read security-events: write jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: akanthed/[email protected] with: scanner-version: 0.10.0 fail-on: high

发现结果会以内联注释的形式显示在 PR 上，同时也会出现在仓库的 Security 标签页中。（`secureai-scan init` 会直接使用 CLI 生成一个等效的工作流。）

扫描结果干净？将徽章添加到您自己的 README 中：```md
[![secureai-scan](https://img.shields.io/badge/secureai--scan-passing-brightgreen)](https://github.com/akanthed/SecureAI-Scan)

Pre-commit 钩子

更倾向于在推送前捕获发现结果？将此仓库添加为 pre-commit 钩子源，以替代或配合 GitHub Action 使用：```yaml repos:

• repo: https://github.com/akanthed/SecureAI-Scan rev: v0.10.0 hooks:
  • id: secureai-scan

钩子会在每次提交时扫描整个项目（而不仅仅是变更的文件——因为对文件 A 的数据流追踪可能依赖于文件 B，而部分扫描会遗漏这一点），并默认在发现 `high` 及以上严重级别的问题时阻止提交。你可以在自己的配置中覆盖该阈值：```yaml
      - id: secureai-scan
        args: ["--fail-on", "critical"]

规则

42 条规则，映射到官方 OWASP LLM 应用 Top 10（2026）——此外，在适用情况下，还映射到 OWASP 智能体应用 Top 10（2026，ASI）、OWASP MCP Top 10（2025）以及欧盟《人工智能法案》条款。参见带版本号的 2026 覆盖范围与限制；threat-model 会为每个扫描的项目渲染该矩阵。

secureai-scan explain <RULE_ID> 提供任何规则的漏洞利用演练以及前后代码示例。

架构

三个独立的扫描面汇入一个合并、去重的发现列表：``` ┌─────────────────────┐ *.ts / *.js ───▶ │ ts-morph AST rules │───┐ │ (import-resolved │ │ │ sinks + dataflow) │ │ └─────────────────────┘ │ │ ┌─────────────────────┐ │ ┌──────────────┐ ┌─────────────────┐ *.py ───▶ │ tree-sitter AST + │───┼───▶ │ scan.ts │───▶ │ evidence filter │ │ local taint flow │ │ │ merge/dedupe│ │ → confidence │ └─────────────────────┘ │ │ + suppress │ │ → severity │ │ │ (// secure- │ │ → baseline diff │ .mcp.json, ┌─────────────────────┐ │ │ ai-ignore) │ │ → report │ SKILL.md ───▶ │ Config/bundle scan │──┘ └──────────────┘ └─────────────────┘ │ (off-disk, evasion- │ │ │ resistant) │ ▼ └─────────────────────┘ terminal · sarif · json · md · html

package.json, requirements.txt ─▶ dependency-guard.ts (advisories.ts, offline, version-aware)

每条 AST 规则只有在通过真实导入解析到已知 SDK 时，才会将函数称为“LLM 调用”——绝不会仅凭名称匹配。有关每个表面的完整细分，请参阅 [`docs/Architecture.md`](https://github.com/akanthed/secureai-scan/blob/main/docs/Architecture.md)；有关证据层级契约的运作方式，请参阅 [`docs/DetectionEngine.md`](https://github.com/akanthed/secureai-scan/blob/main/docs/DetectionEngine.md)。

## MCP 服务器（从 Claude 使用）

该包附带一个 MCP 服务器，暴露了 `scan_repository`、`explain_rule`、`generate_bom` 和 `scan_untrusted_target`（在 Claude 推荐安装某个技能或 MCP 服务器之前，先获取并扫描它——与 `skill`/`mcp` CLI 命令相同的“获取但不执行”行为）：```json
{
  "mcpServers": {
    "secureai-scan": {
      "command": "node",
      "args": ["/path/to/secureai-scan/mcp-server/index.js"]
    }
  }
}

Claude 技能

对于 Claude Code / Claude.ai 用户，skills/secureai-scan/SKILL.md 会教 Claude 何时运行扫描（审查 AI/LLM 代码，或在安装 MCP 服务器/Agent 技能前进行检查）以及如何解读结果——与上述 MCP 服务器不同，无需单独运行进程。将 skills/secureai-scan/ 目录复制到你的 .claude/skills/ 中即可使用。

规避抵抗

2026 年 7 月，两项公开研究显示 Agent 技能扫描器可被轻易绕过。

Cloak and Detonate（Ji、Xu、Li、Gao、Wei、Wang 与 Cheung——香港科技大学，arXiv:2607.02357）针对 九款 已发布的技能扫描器，使用 1,613 个野外恶意技能进行了对抗性研究。两个攻击家族均能完全保留载荷：

• Reify —— 重写规则所匹配的字节，而 agent 在运行时仍会重新组装原始内容。对大多数静态扫描器的绕过率 >80%。
• Disperse / SFS 打包 —— 将载荷移出规则作用域：放入扫描器跳过的目录、改用重命名的扩展名，或归档并编码进 .git/ 中，并附带一个良性的掩护 SKILL.md，在首次运行时重建载荷。在每款被测扫描器上绕过率 ≥90%，多数扫描器上 ≥96%。一款混合扫描器的检测率从约 99% 跌至约 10%。

另外，Gecko Security（VentureBeat）将载荷放在 *.test.ts 文件中。所有公开扫描器都跳过了它——但 Jest 和 Vitest 会在下一次 npm test 时自动发现并执行这些文件。

SecureAI-Scan 可处理每项已公开的技术。下表中的每一行在 test/deobfuscate.test.js 中都有对应的测试，或在 test-fixtures/vulnerable/skills/ 中有对应的测试夹具：

这并不会削弱精确性契约

反混淆通常是精确性风险——匹配越多，噪音越多。这里的逻辑是相反的：仅在反混淆后才出现的匹配会被提升为 proven，而非降级。 普通文档不会在 "ignore previous instructions" 中包含零宽连接符，也不会在 curl 中包含西里尔字母 с。隐藏行为本身就是意图的肯定性证据。

比较对象是原始匹配的集合，而不仅仅是"原始文本是否匹配"——否则攻击者可以通过保留一句无害短语来掩盖信号。

两条新的包级规则仅在合取条件下触发，绝不会因单个关键词触发：

• SKL004 需要不透明数据块以及一条按名称引用该数据块的解包指令——README 中在无关的二进制资产旁提到 tar -x 并不足够。真正的归档文件（gzip/zip/png/pdf/wasm——通过魔数而非扩展名检查）无论如何压缩，从一开始就永远不会被视为"不透明"。
• SKL005 需要具体的凭据信号——路径（~/.aws/credentials，而非 "token" 一词）或批量环境变量枚举（os.environ.items()，而非 os.environ["API_KEY"]）——以及向硬编码的非本地主机的出口流量，两者在同一文件中相距 25 行以内，或通过一次或多次重命名重新赋值后被执行的远程获取。一个发布辅助工具在一个函数中读取 ~/.npmrc、四十行后调用注册表，则保持干净；为 API 调用读取单个命名环境变量也绝不会被标记——这两种形态均被固定为安全夹具。

不仅针对我们自己编写的夹具，还针对两个真实世界语料库进行了验证：在 anthropics/skills 的全部 18 个真实技能包以及 vercel/ai 的全部 14 个中零发现，并且在 cisco-ai-defense/skill-scanner 的带标签评估语料库（20 个技能，每个都有 _expected.json 判定）上6/6 全部正确，对所有标记为安全的项目零误报。参见 测试与基准测试。

这不是什么

诚实的局限：论文的结论是运行时引爆优于静态分析，这是正确的。了解这些规则的适应性攻击者可以编写出它们未覆盖的变换。这里改变的是规避的成本——已公开、当前流传的技术不再有效，而击败它们所需的混淆本身现在会提高发现的严重性。静态扫描是过滤器，而非安全边界。 无论任何扫描器怎么说，都要将不受信任的技能视为不受信任的代码。

信任与发布保障

• CI 在 Linux、Windows 和 macOS 上跨受支持的 Node 版本运行。
• CodeQL、生产依赖审计、OpenSSF Scorecard、Dependabot 以及本扫描器自身的阻断式自扫描提供独立检查。
• 每次手动 npm 发布都会通过 prepublishOnly 触发测试、覆盖率下限、经审查的真实仓库回归门禁以及 tarball 检查。
• GitHub Actions 不会收到 npm 密码或令牌，也无法发布该包。
• 发布保障、单一维护者治理、安全报告 以及带版本号的基准测试证据均为公开内容。

这是一个单一维护者项目，没有合同 SLA 或独立认证。上述控制措施降低了风险；它们不会将静态扫描变成安全性的证明。

精确性契约

误报会毁掉扫描器。SecureAI-Scan 的规则引擎遵循三条硬性规则：

1. Sink 通过导入解析。 如果某个标识符解析到非 LLM SDK 的模块，则它绝对不是 LLM 调用——无论其名称是什么。
2. 证据被标记，绝不混合。 追踪到的数据流与词邻近匹配不是一回事，因此它们永远不会共享层级。
3. 安全语料库为每次发布把关。 test-fixtures/safe/ 包含曾经导致误报的模式（脱敏的 PII 载荷、Google Maps 客户端、LLM 客户端旁的环境变量 API 密钥、普通响应日志、OAuth 元数据字段、流式响应的 chunks、虚构/叙事提示文本）。其中任何发现都会导致测试套件失败。

测试与基准测试

三层测试，因为仅靠一层不足以信任扫描器的声明——精确率和召回率是不同类型的失败模式，两者都会被检查。

1. 夹具语料库——精确率 + 召回率，每次构建时运行。```bash npm test

[`test-fixtures/vulnerable/`](https://github.com/akanthed/secureai-scan/blob/main/test-fixtures/vulnerable) 和 [`test-fixtures/safe/`](https://github.com/akanthed/secureai-scan/blob/main/test-fixtures/safe) 会一起被扫描：每个易受攻击的测试固件都必须在其预期规则上触发 `proven`/`likely` 级别的证据（召回率），每个安全的测试固件都必须产生**零**条 `proven`/`likely` 级别的发现（精确率）。快速且确定性高——但这只能证明扫描器在专门为测试它而编写的代码上表现正常。

**2. 真实世界回归基准——针对我们未编写的公共仓库。**```bash
npm run regression                          # scan the full curated repo set
npm run regression -- --fresh               # re-clone everything first
npm run regression -- openai-node           # scan just one repo by name
npm run regression -- --update-baseline     # accept the current findings

scripts/regression-scan.js 克隆一组经过精选、多样化的真实公共仓库（OpenAI/Anthropic/Vercel AI SDK、官方 MCP 服务器和 TypeScript SDK、LlamaIndex，外加 anthropics/skills 和 cisco-ai-defense/skill-scanner 以覆盖技能包——涵盖 TS 和 Python、SDK 消费者示例代码以及 SDK 作者源码），并使用构建好的 CLI 对每个仓库进行扫描。

只要出现任何不在 test/regression-baseline.json 中的 proven/likely 发现，它就会以非零状态退出——该基线文件是一份经人工审查的记录，其中每条发现都已对照其源码行进行过核实。指纹采用 repo|rule|file 格式而非行号，因此上游的常规变动不会产生噪音。新的指纹意味着扫描器必须给出合理解释：如果它不是真正的问题，那就是规则缺陷，需从根源修复，并作为新的 test-fixtures/safe/ 夹具锁定。将未经阅读的发现加入基线会破坏整个机制。

技能包覆盖有单独的检验标准，因为 cisco-ai-defense/skill-scanner 的 evals/ 语料库带有标签——其 20 个夹具中的每一个都附带 _expected.json 判定结果，并位于字面命名为 malicious/ 或 safe/ 的目录下，因此它同时充当召回率检查，而不仅仅是精确率检查：6/6 个范围内的恶意夹具均触发，任何标记为 safe 的内容均零发现，并且 anthropics/skills 中全部 18 个真实包和 vercel/ai 中全部 14 个包均零发现。（其余 Cisco 类别——SQL 注入、路径遍历、资源耗尽、对函数参数的通用 eval()、故意跨四个文件拆分的载荷——要么超出文档所述的 LLM/MCP/RAG 范围，要么超出同文件合取分析的能力；具体推理见 0.6.0 变更日志条目。）

来自推动原始精确率修复的那次运行的历史前后对比（默认证据级别下的发现，未使用 --paranoid）：

当前运行（2026-08-06）——带版本号的证据记录在 docs/benchmarks/v0.9.0.json 中：

vercel/ai 的分诊发现了三个真实的、已定位根因的缺陷——均非 v0.6.0 技能规则所特有，全部位于许多规则共用的共享逻辑中：

1. resolveLlmSink 将任何解析到 LLM SDK 模块的调用都视为模型调用，无论方法名是什么——导致 isToolUIPart（ai 包与 generateText 一同导出的一个类型守卫）被标记为 LLM 调用。仅此一项就造成了 5 个发现组中的 3 个（AI001、AI003、AI010）。
2. AI005 中的 DANGEROUS_CALLEES 为 SQL 注入类接收器包含 "query"，但 "query" 同时也是合法的 LLM/代理调用动词——claudeSdk.query({ prompt, options })（Claude Agent SDK 自身的模型调用）仅因共享的方法名就被标记为"LLM 输出传入危险接收器"。
3. REQUEST_SOURCES（在 MCP002、MCP010、VEC003 中完全相同地重复）匹配了裸的 "params."——任何按惯例命名为 params 的函数参数都会被匹配，而不一定是 HTTP 请求数据。一个 URL 方案验证器（assertOpenLinkParams(params: unknown)）被标记为"MCP 服务器 URL 来自用户输入"。

三个缺陷均从根源修复（而非针对特定调用点），并作为永久夹具固定在 test-fixtures/ 下。完整细节见 CHANGELOG.md。

3. 易受攻击版本与已修补版本验证——证明召回率，而不仅仅是精确率。

上述两层只检查扫描器在安全代码上保持安静。DEP003 的公告检查则从另一个方向验证：将包固定到文档记载的易受攻击版本并确认其被标记，然后将其固定到已修补版本并确认其不被标记。```bash node --test test/dependency-guard.test.js

covers: `[email protected]`（CVE-2025-6514，存在漏洞）被标记 / `[email protected]`（已修补）通过；`[email protected]`（后门之前）通过 / `[email protected]`（之后——恶意包不存在合法的修补版本）仍被标记；`llama-cpp-python==0.2.71`（CVE-2024-34359，来自 OSV 生成的集合）被标记 / `==0.2.72`（已修补）通过，包括在 PyPI 名称规范化（`llama_cpp_python`）下；以及 `langchain>=0.1.0` 风格的非固定版本说明符，在默认报告中产生**零**条发现。构建此测试暴露了一个真实缺口：`DEP003` 过去仅按包名匹配公告，从未真正将声明的版本与公告的受影响范围进行比较——已在 [`src/scanner/semver.ts`](https://github.com/akanthed/secureai-scan/blob/main/src/scanner/semver.ts) 中修复。

歧义的处理方式因公告类型而异，这是有意为之。**恶意**包即使在无法解析声明版本时也会触发——安装后门无法恢复，因此倾向于标记。**CVE** 仅在声明版本是精确固定版本且可证明位于受影响范围内时，才在 `proven` 级别触发；非固定但可能受影响的情况降级为 `heuristic`（仅 `--paranoid` 模式）。将恶意包规则应用于包含 162 条记录的 CVE 快照，会对每个声明 `langchain>=0.1.0` 的仓库产生一条严重发现——在大规模场景下这是无法操作的噪音。

## 路线图

已发布和计划中的内容请参阅 [`ROADMAP.md`](https://github.com/akanthed/secureai-scan/blob/main/ROADMAP.md)。两种语言引擎均基于 AST：TypeScript/JavaScript 使用 ts-morph，Python 使用 Tree-sitter。Python 的导入、调用、赋值、装饰器、作用域、关键字参数、字典字段和字符串均为语法节点；目标代码从不被导入或执行，也无需 Python 解释器。剩余的 Python 缺口是受限的跨函数/跨文件污点深度，而非解析问题。扫描性能与已知限制记录在 [`docs/Performance.md`](https://github.com/akanthed/secureai-scan/blob/main/docs/Performance.md) 中。

## 贡献

欢迎贡献——工作流程请参阅 [`CONTRIBUTING.md`](https://github.com/akanthed/secureai-scan/blob/main/CONTRIBUTING.md)，如何添加达到上述精度标准的检测规则请参阅 [`docs/WritingRules.md`](https://github.com/akanthed/secureai-scan/blob/main/docs/WritingRules.md) / [`docs/RuleDevelopment.md`](https://github.com/akanthed/secureai-scan/blob/main/docs/RuleDevelopment.md)。每条新规则都需要在 [`test-fixtures/vulnerable/`](https://github.com/akanthed/secureai-scan/blob/main/test-fixtures/vulnerable) 和 [`test-fixtures/safe/`](https://github.com/akanthed/secureai-scan/blob/main/test-fixtures/safe) 中各有一个测试夹具、在 `src/scanner/catalog.ts` 中有一条记录，以及在 `test/corpus.test.js` 中有一个用例——`npm test` 会强制执行这三项要求。

## 许可证

MIT © Akshay Kanthed