# mcp-supply-chain-check

Ein [MCP](https://modelcontextprotocol.io)-Server, der Coding-Agenten (z. B.
Claude Code) einen Supply-Chain-/SBOM-Sicherheitscheck für
Projektabhängigkeiten als Tool bereitstellt — gegen die öffentliche,
kostenlose [OSV.dev](https://osv.dev)-Advisory-Datenbank, ohne API-Key.

Zwei Tools:

1. **`check_package`** — prüft ein einzelnes Paket (Ecosystem, Name, optional
   Version) gegen OSV.dev und gibt gefundene Advisories mit einer
   Kurz-Einschätzung zurück.
2. **`check_sbom`** — liest eine lokale CycloneDX- oder SPDX-JSON-SBOM-Datei,
   prüft alle enthaltenen Komponenten in einer Batch-Abfrage gegen OSV.dev und
   gibt eine nach Advisory-Anzahl sortierte Liste betroffener Komponenten
   zurück.

## Installation

```bash
npm install
```

Voraussetzung: Node.js >= 18. Benötigt Internetzugriff auf `api.osv.dev`,
sonst keine Abhängigkeit zu Drittdiensten oder internen Systemen.

### In Claude Code registrieren

```bash
claude mcp add supply-chain-check -- node /pfad/zu/mcp-supply-chain-check/src/index.js
```

Alternativ nach `npm install -g .` über den Bin-Eintrag:

```bash
claude mcp add supply-chain-check -- mcp-supply-chain-check
```

Der Server spricht ausschließlich stdio (kein HTTP-Port, keine offene
Netzwerk-Schnittstelle außer dem ausgehenden Aufruf an `api.osv.dev`).

## Beispiel-Aufrufe

### `check_package`

```json
{ "ecosystem": "npm", "name": "lodash", "version": "4.17.15" }
```

liefert u. a.:

```
npm/lodash@4.17.15: 1 Advisory(s) gefunden — Einschätzung: unauffällig
- GHSA-29mw-wpgm-hmr9 [MODERATE]: Regular Expression Denial of Service (ReDoS) in lodash (aliases: CVE-2020-28500)
```

`ecosystem` folgt den [OSV.dev-Ecosystem-Namen](https://google.github.io/osv.dev/ecosystems/)
(`npm`, `PyPI`, `Go`, `crates.io`, `Maven`, `RubyGems`, `NuGet`, `Packagist`, …).
`version` ist optional; ohne Angabe werden alle bekannten Advisories des
Pakets über alle Versionen hinweg gemeldet.

### `check_sbom`

```json
{ "path": "/pfad/zu/sbom.cdx.json" }
```

liefert eine nach Advisory-Anzahl sortierte Liste betroffener Komponenten,
plus Hinweis auf übersprungene Komponenten (kein erkennbares Ecosystem/purl)
und auf Kürzung, wenn die SBOM mehr als 200 Komponenten enthält.
Unterstützt werden CycloneDX (`components[].name`/`version`/`purl`) und SPDX
(`packages[].name`/`versionInfo`, Ecosystem-Erkennung über `externalRefs[].referenceType: "purl"`).

## Einschätzung

Die Kurz-Einschätzung ist `kritisch`, wenn mindestens eine Advisory als
`HIGH`/`CRITICAL` eingestuft ist oder mehr als eine Advisory gefunden wurde,
sonst `unauffällig`. Das ist eine grobe Heuristik für einen schnellen
Überblick, kein CVSS-Scoring — die vollständigen Advisory-Daten (inkl. aller
Referenzen) stehen über die zurückgegebenen IDs auf [osv.dev](https://osv.dev)
zur Verfügung.

## Transparenz: Rechte und Datenfluss

Der Server läuft als lokaler stdio-Prozess mit genau den
Dateisystemrechten des aufrufenden Agenten/Clients (z. B. Claude Code) —
er kann nichts lesen, was dieser Prozess nicht auch lesen könnte, und
erweitert dessen Zugriff nicht.

Bei `check_sbom` werden aus der lokal gelesenen SBOM-Datei Paketname,
Version und Ecosystem je Komponente extrahiert und zur Abfrage an die
externe OSV.dev-API (`api.osv.dev`) gesendet — nicht der Dateiinhalt oder
der Dateipfad selbst, aber die darin enthaltenen Komponentenangaben
verlassen damit die lokale Maschine. Wer das nicht möchte (z. B. bei
SBOMs mit sensiblen internen Paketnamen), sollte den Server nicht gegen
solche Dateien laufen lassen.

## Datenquelle

Alle Daten stammen von [OSV.dev](https://osv.dev), dem offenen,
kostenlosen Schwachstellen-Datenbank-Aggregator von Google
(Daten lizenziert unter CC-BY 4.0). Dieses Projekt steht in keiner
Verbindung zu Google oder OSV.dev und ist kein offizielles Produkt davon.

## Tests

```bash
npm test
```

Läuft mit Node's eingebautem `node:test`, keine echten Netzwerkaufrufe
(OSV-Antworten werden in den Tests gemockt).

## Lizenz

MIT, siehe [LICENSE](LICENSE).