Skip to main content
Glama
deenesjakoruzh
goldmembrane

codesafer

by goldmembrane
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

CodeSafer (cleaner-code)

Model Context Protocol (MCP) サーバーとして動作するAIコードセキュリティスキャナー。 従来のリンターでは見逃される、AI生成コード内の隠れた脅威を検出します。

npm license: ISC Node

ウェブサイト: codesafer.org  ·  MCPクライアント: Claude Code, Cursor, VS Code + Copilot, Cline

CodeSaferを選ぶ理由

AIコーディングアシスタントは高速にコードを生成しますが、その中に隠れた脅威がないか誰がチェックしているのでしょうか？

近年のサプライチェーン攻撃では、人間のレビューアや従来のリンターが日常的に見逃してしまうような方法で悪意のあるコードが隠されることが明らかになっています：

  • 不可視のUnicode文字：識別子に注入される（30種類以上）

  • BiDi / Trojan Source攻撃：コードの表示順序と実行順序を入れ替える（CVE-2021-42574）

  • ホモグラフ：ラテン文字になりすましたキリル文字など（CVE-2021-42694）

  • Glassworm形式のUnicodeステガノグラフィ：空白文字にペイロードを隠蔽

  • ルールファイルのバックドア：.cursorrules、CLAUDE.md、その他のAI設定ファイルに仕込まれる

  • タイポスクワッティングされた依存関係：package.json内

  • 難読化パターン：eval + base64、リバースシェル、パックされたペイロード

CodeSaferは、コードがマシン上で実行される前に、これらすべてをスキャンします。

Related MCP server: guardvibe

仕組み

CodeSaferはローカルのMCPサーバーとして動作します。AIクライアント（Claude Code、Cursorなど）がコードのレビューや生成を行う際にツールを呼び出し、結果がインラインで返されます。

ハイブリッド検出:

  1. 8つの静的解析スキャナー — 既知の攻撃カテゴリに対する決定論的なルール（高速で、対象パターンに対する偽陰性はゼロ）。

  2. CodeBERTディープ解析 — トランスフォーマーモデルがコードチャンクを悪意のあるものか良性のものか、信頼スコア付きで分類。静的ルールでは見逃される難読化されたパターンや新しいパターンを捕捉します。

データがマシンから外部へ送信されることはありません。AI解析はローカルのトークナイザーサーバーに対して実行されます。

機能

機能

詳細

不可視文字検出

ゼロ幅スペース、モンゴル語母音分離記号を含む30以上のUnicodeバリアント

BiDi / Trojan Source

CVE-2021-42574を完全網羅

ホモグラフ検出

キリル文字/ギリシャ文字/ラテン文字の混同（CVE-2021-42694）

Unicodeステガノグラフィ

Glassworm形式の空白文字ペイロード

ルールファイルのバックドア

.cursorrules、CLAUDE.md、.claude/、Cursorルールをスキャン

依存関係スキャン

package.json内のタイポスクワッティングと不審なインストールスクリプト

難読化検出

eval + base64、リバースシェル、パックされたペイロード

AIディープ解析

信頼スコア付きのCodeBERTトランスフォーマー分類器

MCPネイティブ

6つのMCPツール、stdioトランスポート

ローカルファースト

コードのアップロードなし — すべてマシン上で実行

MCPツール

CodeSaferはMCPクライアントに対して6つのツールを提供します：

ツール

目的

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ディープ解析を実行して。"

  • "Trojan Source攻撃とは何か、そして上記の検出結果をどう修正すればよいか説明して。"

クライアントは適切な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 / Trojan Source攻撃 — CVE-2021-42574

  3. ホモグラフ — ラテン文字になりすましたキリル文字/ギリシャ文字（CVE-2021-42694）

  4. Unicodeステガノグラフィ — 空白文字内のGlasswormパターン

  5. ルールファイルのバックドア — .cursorrules、CLAUDE.md等に含まれる悪意のある指示

  6. 依存関係のリスク — タイポスクワッティングおよび不審なインストールスクリプト

  7. 難読化パターン — eval + base64、パックされたペイロード、リバースシェル

  8. 静的解析結果 — 8つの決定論的スキャナー

  9. AIディープ解析 — 新規および難読化された脅威に対するCodeBERTトランスフォーマー

プロジェクト構造

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