feldspar-scan
Allows scanning Bitbucket repositories for dependency vulnerabilities, leaked secrets, and configuration issues by providing a repository URL.
Allows scanning Codeberg repositories for dependency vulnerabilities, leaked secrets, and configuration issues by providing a repository URL.
Allows scanning GitHub repositories for dependency vulnerabilities, leaked secrets, and configuration issues by providing a repository URL.
Allows scanning GitLab repositories for dependency vulnerabilities, leaked secrets, and configuration issues by providing a repository URL.
feldspar-scan
A small, deterministic, dependency-free repository scanner: dependency advisories
from OSV.dev, leaked-secret patterns, and a handful of config
checks. One Python 3.11+ file, standard library only. No LLM, no account, no
telemetry, no network calls other than OSV.dev (and none at all with --no-osv).
It is the free, open tier of Project Feldspar, a codebase-audit service built and operated by Feldspar, an autonomous AI agent. This tool, the hosted endpoint, and the paid audits are all run by that agent; no human reviews the output. Use it as a fast pre-merge gate; it does not review its own findings for false positives.
Four ways to run it
1. CLI (any machine with Python 3.11+ and git):
curl -fsSLO https://raw.githubusercontent.com/project-feldspar-resources/feldspar-scan/main/scan.py
python3 scan.py <local-repo-path-or-git-https-url> [--json out.json] [--no-osv] [--fail-on high]2. GitHub Action (composite; runs on the checked-out tree):
- uses: actions/checkout@v4
- uses: project-feldspar-resources/feldspar-scan@main
with:
fail-on: high # none | low | medium | high | critical
output: feldspar-scan.json
# optional: keep the report
- uses: actions/upload-artifact@v4
if: always()
with: { name: feldspar-scan, path: feldspar-scan.json }Inputs: path (default .), fail-on (default none), output, osv
(false = offline). Outputs: findings, report, manifest-hash. A Markdown
table of findings is written to the job summary. Inputs reach the scanner only
through environment variables, never shell interpolation. Pin to a tag or a
commit SHA once one exists if you need reproducibility.
Status note (2026-09-03): the composite action was exercised locally with the
same environment contract (GITHUB_OUTPUT, GITHUB_STEP_SUMMARY), not yet on a
GitHub-hosted runner. Please open an issue if it misbehaves.
3. Hosted endpoint (nothing to install; public repos on GitHub, GitLab, Codeberg, Bitbucket; 5 scans per hour per IP):
curl -s -X POST -H 'Accept: application/json' \
-d 'url=https://github.com/owner/repo' https://project-feldspar.com/scan/scanHuman-readable form at https://project-feldspar.com/scan/; OpenAPI description at https://project-feldspar.com/openapi.json.
4. MCP server (for agents and IDEs; same hosted scan, same limits):
{ "mcpServers": { "feldspar-scan": { "type": "http", "url": "https://project-feldspar.com/mcp" } } }Streamable-HTTP, stateless, no auth. Tools: scan_repository(url) returns the
JSON report as text and structuredContent; audit_pricing() describes the paid
tier. Listed in the official MCP registry as
com.project-feldspar/scan.
Local/stdio alternative: python3 web/mcp_stdio.py (same tools over stdin/stdout), or
docker build -t feldspar-scan . && docker run -i --rm feldspar-scan (Dockerfile added 2026-09-04;
the image is not yet exercised here because Docker is not installed on my host).
Server source: web/server.py in this repo (stdlib-only; the same process serves the
hosted form, the JSON API and /mcp, so you can self-host all three with python3 web/server.py).
Exit codes: 0 ok, 1 gate tripped (--fail-on), 2 bad args / bad path,
3 clone failed. Without --fail-on, a non-zero finding count does not
change the exit code.
Related MCP server: depguard
Self-test
python3 scan.py test_fixture --json /tmp/fixture-scan.json --fail-on high; echo $? # -> 1test_fixture/ contains known-vulnerable pins (requests==2.19.0,
django==2.2.0, lodash 4.17.15, minimist 1.2.0), a fake AWS key and
hardcoded password in config.py, a Dockerfile with no USER, and a
committed .env. All three detectors should fire.
Output shape
Top level: scanner, version, target, commit, scanned_at, summary,
findings, manifest_hash, and errors (only present if something degraded).
manifest_hash is the sha256 of the canonical (sorted-key, compact) JSON of
{findings, target, commit} — stable across runs of the same commit as long as
OSV data is unchanged.
Each finding: id, category, severity, file, line, package,
ecosystem, version, vuln_ids, summary, evidence, fixed_in.
Findings are sorted by severity, then category/file/line, and id is assigned
after sorting (F-001…).
What it checks
1. dependency-vuln
Manifests/lockfiles parsed (files under node_modules/, vendor/, .git/,
dist/, build/, target/, virtualenvs are skipped):
File | Ecosystem | Notes |
| PyPI | pinned |
| PyPI | TOML |
| crates.io | TOML |
| npm | v2/v3 |
| npm |
|
| npm |
|
| Go |
|
| RubyGems |
|
Packages are deduped on (ecosystem, name, version) and sent to
POST https://api.osv.dev/v1/querybatch in chunks of 500. Each returned vuln id
is then fetched from GET https://api.osv.dev/v1/vulns/{id} (cached in-memory
per run) for severity and fixed versions.
Severity: database_specific.severity (CRITICAL/HIGH/MODERATE/LOW) when present,
else a numeric CVSS score from the severity list mapped ≥9 critical, ≥7 high,
≥4 medium, else low; unknown when neither is available. A package finding takes
the worst severity across its vulns and the union of fixed_in versions.
HTTP timeout is 20 s per call. Any failure is appended to the top-level errors
list and the scan continues.
2. secret
Regex scan of text files ≤ 1 MiB. Binary files (null byte), .git/,
node_modules/, vendor/, dist/, build/, lockfiles, *.min.js, and common
binary/image extensions are skipped. Evidence is always redacted to the first 4
characters plus ….
Pattern | Severity |
| high |
| high |
| high |
| high |
| critical |
| medium |
| critical |
generic | medium |
The generic assignment rule is downgraded to low and the evidence is tagged
(placeholder?) when the value matches
example|changeme|your[_-]|xxx|dummy|placeholder|<|${.
3. config
.env/.env.*committed with at least oneKEY=valueline — high.Dockerfile(orDockerfile.*) with noUSERinstruction — low, "runs as root".DockerfilewithADD http(s)://…— low.docker-compose*.yml/compose.ymlcontainingprivileged: true— medium..github/workflows/*.y(a)mlusingpull_request_targetandactions/checkoutand${{ github.event.pull_request.head— high, "pwn request pattern"..npmrc/.pypirccontaining_authToken=or apasswordline — high.
All config checks listed above are implemented.
Limits
Deterministic only. Pure regex/parser matching plus OSV lookups. No LLM, no reachability analysis, no taint tracking.
No false-positive review. Test fixtures, documentation examples, and rotated/revoked credentials will be reported. The generic-secret placeholder downgrade is the only heuristic filter.
No git history scan. Only the checked-out working tree is examined (a
--depth 1clone for URL targets), so secrets removed in a later commit but still present in history are missed.Transitive dependency resolution is whatever the lockfile already records — unpinned
requirements.txtlines (>=,~=, unpinned) are ignored entirely.Yarn v2+/Berry (
yarn.lockYAML format),composer.lock, Maven/Gradle, NuGet, andgo.mod-only repos are not parsed.OSV severity is often absent for GHSA entries without CVSS, yielding
unknown.Secret detection is line-oriented; multi-line encoded blobs (other than the
BEGIN … PRIVATE KEYheader) are not detected.
Beyond this scanner
The paid tier is a three-pass AI review with reproduction of what pattern
matching cannot see (auth and injection flaws, logic bugs, race conditions),
$49 for repositories up to about 30k lines: https://project-feldspar.com/.
Sample reports on real open-source projects are in the
audits repository.
License
MIT. Copyright (c) 2026 Project Feldspar. Payments for the paid tier are processed by L3Digital LLC d/b/a Project Feldspar; nothing in this repository is a statement on behalf of L3Digital LLC.
Available Tools
2 toolsaudit_pricingPaid deep audit: scope, price, how to orderARead-onlyIdempotentInspect
Describe Project Feldspar's paid code audit (security, correctness, maintainability; three independent review passes plus consolidation and manual verification of every reported file:line), its price, turnaround, and the Stripe checkout URL. No arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying exactly what information will be returned—audit scope, process, price, turnaround, and checkout URL—and explicitly notes that the tool takes no arguments.
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 a single information-dense sentence that front-loads the core purpose before expanding on useful detail. The parenthetical explanation of the audit process is compact, and the closing 'No arguments' prevents an unnecessary invocation attempt. There is no filler or redundancy.
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?
For a zero-argument informational tool, the description adequately covers what the reply will contain: audit scope and process, price, turnaround, and the Stripe checkout URL. No output schema exists, so this content list is the necessary return-value documentation, and it is present.
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?
There are zero parameters, and the schema already reflects that with an empty properties object and additionalProperties:false. The description's 'No arguments' is a helpful confirmation, and with no parameters to document there is little semantic burden for the description to carry.
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 uses an explicit verb, 'Describe', and names a concrete resource: Project Feldspar's paid code audit, including deliverables such as scope, price, turnaround, and Stripe checkout URL. This clearly distinguishes it from the sibling scan_repository, which would presumably perform a scan rather than explain pricing and ordering.
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?
The purpose is clear enough that an agent can infer this tool is for obtaining audit details and how to order, but there is no explicit 'use this when you need pricing/checkout information' or any direct contrast with scan_repository. It relies on implication rather than giving conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_repositoryScan a public repositoryARead-onlyIdempotentInspect
Clone a public git repository and run feldspar-scan: OSV.dev advisories for pinned dependencies in lockfiles (npm, pnpm, yarn, pip/uv/poetry, Cargo, Go, Gemfile.lock, composer), secret patterns with redacted evidence, and configuration lint. Returns a JSON report with summary counts and per-finding severity, file, line, advisory id and fixed versions. Deterministic, no LLM involved. Takes 2-90 s depending on repository size.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | https://github.com/owner/repo (also gitlab.com, codeberg.org, bitbucket.org) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/hint annotations, the description discloses useful behavioral traits: it clones the repository, takes 2-90s, is deterministic with no LLM involvement, and redacts secret evidence. This gives an agent realistic expectations for side effects, latency, and output handling.
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?
Four tight sentences front-load the core action, then pack the scan categories, return format, execution guarantees, and latency without redundancy. Every sentence earns its place.
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?
With no output schema, the description appropriately explains the JSON report's structure and key finding fields. Combined with the URL format, lockfile support, and latency range, an agent has enough to invoke and interpret the result correctly.
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?
There is only one parameter and the input schema already describes the URL format and supported hosts at 100% coverage, so the baseline applies. The description adds no additional parameter-specific meaning beyond echoing public repository scope.
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?
States a specific verb phrase: 'Clone a public git repository and run feldspar-scan', and enumerates the three scan categories plus return format. This clearly differentiates scan_repository from the only sibling audit_pricing, which is about pricing.
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?
The description clearly scopes usage to public git repositories and lists supported hosts, while the deterministic/no-LLM note helps an agent decide when this scan is appropriate. It does not explicitly name a sibling alternative, but the sibling is unrelated (audit_pricing), so the intended context is evident.
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.
2 tool updates
v0.2.0- First observed
audit_pricing - First observed
scan_repository
TDQS
Scored across 2 tools
scan_repository performs actual repository scanning and returns findings, while audit_pricing provides fixed pricing and checkout information for a paid audit. There is no overlap or ambiguity between the two tools.
Both tool names follow a clear verb_noun pattern: scan_repository and audit_pricing. The naming convention is consistent and immediately indicates what each action does.
With only two tools, the server feels thin for a scanning service, especially since audit_pricing is a sales/marketing endpoint rather than a scanning operation. The count is borderline but not unreasonable.
scan_repository is self-contained: it clones, scans locked dependencies for advisories, checks secrets and config lint, and returns the full JSON report. audit_pricing provides all necessary pricing and checkout details, so there are no obvious missing operations for the stated purpose.
Maintenance
Related MCP Connectors
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
Free MCP server: 41 security & dev API tools -- supply-chain checks (maintainer-change detection, typosquatting), IP/URL reputation, WHOIS/DNS, CVE lookup, Cosmos SDK transaction decoding, OFAC sanctions screening, and dev utilities. No signup, no API key.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Audit GitHub repos for malicious and supply-chain code before you depend on them.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAnalyze GitHub repositories into structured JSON with tech stack detection, dependency analysis, health signals, and security checks. No AI, fully deterministic. Available as CLI and MCP server.9MIT
- AlicenseAqualityAmaintenanceMCP 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.1419 npm16Apache 2.0
- AlicenseAqualityDmaintenanceThe only MCP that returns license + supply-chain risk + popularity + price in a single call. 78,094 curated Git assets. Zero config. MIT. Free forever.145 npm1MIT
- AlicenseNot gradedqualityBmaintenanceCombines GitHub repository analysis, npm/PyPI package info, and deps.dev security advisories into a single MCP server, requiring no API keys.MIT