npm 패키지 종속성의 보안 취약점을 감사하는 강력한 MCP(모델 컨텍스트 프로토콜) 서버입니다. 실시간 보안 점검을 위해 원격 npm 레지스트리 통합 기능을 내장하고 있습니다.
🔍 실시간 보안 취약점 스캐닝
🚀 원격 npm 레지스트리 통합
📊 심각도 수준이 포함된 자세한 취약성 보고서
🛡️ 다양한 심각도 수준 지원(중요, 높음, 보통, 낮음)
📦 npm/pnpm/yarn 패키지 관리자와 호환
🔄 자동 수정 권장 사항
📋 CVSS 점수 및 CVE 참조
Smithery를 통해 Claude Desktop용 Security Audit Tool을 자동으로 설치하려면:
지엑스피1
Cline/Cursor에 MCP 구성 추가:
{
"mcpServers": {
"mcp-security-audit": {
"command": "npx",
"args": ["-y", "mcp-security-audit"]
}
}
}저장소를 복제합니다.
git clone https://github.com/qianniuspace/mcp-security-audit.git
cd mcp-security-audit종속성을 설치하고 빌드합니다.
npm install
npm run buildCline/Cursor에 MCP 구성 추가:
{
"mcpServers": {
"mcp-security-audit": {
"command": "npx",
"args": ["-y", "/path/to/mcp-security-audit/build/index.js"]
}
}
}Related MCP server: audit-mcp-cli
이 도구는 심각도 수준, 수정 권장 사항, CVSS 점수, CVE 참조를 포함한 자세한 취약성 정보를 제공합니다.
{
"content": [{
"vulnerability": {
"packageName": "lodash",
"version": "4.17.15",
"severity": "high",
"description": "Prototype Pollution in lodash",
"cve": "CVE-2020-8203",
"githubAdvisoryId": "GHSA-p6mc-m468-83gw",
"recommendation": "Upgrade to version 4.17.19 or later",
"fixAvailable": true,
"fixedVersion": "4.17.19",
"cvss": {
"score": 7.4,
"vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N"
},
"cwe": ["CWE-1321"],
"url": "https://github.com/advisories/GHSA-p6mc-m468-83gw"
},
"metadata": {
"timestamp": "2024-04-23T10:00:00.000Z",
"packageManager": "npm"
}
}]
}{
"content": [{
"vulnerability": null,
"metadata": {
"timestamp": "2024-04-23T10:00:00.000Z",
"packageManager": "npm",
"message": "No known vulnerabilities found"
}
}]
}개발 참고를 위해 public 디렉토리에 있는 예제 응답 파일을 확인하세요.
Severity-response.json : 취약점이 발견되었을 때의 응답 예시(npm 감사 API 응답에서 변환됨)
no-Severity-response.json : 취약점이 발견되지 않았을 때의 응답 예시(npm 감사 API 응답에서 변환)
참고: 위에 표시된 예시 응답은 더 구조화된 형식을 제공하기 위해 npm 감사 API의 원시 응답을 변환한 것입니다. 원본 npm 감사 API 응답에는 추가 메타데이터가 포함되어 있으며 구조가 다를 수 있습니다.
기여를 환영합니다! 행동 강령과 풀 리퀘스트 제출 절차에 대한 자세한 내용은 기여 가이드를 참조하세요.
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
ESX ( qianniuspace@gmail.com )
Audit specific dependencies for vulnerabilities
| Name | Required | Description | Default |
|---|---|---|---|
| dependencies | Yes | Dependencies object from package.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to mention whether the operation is read-only, requires network access, or what happens with the dependencies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, no unnecessary words. It is concise but slightly under-informative for its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and minimal description leave the return value and behavior undocumented. The nested object type is not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameter. The tool description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits dependencies for vulnerabilities, using a verb-object structure. However, without sibling tools, differentiation is not necessary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use the tool, prerequisites, or alternatives. The description assumes the agent knows the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0audit_nodejs_dependenciesScored across 1 tool
With only one tool, there is no possibility of confusion between tools. The tool's purpose is clearly stated in its name and description, making it unambiguous.
A single tool name follows a clear verb_noun pattern (audit_nodejs_dependencies) which is consistent with typical MCP naming conventions. There are no other names to compare, but the pattern is clear.
Having only one tool is extremely thin for a security audit server. Auditing dependencies likely requires supporting operations like resolving dependency trees, checking for updates, or generating reports, which are missing.
The server's purpose appears to be auditing Node.js dependencies, but it only offers a single operation that audits dependencies without coverage for other lifecycle steps like viewing audit results, fixing vulnerabilities, or scanning different scopes.
Detect malicious or vulnerable npm packages: registry search, OSV.dev and GitHub advisory lookups
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Query OSV.dev for package vulnerabilities and batch-audit dependency lists via MCP.
Dive into the world of npm with our NPM Package Info MCP. Access crucial metadata about any npm