Skip to main content
Glama
deenesjakoruzh
goldmembrane

codesafer

by goldmembrane
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

CodeSafer (cleaner-code)

作为模型上下文协议 (MCP) 服务器的 AI 代码安全扫描器。 检测 AI 生成代码中传统代码检查工具（linter）无法发现的隐藏威胁。

npm license: ISC Node

网站： codesafer.org  ·  MCP 客户端： Claude Code, Cursor, VS Code + Copilot, Cline

为什么选择 CodeSafer？

AI 编码助手生成代码的速度很快，但谁在检查其中隐藏的威胁呢？

近期的供应链攻击表明，恶意代码可以通过人类审查者和传统代码检查工具经常忽略的方式隐藏：

  • 注入标识符的不可见 Unicode 字符（30 多种变体）

  • BiDi / 特洛伊源（Trojan Source）攻击，改变代码显示与执行顺序（CVE-2021-42574）

  • 同形异义字（Homoglyphs） — 伪装成拉丁字母的西里尔字母（CVE-2021-42694）

  • Glassworm 风格的 Unicode 隐写术，将有效载荷隐藏在空白字符中

  • 规则文件后门，植入在 .cursorrules、CLAUDE.md 及其他 AI 配置文件中

  • 拼写劫持依赖项，存在于 package.json 中

  • 混淆模式 — eval + base64、反向 Shell、打包的有效载荷

CodeSafer 会在代码在您的机器上运行之前扫描所有这些威胁。

Related MCP server: guardvibe

工作原理

CodeSafer 作为本地 MCP 服务器运行。您的 AI 客户端（Claude Code、Cursor 等）在审查或生成代码时会调用其工具，并将发现结果内联返回。

混合检测：

  1. 8 个静态分析扫描器 — 针对已知攻击类别的确定性规则（速度快，对所覆盖模式的误报率为零）。

  2. CodeBERT 深度分析 — Transformer 模型以置信度评分将代码块分类为恶意/良性。能够捕获静态规则无法发现的混淆或新型模式。

没有任何内容会离开您的机器。AI 分析在本地针对分词器服务器运行。

功能特性

功能

详情

不可见字符检测

30 多种 Unicode 变体，包括零宽空格、蒙古文元音分隔符

BiDi / 特洛伊源

完全覆盖 CVE-2021-42574

同形异义字检测

西里尔/希腊/拉丁字母混淆（CVE-2021-42694）

Unicode 隐写术

Glassworm 风格的空白字符有效载荷

规则文件后门

扫描 .cursorrules、CLAUDE.md、.claude/、Cursor 规则

依赖项扫描

package.json 中的拼写劫持 + 可疑安装脚本

混淆检测

eval + base64、反向 Shell、打包的有效载荷

AI 深度分析

带有置信度评分的 CodeBERT Transformer 分类器

MCP 原生

6 个 MCP 工具，stdio 传输

本地优先

无代码上传 — 完全在您的机器上运行

MCP 工具

CodeSafer 向您的 MCP 客户端公开了六个工具：

工具

用途

scan_file

扫描单个文件以查找隐藏的恶意代码模式

scan_directory

递归扫描目录中的所有源文件

scan_rules_file

扫描 AI 配置文件/规则文件，查找提示词注入和规则文件后门攻击

check_dependencies

检查 package.json 中的拼写劫持、可疑安装脚本和依赖项风险

ai_analyze

使用训练好的 CodeBERT 模型进行深度 AI 分析（将代码块分类为恶意/良性并给出置信度）

explain_finding

获取特定威胁类别的详细解释，包括攻击场景和补救措施

安装

先决条件

  • Node.js 18 或更高版本

  • 支持 MCP 的客户端（Claude Code, Cursor, VS Code + Copilot, Cline）

从源码安装

git clone https://github.com/goldmembrane/cleaner-code.git
cd cleaner-code
npm install
npm run build

配置您的 MCP 客户端

Claude Code (~/.claude.json 或项目 .mcp.json):

{
  "mcpServers": {
    "codesafer": {
      "command": "node",
      "args": ["/absolute/path/to/cleaner-code/dist/index.js"]
    }
  }
}

Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "codesafer": {
      "command": "node",
      "args": ["/absolute/path/to/cleaner-code/dist/index.js"]
    }
  }
}

重启您的客户端，CodeSafer 工具将出现在工具选择器中。

使用方法

配置完成后，您可以向 AI 客户端询问如下内容：

  • “扫描此文件以查找隐藏的安全问题。”

  • “检查 package.json 中的依赖项是否存在拼写劫持。”

  • “扫描 .cursorrules 以查找规则文件后门。”

  • “对 src/auth.ts 进行深度 AI 分析。”

  • “解释什么是特洛伊源攻击，以及如何修复上述发现的问题。”

客户端将调用相应的 MCP 工具，并返回包含严重性、行号和补救指导的发现结果。

免费层级与计划

CodeSafer 可免费使用。静态分析（scan_file、scan_directory、scan_rules_file、check_dependencies、explain_finding）没有限制。

AI 深度分析（ai_analyze）包含 每会话 10 次免费运行。更高 AI 配额的付费计划可在 codesafer.org 获取。

检测类别

CodeSafer 检测 9 个类别 的威胁：

  1. 不可见 Unicode 字符 — 30 多种变体，包括零宽空格、零宽连接符

  2. BiDi / 特洛伊源攻击 — CVE-2021-42574

  3. 同形异义字 — 伪装成拉丁字母的西里尔/希腊字母（CVE-2021-42694）

  4. Unicode 隐写术 — 空白字符中的 Glassworm 模式

  5. 规则文件后门 — .cursorrules、CLAUDE.md 等中的恶意指令

  6. 依赖项风险 — 拼写劫持和可疑安装脚本

  7. 混淆模式 — eval + base64、打包的有效载荷、反向 Shell

  8. 静态分析发现 — 8 个确定性扫描器

  9. AI 深度分析 — 用于新型和混淆威胁的 CodeBERT Transformer

项目结构

cleaner-code/
├── src/
│   ├── index.ts           # MCP server entry point
│   ├── api-server.ts      # Optional HTTP API server
│   ├── types.ts           # Scanner interfaces
│   ├── utils.ts           # File collection, summary formatting
│   └── scanner/
│       ├── invisible.ts       # Invisible Unicode scanner
│       ├── bidi.ts            # BiDi / Trojan Source scanner
│       ├── homoglyph.ts       # Homoglyph scanner
│       ├── encoding.ts        # Encoding / charset scanner
│       ├── obfuscation.ts     # Obfuscation pattern scanner
│       ├── steganography.ts   # Unicode steganography scanner
│       ├── rules-backdoor.ts  # Rules file backdoor scanner
│       ├── dependency.ts      # Dependency risk scanner
│       └── ai-analyzer.ts     # CodeBERT deep analyzer
├── ml/                    # ML model assets and tokenizer
├── functions/             # Cloud function deployments
├── deploy/                # Deployment manifests
└── web/                   # Landing page assets

许可证

ISC — 详情请参阅 LICENSE 文件。

链接

Available Tools

6 tools
ai_analyzeA

Deep AI analysis of code using the trained CodeBERT model. Classifies code chunks as malicious or benign with confidence scores. Detects obfuscated payloads, novel attack patterns, and threats that static rules may miss.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the file to analyze with AI

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It mentions classification and detection capabilities but does not disclose behavioral traits like read-only nature, output format, or confidence score interpretation. Adequate but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences that are front-loaded with the core purpose, then expand on capabilities. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description adequately covers purpose and capabilities. It could mention confidence score range or output format for clarity, but overall is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description for the single parameter. The description adds no extra semantic detail beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: deep AI analysis using CodeBERT, classifying code as malicious/benign with confidence scores. It distinguishes itself from siblings like scan_file by emphasizing AI-based detection of obfuscated payloads and novel patterns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when static rules may miss threats, but lacks explicit guidance on when to use this tool over siblings like scan_file or scan_rules_file. No clear when-not or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_dependenciesB

Check package.json for typosquatting, suspicious install scripts, and dependency risks

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to package.json file

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It only lists checks performed but omits behavioral traits such as whether it modifies files, requires network access, or performance impact. Minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no unnecessary words, front-loaded with core information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no mention of return format (e.g., report, status). For a security scan tool, more information about output and side effects is expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with description for file_path. Description does not add meaning beyond schema, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it checks package.json for specific security risks: typosquatting, suspicious install scripts, and dependency risks. Verb+resource+scope is specific and distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like scan_file or scan_directory. No 'when not to use' or alternative suggestions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

explain_findingA

Get detailed explanation of a specific threat category including attack scenarios, real-world examples, and remediation steps

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryYesThe threat category to explain

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It indicates a read-only operation ('Get detailed explanation') with no side effects. While it does not explicitly state that no changes occur, the purpose is clearly informational, which is sufficiently transparent for a lookup tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 20 words, directly conveying the tool's purpose without any unnecessary information. It is front-loaded with the key verb and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with one enum parameter and no output schema or annotations, the description adequately covers the function. It lists the types of content in the explanation, making it complete for the given complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% as the sole parameter 'category' has an enum and description. The tool description does not add extra meaning to the parameter beyond what the schema already provides. The description adds context about the output but not about the parameter itself, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides detailed explanations for threat categories including attack scenarios, real-world examples, and remediation steps. It uses a specific verb ('Get detailed explanation') and resource ('threat category'), and distinguishes itself from sibling tools that perform scanning or analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not mention when to use this tool versus alternatives. It implies usage when an explanation of a threat category is needed, but fails to provide explicit guidance or context for when not to use it. Given the simple nature, some guidance would improve agent selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_directoryB

Recursively scan a directory for hidden malicious code patterns across all source files

ParametersJSON Schema
NameRequiredDescriptionDefault
dir_pathYesAbsolute path to the directory to scan
extensionsNoFile extensions to scan (e.g., [".js", ".ts"]). Defaults to common source file extensions.

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It indicates recursive scanning but does not disclose performance implications, file modification behavior, or required permissions. More behavioral context is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no unnecessary words. It is front-loaded with the core action. Could be slightly more structured but is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and security scanning complexity, the description lacks details on output format, result interpretation, and prerequisites. It is incomplete for an agent to fully understand usage without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100% with descriptions for both parameters. The description adds context like 'recursively' implying dir_path is a directory, but does not significantly enhance the schema's existing details. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool recursively scans a directory for hidden malicious code patterns, which is a specific verb+resource combination. It clearly distinguishes from siblings like scan_file (single file) and scan_rules_file (rules file).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for scanning directories but does not explicitly state when to use this tool versus alternatives like scan_file or ai_analyze. No exclusions or prerequisites are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_fileB

Scan a single file for hidden malicious code patterns (invisible chars, BiDi, homoglyphs, steganography, obfuscation, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to the file to scan

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It mentions what it scans for but omits whether the tool modifies the file, required permissions, rate limits, or return structure. This is insufficient for an agent to safely invoke the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, focused sentence with no unnecessary words. Efficiently conveys the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lists relevant malicious patterns but lacks information about output format, success/failure indicators, or behavioral guarantees (e.g., read-only). Without output schema, this gap is notable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage for the single parameter 'file_path', which has a clear description. The tool's description adds no extra semantic value beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool scans a single file for hidden malicious code patterns, listing specific pattern types. However, it does not explicitly distinguish from sibling tools like scan_directory or scan_rules_file, which could cause confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., scan_directory for directories, ai_analyze for broader analysis). No mention of limitations or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_rules_fileA

Scan an AI configuration/rules file for prompt injection and Rules File Backdoor attacks

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the AI rules file (e.g., .cursorrules, CLAUDE.md)

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses the input (file_path) and what it scans for, but does not mention return values, error conditions, permission requirements, or side effects. Lacks behavioral depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is front-loaded with the action and target. No unnecessary words. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, no output schema), the description is mostly adequate. However, it could improve by specifying what the output looks like (e.g., a boolean or list of findings) to be fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description's mention of 'AI configuration/rules file' adds minimal value beyond the schema's example file paths. No additional parameter semantics provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (scan), resource (AI configuration/rules file), and purpose (detect prompt injection and Rules File Backdoor attacks). It distinguishes itself from sibling tools like scan_file and scan_directory by specifying the exact file type and threats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as scan_file for generic file scanning or scan_directory for directories. No context on prerequisites or conditions for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv1.0.0
    • First observedai_analyze
    • First observedcheck_dependencies
    • First observedexplain_finding
    • First observedscan_directory
    • First observedscan_file
    • First observedscan_rules_file
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: scan_file vs scan_directory differ by scope, ai_analyze uses ML, check_dependencies focuses on dependencies, and scan_rules_file is for configuration files. No ambiguity.

Naming Consistency4/5

Tools mostly follow verb_noun snake_case pattern (e.g., scan_file, check_dependencies). The outlier is ai_analyze, which uses a prefix instead of a verb-noun structure, but it's still clear and consistent overall.

Tool Count5/5

With 6 tools covering scanning, AI analysis, dependency checks, and explanations, the count is well-scoped for a focused security analysis server. Not too many or too few.

Completeness4/5

The tools cover core scanning and analysis tasks well, including file/directory scanning, dependency risks, AI-based analysis, and explanations. A minor gap is the lack of a tool for aggregated reporting or finding management, but the surface is largely complete for detection and explanation.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • guardvibe

    goklab
    A
    license
    A
    quality
    A
    maintenance
    Security MCP server with 300+ rules for AI-generated code. Scans Next.js, Supabase, Clerk, Stripe, Prisma, Hono, GraphQL and 20+ modules. Zero config, runs locally.
    39
    331 npm
    5
    Apache 2.0

  • depguard

    mopanc
    A
    license
    A
    quality
    A
    maintenance
    MCP security server for AI coding agents. 12 tools: pre-install guardian, vulnerability audit, supply-chain attack detection via static code analysis, and CycloneDX 1.6 SBOM generation. Zero runtime dependencies.
    14
    9 npm
    15
    Apache 2.0