CodeInspectus

CodeInspectus，由 Synvoya 打造

一款本地优先、保护隐私的安全 MCP 服务和命令行工具。任何 AI 编码 Agent（Claude Code、Cursor、Codex、Windsurf、Cline、Aider）都可以调用 CodeInspectus，扫描 AI 生成或“氛围编程”编写的代码，查找真实漏洞，将发现映射到合规框架，如实反映代码级覆盖情况，并推动 扫描 → 修复 → 重新扫描 循环——全程在你的计算机上完成，无需账户，且扫描时不会有任何网络流量外发。

复现 V2.1 验证案例：[email protected] 软件包会扫描不可变的公开 Rich 提交，找到一个高置信度的 GitHub Actions 表达式注入模式，在临时克隆中应用 GitHub 文档所述的中间 env 修复方案，确认结果为 已解决 1 项、剩余 0 项、新增 0 项、未重新检查 0 项，随后为修复前后的状态分别创建并验证封存证据。运行复现脚本，或阅读扫描器生成的案例研究。发布前记录的运行使用了 V2.1 的原始 tarball；发布后，脚本默认使用 npm。此案例使用 ai 扫描器类别，以单独验证稳定的原生行为；如需覆盖整个代码仓库，请执行常规完整扫描。

如果 CodeInspectus 对你有帮助，请为此仓库加星，让更多 AI 应用构建者发现它。

CodeInspectus 通过统一的 CWE 键控架构，协调三款一流的开源引擎，并加入通用扫描器容易遗漏的针对 AI 代码的专项检查：

• Opengrep — SAST / OWASP Top 10（SARIF）
• Gitleaks — 密钥
• Trivy — 依赖项 CVE（SCA）、IaC 错误配置、密钥、许可证、SBOM
• CodeInspectus Pub — 对第一方 Dart/Flutter 依赖项进行精确版本匹配，并从 pubspec.lock 生成 CycloneDX/SPDX 清单，使用随附的离线 OSV Pub 快照作为支持
• CodeInspectus native checks — 客户端密钥／捆绑包暴露、Supabase RLS／反向身份验证（CVE-2025-48757 类问题）、提示词注入接收点、 模型生成的工具参数传入 Node、Python，或受限支持的 Go、Java、C#、PHP、Rust 和 Ruby shell 接收点且没有明显防护措施， 一般模型输出传入 JavaScript eval/Function 或经导入验证的 shell 字符串 API， 常见的 Next.js 和经导入验证的 Express 管理 API 处理程序缺少明显的身份验证 或服务器端授权，明确配置为匿名部署但没有请求身份验证或特权操作授权的 Supabase Edge Functions， 使用客户端可写的 user_metadata 进行授权，以及通过 dangerouslySetInnerHTML 渲染未经净化的模型／用户输出（XSS / LLM05）；另外还包括明确的 API 边界 泄露、原始请求写入数据库、敏感日志记录，以及需证据支持的安全标头／CSP／Referrer-Policy／Permissions-Policy／会话 Cookie／Supabase-CAPTCHA 配置检查。另有独立的第一方规则包，涵盖六种范围狭窄的 Flutter/Dart 源码故障模式和八种有限范围的 Android/iOS 仓库配置故障，以及四种 React Native 和两种 Expo 框架特有的移动端故障。有限范围的 Python AI/API 规则包涵盖十种狭窄的 Django、Flask、FastAPI、Starlette、Jinja、OpenAI、Anthropic、LangChain 和 OS 命令源码故障。 独立的 Go、Java 和 C# AI 规则包各自包含一条精确规则，检测官方 OpenAI SDK 中从工具参数到 shell 的传递；PHP 规则包为社区维护的 openai-php/client 生态系统提供一条等效规则，Rust 规则包为社区维护的 async-openai 生态系统提供一条有限范围的规则。Ruby 规则包为官方 openai gem 提供一条等效规则。Firebase 配置规则包包含 三条针对 Firestore、Cloud Storage 和 Realtime Database 的字面公开写入规则。GitHub Actions 规则包包含两条工作流规则，分别检测直接插入不可信上下文的 shell 插值，以及精确的 pull_request_target 检出并执行链。

随附的清单包含 94 项精选检测：72 个第一方原生规则 ID（29 个 JavaScript/TypeScript、6 个 Flutter/Dart、4 个 Android、4 个 iOS、4 个 React Native 和 2 个 Expo；此外还有 10 个 Python AI/API、1 个 Go AI、1 个 Java AI、1 个 C# AI、1 个 PHP AI、1 个 Rust AI、1 个 Ruby AI、 3 个 Firebase 配置、2 个 GitHub Actions 工作流，以及 2 个 JavaScript 基线 SAST 规则）、18 条由 Opengrep 维护的 SAST 规则，以及 4 条自定义 Gitleaks 规则。全部 20 条 Opengrep YAML 规则在运行时仍保持启用： 由原生引擎负责的两条规则会核对结果是否完全一致，并在结果不符或原生引擎不可用时回退到 Opengrep。 Opengrep、Gitleaks 和 Trivy 均为可选、受管理且可叠加的引擎。

CodeInspectus 会在征求许可前，说明每个引擎的覆盖范围、许可证、特定平台的大小以及所需操作。获得批准后，它会下载官方的、由 SHA 固定版本的 引擎二进制文件，将其存储在 npm 包之外，并将其作为本地子进程调用。它不会分叉这些引擎。

为什么选择 CodeInspectus？

AI 生成的应用经常会带有通用扫描器容易漏掉的安全问题：暴露的客户端密钥、薄弱的 Supabase 身份验证模式、不安全的 HTML 渲染、提示词注入接收点，以及有风险的 AI／向量存储集成。

CodeInspectus 将经过验证的本地扫描器与 AI 应用专用规则相结合，并通过 MCP 服务提供工作流，让编码 Agent 能够在发布前扫描、解释并协助修复问题。

安装

前置条件： Node.js ≥22。推荐使用 Node 24 LTS。无需单独安装引擎或 Cosign。经批准后，CodeInspectus 可以在 ~/.codeinspectus/ 中引导安装一个 SHA 固定版本的 Cosign 验证器；签名验证仍采用失败即关闭策略。 在 Linux 上，当前上游 Opengrep 资源需要 glibc。Alpine/musl 仍支持原生 CodeInspectus 规则、Gitleaks 和 Trivy，但在任何下载开始前，安装流程都会将 Opengrep 标记为不可用；如果选择了 Opengrep，汇总扫描覆盖率会报告为部分覆盖。

官方 @contentauth/c2pa-node 验证器是一个可选的 peer 依赖，因为其上游包会在自身生命周期脚本中下载平台原生绑定。常规 CodeInspectus 安装不会安装该 peer 依赖。如果需要本地 C2PA 验证，请将其与 CodeInspectus 一并显式安装；否则，候选资源会报告部分 content_provenance 覆盖。

# Interactive: inspect coverage, licenses, and sizes; then approve all or choose components.
npx codeinspectus setup

# Automation after an operator has reviewed the plan:
npx codeinspectus setup --status
npx codeinspectus setup --all
npx codeinspectus setup --select opengrep,gitleaks

在终端中，首次直接运行 npx codeinspectus 会打开此引导式安装流程。MCP 客户端仍通过管道 stdio 启动，并提供 codeinspectus_setup：Agent 必须先请求计划、展示计划并征求许可，然后调用 install 并设置 confirm_downloads=true。被拒绝的选项会保存下来，避免反复征求用户意见；setup --reset 可清除这些选项。

安装流程首先会在不访问网络的情况下检查本地状态。它只会下载缺失、不匹配或新固定版本的二进制文件，根据 npm 包中附带的不可变锁定文件验证这些文件，然后以原子方式安装到 ~/.codeinspectus/。只有在离线 Trivy 漏洞数据库缺失、没有重新扫描来源记录或超过七天未更新时，才会刷新该数据库。因此，仅更新规则的 CodeInspectus 升级不会下载任何内容。安装完成后，扫描不会进行任何网络 I/O。

每个扫描结果和 codeinspectus_list_rules 响应都包含结构化的 engine_setup 状态：ready、repair_required、db_refresh_recommended 或 unsupported_platform。系统会指示 MCP Agent 说明非就绪状态，并通过 codeinspectus_setup 征求批准。不会通过静默的 npm postinstall 下载任何内容。高级用户或手动操作仍可使用 repair-engines；较旧的 install-engines 命令仍作为兼容别名保留。

如果 Trivy 数据库是在 0.3.2 之前安装的，扫描输出会提示你的 Agent 尚未启用 CVE 重新扫描跟踪。Agent 应运行一次安装流程（codeinspectus_setup 或 npx codeinspectus setup）；这会通过经过验证的安装路径重新获取数据库并记录其来源。在此之前，已消失的 CVE 会保守地报告为 not_rechecked；当前扫描发现仍完整无缺，不受影响。

可随时重新验证固定版本的二进制文件：

npx codeinspectus verify-engines

CLI、CI 和本地证据工作流

codeinspectus scan . --format sarif --output results.sarif
codeinspectus scan . --format csv --output findings.csv
codeinspectus scan . --format sarif --output results.sarif --fail-on-severity high
codeinspectus scan . --baseline SCAN_ID --fail-on-new-severity high
codeinspectus scan . --diff origin/main --head HEAD
codeinspectus scan . --working-tree --base HEAD
codeinspectus bundle create SCAN_ID --output-dir /outside/repository/scan-results
codeinspectus bundle verify /outside/repository/scan-results
codeinspectus bulk scan /absolute/path/to/local-repositories --concurrency 2
codeinspectus history scan . --from BASE_SHA --to HEAD_SHA --since 2026-07-01 --until 2026-07-30 --max-commits 20
codeinspectus issue export SCAN_ID CI-0001 --adapter github --visibility private

限定于 Git 的扫描会保留完整仓库上下文，为变更内容与支持上下文中的发现添加标记，并报告精确的解析后修订版本和明确的完整性限制。它们绝不会检出、重置、暂存或修改仓库。请参阅 docs/GIT-SCOPED-SCANS.md。

封存包会保留经过脱敏的 JSON、SARIF、Markdown、覆盖率、来源信息，以及一份附加的规范化扫描记录，其中包含每个制品的内容哈希。导出或比较封存包之前必须进行验证。请参阅 docs/SEALED-SCAN-BUNDLES.md。

CSV 是规范 JSON 模型的确定性、适用于电子表格的投影。即使没有任何发现，也始终会保留明确的扫描/覆盖率行，并对可能触发公式的单元格进行中和处理。有关稳定的列约定，请参阅 docs/CSV-EXPORT.md。

V2 TypeScript SDK 可从 codeinspectus/sdk 获取。它是一个有界、无 shell 的封装器，调用实际安装的本地 CLI，并导出带版本的发现、覆盖率、历史记录、基线、分类处置和封存包类型，而不重复扫描器逻辑。请参阅 docs/TYPESCRIPT-SDK.md。 批量模式会在一个明确指定的本地父目录下扫描已存在的代码仓库，并采用有界并发、按代码仓库隔离和可原子恢复的清单。它不会克隆代码仓库，也不需要 GitHub 账号。请参阅 docs/BULK-SCANNING.md。

代码仓库历史模式需单独选择启用，并要求明确指定修订版本、UTC 日期和提交数量范围。它会扫描相互隔离的不可变快照，将浅层或截断的历史标记为部分历史，绝不会将旧发现描述为当前问题，也不会将历史机密描述为仍然有效的机密。请参阅 docs/REPOSITORY-HISTORY.md。

问题跟踪适配器会生成一份经过脱敏、需要审核的 GitHub、Jira 或 Linear JSON 负载，不需要身份验证，也不会提交。必须指定目标的可见性，产物中会保留有关公开或私密披露的警告。请参阅 docs/ISSUE-PAYLOADS.md。

第一条命令仅生成报告：保留发现，但不会导致完整扫描失败。第二条命令会强制执行严重性阈值。如果汇总覆盖范围为部分覆盖或未知，两条命令都会以退出码 2 失败并关闭；覆盖范围优先于发现的严重性。只有在覆盖完整后出现超过阈值的发现，才会使用退出码 1。完整的退出约定、SARIF 上传、产物隐私以及 fork/Dependabot 行为，请参阅 CLI 命令参考和 CI 策略及 SHA 固定的 GitHub Actions 工作流。

只有在与兼容的明确存储扫描结果进行比较，并能证明发现是新增项时，基线强制执行才会失败。不兼容、部分或未知的比较证据会以退出码 2 失败并关闭。本地分诊会以仅追加的方式添加审核上下文，不会隐藏或更改发现。有关命令、精确匹配、范围、存储、脱敏、架构和审计行为，请参阅基线与本地分诊。

无需网络连接即可列出、检查、重新运行和比较本地扫描历史：

codeinspectus scans list --repository "$PWD"
codeinspectus scans show SCAN_ID
codeinspectus scans rerun SCAN_ID
codeinspectus scans compare OLD_SCAN_ID NEW_SCAN_ID --format json

比较受证据条件约束：只有在生产者组件兼容且覆盖范围完整、可进行同类比较时，缺失项才会标记为 Resolved；否则会标记为 Not rechecked / unknown。有关筛选条件、范围、V1.x 兼容性、损坏处理和 Reopened 来源信息，请参阅扫描历史与比较约定。

随附的 Agent 规则还定义了一个需经批准的单项发现修复工作流：调查一项确切发现，提出回归原因和最小补丁，只有在另行获得批准后才编辑，随后进行测试，再针对确切的先前扫描结果重新扫描。只有 CodeInspectus 的 resolved 结果才能支持扫描器已解决的声明；not_rechecked 则仍表示明确的证据缺口。

以下两个明确且可选的工作流可扩展调查，但不会改变扫描器给出的事实：

• 威胁建模与知识库审查会将每份由代码仓库控制的文档都视为不可信上下文。文档可以解释或确定原始发现的优先级，但绝不能抑制、降级、覆盖发现，也不能将其标记为已解决。
• 有界多 Agent 审查会将确定性发现与 Agent 解读置于不同的证据通道，明确限制 Agent 数量、时间、范围和成本，并要求先针对确切的先前扫描结果进行确定性重新扫描，之后才能声明扫描器已解决问题。

这些规则包含在 npm 包的 agent-rules/ 目录中；常规 CLI 和 MCP 扫描不会加载文档、调用模型，也不依赖这两个工作流。

每台机器只需安装一次 MCP 服务，即可供所有项目共享——它不是每个代码仓库都需要执行 npm install 安装的依赖。

客户端注册

各客户端使用的服务器命令相同，但配置格式各不相同。使用 JSON MCP 配置的客户端如下：

{
  "mcpServers": {
    "codeinspectus": { "command": "npx", "args": ["-y", "codeinspectus"] }
  }
}

客户端	方法
Claude Code	claude mcp add-json codeinspectus '{"command":"npx","args":["-y","codeinspectus"]}'
Cursor	添加到 ~/.cursor/mcp.json（或项目的 .cursor/mcp.json）
VS Code	code --add-mcp '{"name":"codeinspectus","command":"npx","args":["-y","codeinspectus"]}'
Codex	使用以下 Codex 专属选项之一
Windsurf / Cline / Aider	将上面的 JSON 代码块添加到该客户端的 MCP 配置中

对于 Codex，请选择一种注册方式：

# Codex CLI
codex mcp add codeinspectus -- npx -y codeinspectus

• Codex 应用或 IDE 扩展： 打开 Settings → MCP servers → Add server， 选择 STDIO，将命令设为 npx，参数设为 -y、 codeinspectus，然后重启。
• Codex 配置文件： 将以下内容添加到全局 ~/.codex/config.toml 或 受信任项目的 .codex/config.toml 中：

[mcp_servers.codeinspectus]
command = "npx"
args = ["-y", "codeinspectus"]
tool_timeout_sec = 600

Codex 将 MCP 工具调用的超时时间默认设为 60 秒。CodeInspectus 会并发运行多个安全引擎， 并允许每个引擎最长运行五分钟，因此设为 600 秒可避免在扫描较大的代码库时客户端过早超时。这仅影响 Codex 客户端的超时时间，不会更改引擎限制或其他客户端的配置。

可选：添加现成的 agent-rules/，让你的 Agent 自动运行“扫描 → 修复 → 重新扫描”循环。

包括 Codex 在内，支持服务器指令的 MCP 客户端也会自动接收安全工作流：先展示发现的问题，在修复前征求 具体授权，并在声称问题已解决之前重新扫描。如果你希望将相同策略明确保存在代码库中，Agent 规则文件仍然很有用。

工具

工具	用途
codeinspectus_scan	对路径进行完整本地扫描（引擎 + AI 检查）。返回按 CWE 分类的发现项、检测到的技术、精确的原生包和 Pub 依赖覆盖情况、修复建议、框架标签，以及受支持运行时控制项的三态仓库证据。
codeinspectus_setup	离线设置计划、已保存的拒绝选项，或需经批准的已验证下载到 ~/.codeinspectus；绝不写入目标仓库。
codeinspectus_rescan	修复后重新扫描；与之前的扫描结果对比，列出已解决／仍存在／新增的问题，并提供最新的技术和包覆盖情况。
codeinspectus_plan_cleanup	为精确且已验证的仓库信任项 ID 生成全新的只读 V3.3 计划，包括修改前哈希、转换、阻碍项和审批要求。
codeinspectus_apply_cleanup	应用一项明确获批的精确计划，并使用托管备份、原子化的有限编辑／仅复制媒体清理、相同验证器验证，以及不含内容的审计日志。
codeinspectus_rollback_cleanup	仅当当前字节与记录的清理后状态仍相符时，才还原已应用的清理。
codeinspectus_compliance_report	各框架的代码级控制覆盖情况（非认证）。
codeinspectus_explain_finding	针对单个发现项提供深入说明和完整修复方案。
codeinspectus_generate_sbom	使用 Trivy 和原生 Pub 清单／回退方案生成 CycloneDX/SPDX SBOM（默认写入托管目录，或写入你选择的绝对 .json 路径；绝不替换现有的非 SBOM 文件）。
codeinspectus_list_rules	活跃检测器、原生包清单／规则归属、引擎版本、检测数据库和 Trivy/Pub 数据库的来源与新鲜度，以及结构化的机器设置／修复状态。

CodeInspectus 会扫描、规划和生成报告，但不会修改仓库。唯一会修改源代码／仓库的操作，是明确获批的 V3.3 应用／回滚工具。它会将引擎数据、扫描历史记录、清理检查点和不含内容的审计记录存储在 ~/.codeinspectus 下。 codeinspectus_generate_sbom 也可以选择将 SBOM 写入托管目录（默认）， 或写入你选择的绝对 .json 路径；若现有文件并非 SBOM，则会拒绝替换。 Git 仅以只读模式运行并使用命令行覆盖选项，因此被扫描仓库自身的配置无法让扫描运行程序（fsmonitor 钩子、签名程序或过滤驱动程序），也无法改写 .git/index。

每次扫描也会报告只读的 git 安全状态：如果没有 git 仓库或存在 未提交的更改，工具会建议在修复前创建检查点——你的 Agent 只有在获得你的批准后 才会运行 git；工具绝不会运行会更改仓库的 git 命令。

源代码完整性 — V3.1

V3.1 在扫描、重新扫描、CLI JSON、MCP 结构化输出、SARIF 元数据和 TypeScript SDK 中，启用了稳定且非 CWE 的 repository_trust 契约中的第一项能力。它会确定性地检查受支持的仓库文本，检测双向覆盖/不平衡控制字符、零宽或默认可忽略的令牌字符、隐藏的 Unicode 标签序列、编码的变体选择符序列，以及一组范围受限的混合文字脚本标识符混淆字符。

每项产物都会报告转义后的码点、Unicode 名称、精确的文件/行/码点列、UTF-8 字节偏移、上下文分类、验证器标识、置信度、限制以及需要审批的建议操作。对于超长标签/变体序列，会保留精确范围和序列长度，同时将呈现的证据限制为 64 个码点；在生成输出前会限制密集候选项和标识符的数量，并将未完成的工作报告为部分完成。初始 BOM、合法的 RTL 文本、表情符号变体/ZWJ/标签序列、国际语言连接符和有歧义的混淆字符都会被抑制或以非破坏性方式保留。扫描绝不会编辑文件。V3.3 清理需要精确计划、针对指定文件和标记的明确审批、可恢复的检查点、支持范围内最小限度的编辑、测试和重新扫描。

这是源代码完整性保护，而非 AI 创作检测。V3.2 的明确归因和 C2PA 结果是独立的能力记录；隐藏的 Unicode 绝不会被归入其中任何一类。CodeInspectus 不会声称隐藏的 Unicode 是 Claude 水印或 AI 生成的证据。

AI 来源审计 — V3.2

V3.2 又启用了两项只读的 repository_trust 能力：

• explicit_ai_attribution 会确定性地检查有界的源代码/配置头部、本地 git 提交尾注，以及受支持的图像 EXIF/XMP/IPTC/PNG 元数据，以查找明确声明 AI 生成器或 AI 来源的信息。这些是对声明性记录的已验证观察，而非该声明属实的证明、来源于供应商的证明或基于统计的作者身份判断。
• content_provenance 使用可选的官方 Content Authenticity Initiative Node 验证器，检查受支持的本地 C2PA Content Credentials。结果会区分有效、可信、无效、存在但无法得出结论以及远程引用证据。离线扫描绝不会获取远程清单、OCSP 响应、信任列表或吊销终结点。

每条解析和遍历路径都有范围限制，会拒绝符号链接，并将排除项报告为 partial。V3.2 检测仍为只读。Git 历史记录、法律、许可和合规记录仍受保护；已验证的非受保护产物可以进入 V3.3 的独立审批工作流。V3.2 不会删除元数据、改写文本、检查像素/音频/视频帧，也不会声称缺少标记就意味着由人类创作。在具备权威、可独立验证且带有校准运行阈值的检测器之前，统计文本水印验证仍为 unavailable。

已验证的仓库清理 — V3.3

V3.3 新增了三个 MCP 工具：codeinspectus_plan_cleanup、codeinspectus_apply_cleanup 和 codeinspectus_rollback_cleanup。规划时始终会运行全新的仓库信任审计，并且只接受精确匹配且已验证的产物 ID。它会拒绝已更改、有歧义、受保护、不受支持、重复或范围过宽的对象，并在审批前记录 SHA-256 修改前数据及精确的转换操作。 应用需要就绪计划 ID、完全相同的制品 ID 集合、confirm_cleanup=true，以及针对署名或来源的单独权利确认。文本清理仅限经过验证的精确 UTF-8 范围和独立署名注释。它会创建受管内容备份，使用原子替换，重新运行相同的验证器，并生成不含内容的审计记录。首次写入前，它会验证每个前像、计算所有输出，并持久化所有备份及不含内容的日志，因此即使应用在任意时刻中断，也能在重启后回滚；在审核之前，该仓库的新规划会被阻止，并注明清理 ID。 回滚仅在后续字节仍与记录的结果一致时恢复；若有后续用户更改，则拒绝覆盖，并且只要有一个文件发生更改，就不会改动任何内容。

受支持的媒体适配器会创建新的 *.codeinspectus-clean.* 副本，并保留原件。它们会剥离 PNG、JPEG、MP3、WAV、MP4、MOV、M4A 和 M4V 资源中的硬绑定元数据容器，而不更改编码后的图像、音频或视频负载；它们还会重写 ISO BMFF 块偏移量，以确保副本仍可播放，并拒绝处理分片或带外部索引的 MP4/MOV 文件。图像元数据制品由内置解析器提供；音频和视频资源只有在可选的官方验证器报告了 C2PA 制品后才符合条件。必须确认容器级移除，因为所选容器中的无关元数据也可能被移除。C2PA 清理需要单独确认这是一个来源信息副本。清理后的副本会单独扫描；包含证据的原始资源保持不变。

CodeInspectus 不会运行任意仓库命令。因此，结果会将仓库测试、格式化工具和构建标记为 not_run 且必需；调用方编码 Agent 必须运行相关检查，才能将清理视为完成。V3.3 永远不会重写 Git 历史、移除可见徽标、更改像素/帧/音频、检测统计水印或声称内容由人类创作。

有关架构和 SDK 变更，请参阅 V3 迁移指南。 detected_technologies 说明 CodeInspectus 发现的有限仓库信号。 pack_coverage 则单独报告实际运行的已注册原生分析器和规则的数量。 ran 包状态表示所列规则已执行；这并不意味着已全面覆盖指定语言或框架的安全问题。 not_applicable 表示已安装的包与检测到的项目技术不匹配；not_run、partial 和 unavailable 用于区分扫描器筛选与执行不完整或失败。只有在有限的仓库信号表明项目使用 Flutter 时，Flutter 包才会运行；普通 Dart 软件包不会触发该包。Android 和 iOS 包同样需要有限的平台项目证据，并会报告各自的平台元数据。 React Native 和 Expo 是由技术条件分别触发的包：Expo 项目可以同时运行两个包，而纯 React Native 项目绝不会意味着 Expo 配置规则已运行。 Python AI/API 包需要有限的 Python／软件包／框架证据。它会将不支持的语法、源代码范围限制以及有意排除的语料库作为明确的覆盖说明报告，而不会推断被省略的源代码是安全的。 Go、Java 和 C# AI 包需要对应语言以及精确匹配的官方 OpenAI SDK 依赖项。 PHP 包需要 PHP，以及精确匹配的 openai-php/client 或 openai-php/laravel Composer 证据；这些软件包由社区维护，并非官方 OpenAI SDK。仅有通用的 openai 框架标签无法触发该包。 Rust 包需要 Rust，以及精确匹配的 async-openai Cargo 依赖项证据；该 crate 由社区维护，并非官方 OpenAI SDK。Ruby 包需要 Ruby，以及生产环境 Gemfile 或运行时 gemspec 中精确匹配的官方 openai 依赖项证据；锁文件仍可作为 Ruby 语言证据，因为它们不会保留依赖组。仅有通用的 openai 框架标签无法触发 Go、Java、C#、PHP、Rust、Ruby 或 Python 分析器。 dependency_coverage 则单独报告原生 Pub 匹配器是否运行、分析了哪些锁文件和符合条件的软件包、有意跳过了哪些内容，以及捆绑快照的版本。

如实说明（请阅读）

• “无出站流量”是精确的：在扫描时出站流量为零。 引擎二进制文件和 Trivy DB 仅通过明确的设置／修复命令从经过验证的来源获取，并进行 SHA256 校验。正常安装 CodeInspectus 不会安装可选的 C2PA 对等包； 用户若明确安装该上游包，即允许其在生命周期中下载内容。扫描期间不会下载任何内容。 扫描器在断网时也能运行。绝不进行遥测。
• 必须固定供应链。 Trivy 在 2026 年初两次遭到供应链攻击； 每个引擎二进制文件的 SHA 值都固定在 engines.lock.json 中，并在执行前验证其 哈希值。CodeInspectus 拒绝运行未固定或不匹配的 二进制文件。
• 所有输出中的机密值都会被脱敏——仅显示类型、位置和脱敏后的 预览。
• 合规性 = 代码层面的控制覆盖情况，绝不代表认证。 CodeInspectus 报告“有 N 项代码可见控制发现问题，共 X 项”，并将代码可见子集明确作为分母， 同时附上固定免责声明。它绝不会输出“您的合规度为 X%”或“您通过了[框架]”。严重性加权的态势 评分是单独的视图，不代表合规百分比。尤其是 Essential Eight：只有大约 8 项缓解措施中的 1 项（修补应用程序）有代码证据——这 不是 Essential Eight 评估。
• 提示词注入检测基于启发式且尚不成熟——相关发现会表述为“潜在……”，并标记为中等置信度。
• Flutter/Dart 原生覆盖包含 6 项范围狭窄、由项目自主实现的结构检查： ci-flutter-tls-verification-disabled、ci-flutter-sensitive-shared-preferences、 ci-flutter-webview-untrusted-content、ci-flutter-sensitive-log、 ci-flutter-supabase-privileged-key-client 和 ci-flutter-cleartext-network。 这些检查会检查 Dart 令牌和本地源码结构，但不进行类型解析或全程序 数据流分析。项目根目录扫描会排除生成文件以及测试／示例内容，除非直接扫描这些路径。 不可读取的 Dart 文件、超过 2 MiB 的文件，以及超出项目 10,000 个文件／64 MiB 边界的源码都会跳过，并在 pack_coverage 中列出。这些是仓库 证据，不代表运行时移动端测试或完整的 Flutter 覆盖。原生 Pub 漏洞／SBOM 分析属于单独的 vuln 类引擎，因此可用于 Flutter 和纯 Dart 项目， 但这并不表示 Flutter 源码包已运行。Android/iOS 配置由 单独的原生平台包处理；现有 Trivy 行为保持不变。 随附的 Flutter TP/FP/fixed corpus 精确锁定每条规则在易受攻击项目中 预期有一个发现，在近似误报项目和已修复项目中均无发现。E23/E24 通过已构建的 MCP stdio 服务 对该语料进行测试，包括包执行计数和植入的合成哨兵值脱敏。
• Android/iOS 原生覆盖包含 8 项范围狭窄、由项目自主实现的仓库配置检查。 Android 检查显式启用调试的发布版本、有效的生产明文流量选择加入、生产环境信任用户添加的 CA， 以及导出的 AndroidX FileProvider。iOS 检查全局 ATS 任意加载、不安全的生产域名例外、 生产域名 TLS 策略过弱，以及默认数据保护被禁用。这些包会解析有界的字面 XML/Xcode 仓库证据； 它们绝不运行 Gradle、Xcode 或目标代码，也绝不执行解析出的配置。动态构建设置、 任意 Android 产品风味、完整清单合并、配置描述文件、运行时行为和完整的移动平台安全性 均不在范围内。跳过或不支持的配置会在 pack_coverage 中列出，不会推断为安全或易受攻击。 随附的 Android/iOS TP/FP/fixed corpus 以及 E25/E26 会锁定准确发现、无发现的近似误报／已修复状态、来源信息、脱敏、 执行计数，以及双向同路径重新扫描行为。
• React Native/Expo 原生覆盖包含 6 项范围狭窄、由项目自主实现的结构检查。 React Native 包会检查敏感凭据是否写入已确认的 AsyncStorage 接收端、不可信路由／ 深层链接内容是否进入已导入且启用 JavaScript 的 WebView、是否显式选择加入混合内容， 以及文件来源 WebView 是否允许访问通用来源。单独的 Expo 包会检查敏感服务器环境值是否放入 公共应用配置，以及未签名更新是否通过明文生产 URL 获取。两者均使用有界只读解析， 绝不导入、执行或求值目标代码／配置。动态值、展开语法、未解析的防护条件、不可读取／过大的输入 以及超出边界的源码都会列为明确的覆盖限制，而不会推断为发现。必须存在框架证据； 普通 JavaScript/TypeScript 或原生 Android/iOS 骨架不会启用这些包。这些是文件内／静态仓库证据， 不代表完整数据流分析、部署证明或运行时移动端测试。随附的 React Native/Expo TP/FP/fixed corpus 和 E30/E31 会锁定准确发现、 精确度、脱敏、来源信息、执行计数，以及同路径问题解决／重新引入行为。
• Python AI/API 原生覆盖包含 10 项范围狭窄、由项目自主实现的结构检查。 该包会检查 硬编码的框架签名机密、允许携带凭据且来源为任意域的 CORS、由请求控制的文件响应和重定向、 由请求控制的模板源码、未经净化便作为 HTML 返回的 OpenAI/Anthropic 输出、显式启用 LangChain FAISS pickle 反序列化，以及由请求控制、通过已确认的 LangChain WebBaseLoader 获取的完整 URL；还会检查中等置信度的潜在提示词注入接收端：请求输入到达已确认的 OpenAI/Anthropic 特权指令，或与已配置的工具访问共享 LLM 调用；以及模型工具参数到达已确认的 Python shell 执行 API，且没有可见的经过检查的防护条件。它使用有界的 Lezer 语法门控和按源码顺序的文件内分析； 绝不导入或执行目标 Python 代码。它不提供类型检查器、模块图、跨过程流分析或路径敏感的分支合并。 经 Lezer 验证的格式字符串会保留为不透明动态值，因此不会检查其替换表达式；缩进以制表符开头时 仍会安全失败，并附带明确的覆盖说明。项目根目录扫描会排除生成、迁移、依赖、构建、测试、 夹具、演示、样例和示例目录。对于不支持、格式错误、符号链接、不可读取、过大或超出边界的源码， 会报告问题，而不会推断为安全。随附的 Python AI/API TP/FP/fixed corpus 和 E32/E33 会锁定准确发现、精确度、脱敏、来源信息、执行计数，以及同路径问题解决／重新引入行为。
• Go AI 原生覆盖包含 1 项范围狭窄、中等置信度的结构检查。 ci-go-llm-tool-argument-command-execution 要求使用精确的官方 OpenAI Go SDK Chat Completions 工具调用参数结构，并通过导入证明调用已识别的 shell 及其命令标志。 它支持直接别名、encoding/json.Unmarshal、一个本地 JSON 解析器和一个本地命令包装器。经过检查的 拒绝／批准或允许列表防护条件，以及经过验证的替换值会抑制发现。它不涵盖通用 Go SAST、其他模型 SDK、跨模块分派、运行时沙箱或完整的 Agent 安全审查。随附的 Go TP/FP/fixed corpus 以及 E37/E38 会锁定准确发现、无发现的安全／ 已修复状态、来源信息、包分派，以及同路径问题解决／重新引入行为。
• Java 和 C# AI 原生覆盖在每个生态系统中各包含 1 项范围狭窄、中等置信度的结构检查。 每项检查都要求存在精确的官方 OpenAI SDK 依赖和工具调用参数结构，之后模型数据才能到达已识别且 实际启动的 shell 进程。支持直接别名、一个本地解析器和一个本地命令包装器；经过检查的拒绝／批准或 允许列表防护条件，以及经过验证的替换值会抑制发现。这些包不提供通用 Java 或 C# SAST、跨模块分派、运行时沙箱证明或完整的 Agent 审查。随附的 Java and C# TP/FP/fixed corpora 以及 E39-E42 会锁定准确发现、 安全／已修复状态下无发现、来源信息、语言门控分派，以及同路径问题解决／重新引入行为。
• PHP AI 原生覆盖包含 1 项范围狭窄、中等置信度的结构检查。 ci-php-llm-tool-argument-command-execution 要求存在精确的社区维护 openai-php/client 或 openai-php/laravel Composer 证据，并要求模型工具调用的 function->arguments 到达 exec、system、shell_exec 或 passthru。它支持直接 别名、关联数组形式的 json_decode、一个本地解析器、一个本地命令包装器和一种精确的 映射变参方法分派。经过检查的批准／完整命令允许列表和经过验证的替换值会抑制发现；首个令牌的可执行文件检查 无法中和 shell 元字符，也不会抑制发现。它不提供通用 PHP SAST、跨文件流分析、 运行时沙箱证明或完整的 Agent 审查。随附的 PHP TP/FP/fixed corpus 以及 E43/E44 会锁定准确发现、安全／已修复状态下无发现、来源信息、语言门控分派，以及 同路径问题解决／重新引入行为。
• Rust AI 原生覆盖包含 1 项范围狭窄、中等置信度的结构检查。 ci-rust-llm-tool-argument-command-execution 要求存在精确的社区维护 async-openai Cargo 证据，并要求已识别的模型工具参数到达经导入证明的标准／Tokio 进程 shell 或字面量 Bollard Docker exec shell 向量。它支持直接别名、serde_json 提取、一个已识别的 generate_function_call 结果和一个本地命令包装器。经过检查的批准／允许列表拒绝条件和经过验证的替换值会抑制 发现。它不提供通用 Rust SAST、rustc／类型／Cargo 图解析、跨 crate 流分析、运行时容器／沙箱证明 或完整的 Agent 审查。随附的 Rust TP/FP/fixed corpus 以及 E45/E46 会锁定准确发现、安全／已修复状态下无发现、 来源信息、语言门控分派，以及同路径问题解决／重新引入行为。async-openai 由社区维护， 不会被描述为官方 OpenAI SDK。
• Ruby AI 原生覆盖包含 1 项范围狭窄、中等置信度的结构检查。 ci-ruby-llm-tool-argument-command-execution 要求存在精确的官方生产环境 openai Gemfile 或运行时 gemspec 证据，并识别 Chat 工具调用的 function.arguments 或显式类型化的 Responses 函数工具 参数是否到达 system、exec、IO.popen 或经导入证明的 Open3 shell 执行。它 支持直接别名、JSON.parse 命令提取、一个本地解析器和一个本地命令包装器。经过检查的批准／完整命令 允许列表和经过验证的替换值不会触发发现。它不提供通用 Ruby SAST、Bundler／类型解析、 跨文件流分析、反引号／百分号 x／spawn 覆盖、运行时沙箱证明或完整的 Agent 审查。随附的 Ruby TP/FP/fixed corpus 以及 E47/E48 会锁定准确发现、 安全／已修复状态下无发现、来源信息、语言门控分派，以及同路径问题解决／重新引入行为。
• Firebase 原生覆盖包含 3 项范围狭窄、高置信度的配置检查。 ci-firebase-firestore-public-write、ci-firebase-storage-public-write 和 ci-firebase-realtime-database-public-write 仅标记已提交代码中没有条件或条件恰好为 true 的字面写入授权（Realtime Database 的布尔值／字符串 true）。公开读取不会触发发现， 因为它们通常是有意配置的。有界解析器会屏蔽规则注释／字符串，要求 Firestore/Storage 服务声明完全匹配， 要求 Realtime Database 使用严格 JSON，并排除非生产／依赖／生成目录；绝不运行 Firebase 工具或目标代码。它不会评估辅助函数、已部署策略、IAM、App Check 或运行时访问。 随附的 Firebase TP/FP/fixed corpus 以及 E49/E50 会锁定准确发现、 安全／已修复状态下无发现、来源信息、包分派，以及同路径问题解决／重新引入行为。
• GitHub Actions 原生覆盖包含 2 项范围狭窄的工作流检查。 ci-github-actions-untrusted-expression-command 会标记直接嵌入 run 的、文档明确记载且由攻击者控制的 github 表达式；使用中间 env 值或 action with 输入则不会触发发现。 ci-github-actions-pwn-request 要求完整的高风险链条：精确的 pull_request_target、将拉取请求的不可信引用检出到默认工作区，以及随后执行已检出的代码或本地 action。 除非显式启用 allow-unsafe-pr-checkout，否则会将 Checkout v7 视为受保护版本。 有界 YAML 1.2 解析器只读取直接的 .github/workflows/*.yml／.yaml 文件，绝不执行工作流或目标代码。 它不提供通用工作流污点分析、自定义 action 分析、制品流分析、权限策略证明或运行器／运行时验证。 随附的 GitHub Actions TP/FP/fixed corpus 以及 E51/E52 会锁定准确发现、 安全／已修复状态下无发现、来源信息、分派，以及同路径问题解决／重新引入行为。
• 如果客户端授权信任 user_metadata，则会标记此问题（ci-ai-client-metadata-authz）。 CodeInspectus 会以高严重性、中等置信度（CWE-639）检测读取客户端可写 Supabase user_metadata 的授权决策——例如 if (user.user_metadata.role === 'admin')。 user_metadata 可由登录用户本人编辑（通过 Supabase 的 /auth/v1/user 端点），因此任何人都能自行赋予 role: 'admin'；应使用服务器控制的 app_metadata.role 来限制特权逻辑。 检测范围为文件内 （内联 + 拆分变量／解构）；目前不会追踪跨文件或整个对象别名流（计划中）——参见 good-first-issue。 它还会捕获相关的易错点：客户端可访问代码中的 Supabase service_role JWT 或现代 sb_secret_ 密钥值（严重），以及放在客户端可见环境变量前缀（如 NEXT_PUBLIC_…）后的特权密钥 （高）。格式完全匹配的 sb_publishable_ 密钥会保持静默，因为它们本就公开。每类密钥在每个文件中 最多记录 1,024 个修复位置；同一压缩行上的重复值会合并，不同行仍会分别显示，达到上限时会发出明确的覆盖说明。
• 如果未经净化的模型或用户输出被渲染为原始 HTML，则会标记此问题 （ci-ai-llm-output-dangerous-html）。 CodeInspectus 会检测不可信的请求输入或 LLM／模型输出未经净化便流入 dangerouslySetInnerHTML——这是直接的 XSS 接收端（CWE-79/116；模型输出路径上的 OWASP LLM05），严重性为高，置信度为中等；将值包装在 DOMPurify.sanitize(...) 中即可抑制发现。 如果解构的 prop 直接传入 __html，它会跟踪一次本地函数组件跳转；在 JSX 调用处进行净化则不会触发发现。 它不会追踪跨文件或箭头组件 prop、数据库行、模板数据、对象展开接收端或自定义净化包装器。
• 如果模型输出传入动态执行，则会标记此问题（ci-ai-llm-output-dynamic-execution）。 CodeInspectus 会跟踪从已识别的 OpenAI、Anthropic、Google GenAI、Vercel AI SDK、Cohere、Groq 和 Mistral 调用／输出结构，经直接和拆分变量的文件内流，流向全局 eval／Function、经导入证明的 Node child_process.exec／execSync，或经导入证明的 Execa 命令字符串 API。该规则严重性为高、置信度为中等（CWE-94/78/1426； OWASP LLM05）。常量、固定允许列表分派、execFile／spawn 参数数组、 被遮蔽的全局对象，以及经过明确验证的替换值都不会触发发现。跨文件流、 自定义模型包装器、流式内容累积、间接接收端别名，以及运行时沙箱或批准状态均不会被解析。
• 传统 Next.js 管理员 API 路由需要身份验证和授权 （ci-ai-nextjs-admin-route-no-authz）。当文件中看不到任一边界时， Pages Router 中 pages/api/admin 下的处理程序和 App Router 中 app/api/admin/**/route.* 下的处理程序会被标记（高，中等置信度；CWE-862/863/306； OWASP A01 和 API5）。可识别的服务器会话／令牌检查以及角色／权限决策不会触发发现；Supabase 客户端可写的 user_metadata 会被明确拒绝用作授权依据。非管理员／公开路由不会触发发现。有界检测器只跟踪精确的直接证据和 一次本地辅助函数跳转；不支持的跨文件中间件、自定义防护语义和动态分派会明确标记为未知。
• 会检查经导入证明的 Express 管理员路由和显式匿名的 Supabase Edge Functions。 Express 分析要求路由字面量包含管理员路径并有直接的处理程序证据，遵循支持的中间件／挂载顺序， 并将未解析的自定义中间件作为覆盖元数据报告。Edge 分析将默认或显式的 verify_jwt = true 视为平台身份验证； 只有显式匿名部署才要求可见的请求身份验证，服务角色／管理员操作还要求可见的服务器授权。跨模块自定义包装器仍为未知。
• 服务器/API 边界检查范围有限，仅检查代码可见证据。 4 个 JavaScript/TypeScript 分析器会标记客户端可见的原始／内部错误详情（CWE-209）、响应对象中的显式凭据字段（CWE-201）、 未经可见验证或允许列表处理便直接传入常见 Prisma/Supabase/Mongoose 写入操作的整个请求对象 （CWE-915），以及发送到日志中的显式凭据／标头／Cookie 或身份验证／支付请求正文 （CWE-532）。它们使用文件内数据流；如果能看到验证、公开错误映射器或显式字段投影，则优先保持静默。 构建输出和压缩的供应商文件不在这些源码检查范围内。它们不宣称能检查通用响应最小化、完整业务授权 或运行时／网关验证。
• 运行时安全控制使用 3 种证据状态，绝不将缺失视为漏洞。 受支持的标头／CSP／Cookie／CAPTCHA 控制会报告 verified_in_repository、insecure_configuration_found 或 not_verifiable_from_repository。只有明确的不安全仓库配置才会成为发现；缺少标头、仅在仪表板配置的 CAPTCHA、动态／冲突层以及托管／网关配置只作为元数据，不会扣减态势分数。“已验证”仅表示已识别的源码配置通过了 规则的狭义字面检查；它不代表运行时或完整策略证明。当前发现涵盖明确禁用或 中和的安全标头、包含裸通配符或 'unsafe-eval' 脚本来源的生产 CSP、 有效的字面量 Referrer-Policy: unsafe-url、字面量 Permissions-Policy 中不受限制的摄像头／麦克风／ 地理位置委派、显式设置了不安全属性的身份验证／会话 Cookie，以及已提交的 Supabase CAPTCHA 启用配置与已识别的注册、密码／OTP／SSO／Web3 登录或密码重置调用配对，但调用缺少 captchaToken 的情况。 CAPTCHA 发现描述的是 Supabase 应当拒绝的集成失败，而非绕过机器人防护。 CodeInspectus 仍不能证明已部署的标头、网关速率限制、DNS 邮件安全态势、完整的 CSP 质量、运行时覆盖项 或身份验证行为。由于权威状态取决于实时 DNS，因此不会将缺少 SPF/DMARC 作为仓库发现报告； 且 DMARC p=none 是有效的监控模式；应在部署时明确验证邮件域名。

语言支持

简而言之，说明支持范围。通用引擎覆盖面广；CodeInspectus 原生检查主要针对 JavaScript/TypeScript，同时也覆盖特定的 Flutter/Dart、Android/iOS 配置、React Native、Expo、Python AI/API，以及各包含一条规则的 Go、Java、C#、PHP、Rust 和 Ruby AI 工具包，此外还包括 Firebase Security Rules 和 GitHub Actions 工作流配置工具包。Python 代码库只有符合文档所列十种框架/源代码形式时，才有原生覆盖；Go/OpenAI、 Java/OpenAI、C#/OpenAI、PHP/openai-php、Rust/async-openai 或 Ruby/OpenAI 代码库则只适用其文档所列的一条工具执行规则。其他不受支持的原生工具包生态仍会获得所选通用引擎的覆盖，但不适用任何原生工具包。没有 Flutter 的纯 Dart 项目也不会启用 Flutter 源代码工具包 （但独立的原生 Pub SCA/SBOM 引擎仍可运行）。特此说明，避免你误以为覆盖范围超出实际执行的工具包报告所示范围。

层级	涵盖内容	语言／生态系统范围
密钥 — Gitleaks + 适用的原生客户端密钥检查	硬编码凭据、泄露的密钥	Gitleaks：适用于任何语言，因为其检测基于值／模式。原生客户端密钥分析仍取决于具体检测包：JavaScript/TypeScript bundle 和环境变量暴露，以及传入 Flutter 客户端初始化的 Supabase 特权密钥。
依赖项（CVE/SCA）、IaC 错误配置、SBOM、许可证 — Trivy	易受攻击的依赖项、基础设施错误配置、物料清单	涵盖多种语言和包生态系统及 IaC 格式 — 请参阅 Trivy 的文档。
原生 Pub SCA/SBOM — CodeInspectus Pub	与随附公告快照中的确切锁定版本匹配；原生 Pub 清单及 Trivy 合并／回退	仅限 Dart/Flutter pubspec.lock。 官方 pub.dev／旧版官方托管包按精确列出的版本匹配。自定义注册表、Git、路径、SDK、格式错误、超大和无法读取的输入均会排除并报告。不进行通用 SemVer 推断、可达性判断、许可证推断，也不声称提供完整的依赖关系图。
SAST — Opengrep + CodeInspectus security-baseline	注入、XSS、SSRF、弱加密、不安全反序列化、明确的 CORS 错误配置	JavaScript、TypeScript、Python。 CodeInspectus 自带 Apache-2.0 规则集，并在运行 Opengrep 时不使用网络注册表规则包，因此 SAST 覆盖范围严格限于这些语言——有意窄于 Opengrep 的完整引擎。
原生 JavaScript/TypeScript 检测包	客户端密钥／bundle 暴露、Supabase RLS、提示词注入汇点、模型工具参数传入 Node shell 执行、客户端可写的 user_metadata 授权、未清理输出导致的 XSS、API 响应／错误泄露、不安全请求写入、敏感日志、明确的运行时控制错误配置	JavaScript／TypeScript（包括 .jsx/.tsx/.mjs/.cjs；客户端密钥检查也会读取 .vue/.svelte/.astro/.html）。Supabase RLS 会分析 .sql 和 .ts/.js Edge Functions；运行时控制证据也会读取受支持的配置格式。模型工具命令流分析仅限文件内，并且仅限直接流或一个具名包装函数；不会解析跨模块分发或运行时审批／沙箱状态。
原生 Flutter/Dart 检测包	禁用 TLS 验证、向 SharedPreferences 写入敏感数据、不可信的启用 JavaScript 的 WebView 导航、敏感日志、Supabase 特权客户端密钥、生产环境明文端点	仅限 Flutter 项目。 基于令牌、按源代码顺序进行的文件内 Dart 分析；不进行类型解析、按路径合并分支、完整数据流分析或运行时移动端测试。Pub SCA/SBOM 由独立的原生 Pub 引擎报告。检测包覆盖范围会明确说明文件／总量上限和未覆盖内容。
原生 Android 配置检测包	可调试的发布版清单、有效的明文流量配置、生产环境用户 CA 信任、已导出的 AndroidX FileProvider	仅限 Android 项目证据。 使用有界结构化 XML，并支持 main 到 release 的优先级；不执行 Gradle、不评估任意 flavor/DSL、不进行完整的清单合并、运行时测试或完整 Android 审查。
原生 iOS 配置检测包	全局 ATS 任意加载、不安全的域名例外、弱 TLS 策略、禁用默认数据保护	仅限 iOS 项目证据。 对 XML plist／entitlements 进行有界解析，并检查字面量 Release/AppStore Xcode 引用；不执行 Xcode、不展开动态设置、不检查 provisioning profile、不进行运行时测试或完整 iOS 审查。
原生 React Native 检测包	向 AsyncStorage 写入敏感数据；不可信、混合内容或文件来源的 WebView 配置	仅限确切的 React Native 依赖或经静态证明的 Expo 项目证据。 Expo 使用 React Native，因此经证明的 Expo 证据会同时启用两个检测包；裸 React Native 证据不会启用 Expo 规则。采用有界、感知令牌／结构的 JS/TS/JSX 分析；不执行模块、不解析类型、不分析全程序流、不评估动态属性、不进行运行时测试或完整 React Native 审查。
原生 Expo 检测包	通过公开应用配置暴露服务器密钥；未签名的明文生产更新	仅限确切的 Expo 依赖或显式的顶层 expo 配置证据；通用的 name + slug 字段不会启用检测包。 有界地发现根目录和嵌套包；解析支持注释／尾随逗号的 JSON，并以不执行代码的方式解析直接对象形式的 JavaScript/TypeScript 配置；动态配置会被省略并报告，绝不会执行。
原生 Python AI/API 检测包	硬编码签名密钥；带凭据的通配符 CORS；不可信文件响应、重定向和模板源；将 LLM 输出作为不安全 HTML 返回；明确存在危险的 LangChain FAISS 反序列化；由请求控制的 LangChain Web 加载器抓取；提示词注入汇点；模型工具参数传入 Python shell 执行	Python，且需有界的 Django、Flask、FastAPI、Starlette、Jinja2、OpenAI、Anthropic 或 LangChain 证据。 使用由 Lezer 门控、无需执行代码的文件内分析；不解析类型或模块图，不进行通用的过程间／路径敏感流分析，不证明工件可信，不完整分析 SSRF/Agent 防护，不提供完整 Python 审查，也不提供运行时证明。工具执行分析支持直接流和一个具名本地包装函数，不支持通用／跨模块分发。不支持的语法和超出边界的输入会安全地拒绝处理，并在检测包覆盖范围中报告。
原生 Go AI 检测包	模型生成的 OpenAI Go 工具参数传入可识别的 os/exec shell 调用	仅限使用确切官方 github.com/openai/openai-go 模块的 Go 项目。 一条有界、无需执行代码、文件内的中等置信度规则；不提供通用 Go 安全覆盖，不支持其他模型 SDK，不解析类型／模块，不分析跨模块流，不证明运行时审批／沙箱状态，也不提供完整 Agent 审查。
原生 Java AI 检测包	模型生成的 OpenAI Java 工具参数传入实际启动的可识别 ProcessBuilder 或 Runtime shell 调用	仅限有确切官方 com.openai:openai-java 或 openai-java-core 依赖证据的 Java 项目。 一条有界、无需执行代码、文件内的中等置信度规则；不提供通用 Java 安全覆盖，不支持 Spring AI/LangChain4j/Azure OpenAI，不解析类型／模块，不分析跨模块流，不解析 Java 文本块，不证明运行时审批／沙箱状态，也不提供完整 Agent 审查。
原生 C# AI 检测包	模型生成的官方 OpenAI .NET 工具参数传入实际启动的可识别 System.Diagnostics.Process shell 调用	仅限有确切官方 OpenAI NuGet 包证据的 C# 项目。 一条有界、无需执行代码、文件内的中等置信度规则；不提供通用 C# 安全覆盖，不支持 Semantic Kernel/Azure OpenAI，不解析类型／项目引用，不分析跨文件流，不分析原始字符串内容，不证明运行时审批／沙箱状态，也不提供完整 Agent 审查。
原生 PHP AI 检测包	模型生成的 OpenAI PHP 生态系统工具参数传入 exec、system、shell_exec 或 passthru	仅限有确切的社区维护版 openai-php/client 或 openai-php/laravel Composer 证据的 PHP 项目。 一条有界、无需执行代码、文件内的中等置信度规则；不提供通用 PHP 安全覆盖，不声称支持官方 SDK，不解析类型／Composer 依赖图，不分析跨文件流，不进行通用可调用对象分发，不证明运行时审批／沙箱状态，也不提供完整 Agent 审查。
原生 Rust AI 检测包	模型生成的社区版 async-openai 工具参数传入可识别的标准库／Tokio 进程或 Bollard Docker exec shell 调用	仅限有确切社区维护版 async-openai Cargo 依赖证据的 Rust 项目。 一条有界、无需执行代码、文件内的中等置信度规则；不提供通用 Rust 安全覆盖，不声称支持官方 SDK，不解析 rustc／类型／Cargo 依赖图，不分析跨 crate 流，不进行通用分发，不证明运行时容器／审批／沙箱状态，也不提供完整 Agent 审查。
原生 Ruby AI 检测包	模型生成的官方 OpenAI Ruby 工具参数传入 system、exec、IO.popen 或通过导入证明的 Open3 shell 执行	仅限有确切官方生产环境 openai Gemfile 或运行时 gemspec 证据的 Ruby 项目；仅有 lockfile 证据不会启用检测包。 一条有界、无需执行代码、文件内的中等置信度规则；不提供通用 Ruby 安全覆盖，不解析 Bundler／类型，不分析跨文件流，不覆盖反引号／百分号 x／spawn，不证明运行时审批／沙箱状态，也不提供完整 Agent 审查。
原生 Firebase 配置检测包	Cloud Firestore、Cloud Storage 和 Realtime Database Security Rules 中明确写出的无条件公开写入规则	仅限 Firebase 项目／配置／规则证据。 三条有界、无需执行代码、高置信度规则；公开读取和非字面量条件不会触发检测。不评估辅助函数，不证明已部署策略／IAM／App Check，不进行运行时测试或完整 Firebase 审查。
原生 GitHub Actions 工作流检测包	在 run 中直接插入攻击者可控的 GitHub 上下文；确切的 pull_request_target 不可信检出并执行链	仅限根目录 .github/workflows/*.yml／.yaml 文件。 两条有界、无需执行代码的规则，采用严格的 YAML 1.2 解析。安全的 env／with 间接传递、常规 pull_request、未执行代码的检出以及受保护的 checkout v7 均不会触发检测。不提供通用污点分析、自定义 action、工件、运行器、已部署策略或完整 Actions 审查。

合规框架（代码可见的子集）

NIST CSF 2.0 · ISO/IEC 27001:2022 · SOC 2 · CIS Controls v8.1 · Essential Eight （仅限 Patch Applications）· OWASP Top 10（2021）· OWASP LLM Top 10（2025）。 MITRE ATT&CK 技术仅作为相关对手背景信息展示，绝不作为覆盖率评分。

相关发现还可以带有 OWASP API Security Top 10（2023）类别标签。 这些标签描述检测到的失效模式；它们不代表 OWASP API 审查、 覆盖率评分、合规声明或认证。

合规映射由 AI 起草，并经网络安全从业者 （Synvoya）审查——仅涵盖代码层面，不构成审计或认证。欢迎社区审查。 CWE→控制项映射经过自审，并为每条映射标注置信度，同时设有 开放的社区验证流程——请参阅 docs/COMPLIANCE-RATIONALE.md 和 CONTRIBUTING.md。Essential Eight 不是覆盖情况视图：只有 Patch Applications 有代码证据（约 8 项中的 1 项）——这并非 Essential Eight 评估。

工作原理

agent → codeinspectus_scan → [Opengrep | Gitleaks | Trivy | native Pub] + applicable native packs
      → normalize → dedup (incl. Trivy/native-Pub advisory aliases + secret overlap)
      → CWE-keyed findings + runtime-control evidence → compliance map → compact JSON + summary
ALL LOCAL. NO NETWORK EGRESS AT SCAN TIME.

报告示例

• V2.1 公共仓库扫描 → 修复 → 再扫描 → 封存证据案例研究
• V1.5 公共仓库扫描 → 修复 → 再扫描案例研究
• 对随附的易受攻击测试样例进行可复现的 v0.3.1 扫描

商标

“CodeInspectus”是此免费开源项目的名称（npm codeinspectus、 codeinspectus.com）。“Code Inspect”是一个在拥挤的名称空间中使用的描述性短语； 注册表中可用并不代表已完成商标审查，且该名称不主张为商标。

开发

npm install
npm run build      # tsc --noEmit && tsup  (must compile clean)
npm run eval       # 53 MCP stdio evals across the shipped verification fixtures
npm run inspector  # npx @modelcontextprotocol/inspector node dist/index.js

本仓库的生成方式（可审计的允许列表种子）及端到端构建流程： docs/BUILD.md。

参与贡献

CodeInspectus 是一个由一位网络安全从业者以 Synvoya 名义构建并维护的个人免费开源项目。它背后没有公司，也没有任何待售产品——这正是外部审视至关重要的原因。 我们真心希望获得独立审查，这不是客套话。如果你从事安全工作，你的审视就是贡献。

最需要审查的两个领域：

• 合规 CWE→控制项映射。 这些映射由AI 起草，再由维护者进行策略审查——它们未经独立验证。每条映射都通过三个明确状态进行跟踪：AI 起草 → 维护者策略审查 → 社区验证。目前几乎所有映射都处于前两个状态；社区验证数量为 96 条中的 0 条，我们会如实报告这一点，而不是将其隐藏。 要将映射改为社区验证状态，必须提供证据（控制项主要来源的引文 + 你的依据）——标准和流程见 CONTRIBUTING.md；每条映射的理由和置信度见 docs/COMPLIANCE-RATIONALE.md。
• 检测规则（detection-db/**、src/ai-checks/**、src/packs/**）。欢迎提交新规则、提升精确度的修复以及误报报告。合并标准是精确度： 需提供证明规则能正确检测真阳性的测试样例，以及证明规则不会过度触发的相似但不匹配的测试样例。详情见 CONTRIBUTING.md。

CodeInspectus 声称什么、刻意不声称什么，都有明确记录，方便你在相信某个数字之前先行核查：常设合规免责声明（见上文的 合规框架部分，以及 docs/COMPLIANCE-RATIONALE.md）和三状态诚信指标。如果有内容看起来夸大其词，那就是一个 bug——请提交 issue。

工作流程：fork → branch → PR；维护者负责审查并合并（外部贡献者不会直接推送）。— Synvoya（维护者、网络安全从业者）

适合首次贡献的任务

• 社区验证一个 CWE 到 OWASP Top 10 的映射
• 社区验证一个 CWE 到 SOC 2 或 ISO 27001 的映射

浏览所有适合首次参与的问题。

更新日志

各版本的发布说明见 CHANGELOG.md。

许可证

CodeInspectus 采用 Apache-2.0 许可证。单独下载的引擎仍遵循各自的许可证：Opengrep（LGPL-2.1）、Gitleaks（MIT）和 Trivy（Apache-2.0）。npm 包中不包含引擎二进制文件。版本、版权声明、上游来源和许可证链接详见 THIRD-PARTY-NOTICES.md。 转换后的 Pub 公告快照源自 OSV.dev 记录，这些记录来自 GitHub Advisory Database，并继续采用 CC BY 4.0 许可证；归属信息和转换详情随快照一同附于 detection-db/osv-pub/LICENSE-PROVENANCE.md。