GoThreatScope MCP Server

GoThreatScope

GoThreatScope is a modular, educational security toolchain written in Go.
It generates a lightweight SBOM, checks dependencies against osv.dev for vulnerabilities and known malicious packages, scans for hardcoded secrets (using Gitleaks when available, or a builtin fallback), and records metrics for each run (using pipedream).

This tool also acts as a Model Context Protocol (MCP) server, allowing IDEs such as Cursor or Visual Studio Code to query its results using natural language.
For example, you can ask:

"Analyze my project and show me which dependencies look risky."

The MCP interface exposes tools and resources so other systems or LLMs can retrieve structured SBOMs, vulnerability reports, and secret findings directly from the local filesystem.

Overview

GoThreatScope performs an high-level security inspection of a project directory and organizes the results for both human and automated analysis.

It combines several capabilities into a single workflow:

• SBOM generation: creates a simple inventory of project dependencies.
• Vulnerability and malware detection: checks each dependency against osv.dev to identify known vulnerabilities and malicious packages.
• Secrets detection: searches for API keys, passwords, and private tokens using Gitleaks or a simple builtin fallback scanner.
• Metrics collection: stores structured metrics for every run, allowing comparison between scans (configured with pipedream).

Each module works independently or as part of the analyze pipeline.
All results are stored locally under gothreatscope_store/ and reused when no changes are detected.

Architecture

GoThreatScope is organized into clear, modular packages.
Each package handles a specific security function or integration point, making the tool easy to extend or reuse in other projects.

GoThreatScope
│
├── cmd/gothreatscope/         # CLI entrypoint and MCP server mode
│   └── main.go                # CLI commands and MCP wiring
│
├── pkg/
│   ├── sbom/                  # SBOM generation logic
│   ├── vuln/                  # OSV-based vulnerability and malware detection
│   ├── secrets/               # Gitleaks and builtin secret scanner
│   ├── analysis/              # Full pipeline and storage/diff logic
│   ├── metrics/               # Local and remote metrics sender
│   └── mcp/                   # MCP tools and resources implementation
│
└── gothreatscope_store/       # Automatically generated per-project store
    └── /
        ├── latest/
        │   ├── sbom.json
        │   ├── vuln.json
        │   ├── secrets.json
        │   ├── metrics.json
        │   └── bundle.json
        └── history/<run_id>/

Each project scanned by GoThreatScope receives its own identifier, derived from the SHA-256 hash of its absolute path. All results are written into that project’s folder under gothreatscope_store/, and new files are only created when differences are detected compared to the previous run.

How It Works

GoThreatScope operates through independent modules that can run individually or together as part of a complete analysis pipeline.

1. Project identification

Every scanned project is assigned a unique identifier derived from the SHA-256 hash of its absolute path.
This ensures consistent tracking across runs without revealing directory names.

2. Persistent storage

Scan results are stored under the gothreatscope_store/ directory, grouped by project ID.
Each module writes its own JSON artifact inside a latest/ folder, and keeps a short history of past results.

gothreatscope_store/
└── a93bf44e3e9c/
    ├── latest/
    │   ├── sbom.json
    │   ├── vuln.json
    │   ├── secrets.json
    │   └── metrics.json
    └── history/20251007T215959Z/

3. Change detection

Before saving, GoThreatScope compares digests (hashes) of the new results with those from the previous run. If there are no changes, the stored files remain untouched, avoiding redundant writes and unnecessary history entries.

4. Metrics and telemetry

Each scan produces a metrics.json file summarizing timing, findings