Proof of Commitment

Sterne lügen. Verhaltenssignale nicht.

Ein MCP-Server und Web-Tool, das npm-Pakete, PyPI-Pakete und GitHub-Repos nach verhaltensbezogenem Engagement bewertet — Signale, die schwerer zu fälschen sind als Sterne, READMEs oder Download-Zahlen.

Das Problem der Lieferkette

Drei Pakete in einem typischen Node.js-Projekt sind derzeit KRITISCH:

• chalk — 399 Mio. Downloads/Woche, 1 Betreuer

• zod — 139 Mio. Downloads/Woche, 1 Betreuer

• axios — 96 Mio. Downloads/Woche, 1 Betreuer (Angriff am 1. April 2026)

Sterne und README-Qualität zeigen dies nicht auf. Verhaltenssignale schon.

Jetzt ausprobieren

Terminal (keine Installation):

npx proof-of-commitment axios zod chalk
# or scan your own project:
npx proof-of-commitment --file package.json
# PyPI too:
npx proof-of-commitment --pypi litellm langchain requests

Web-Demo (keine Installation): getcommit.dev/audit — fügen Sie Ihre Pakete ein und sehen Sie die Risikobewertungen in Sekunden.

MCP-Server (keine Installation):

{
  "mcpServers": {
    "proof-of-commitment": {
      "type": "streamable-http",
      "url": "https://poc-backend.amdal-dev.workers.dev/mcp"
    }
  }
}

Fügen Sie es zu Claude Desktop, Cursor, Windsurf oder einem anderen MCP-kompatiblen KI-Tool hinzu. Fragen Sie dann:

"Überprüfe meine package.json auf Lieferkettenrisiken" "Bewerte axios, zod, chalk, lodash — welches hat das höchste Risiko?" "Wird vercel/ai aktiv gewartet?"

GitHub Action

Fügen Sie Lieferketten-Audits zu jeder CI-Pipeline hinzu — erkennt Pakete automatisch aus package.json oder requirements.txt, postet Ergebnisse als PR-Kommentar, schreibt in die GitHub Step Summary und schlägt optional bei KRITISCHEN Paketen fehl.

# .github/workflows/supply-chain-audit.yml
name: Supply Chain Audit
on: [push, pull_request]

jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write   # needed for PR comments
    steps:
      - uses: actions/checkout@v4
      - uses: piiiico/proof-of-commitment@main
        with:
          fail-on-critical: false   # set true to block merges
          comment-on-pr: true       # posts audit table directly on the PR

Wenn comment-on-pr: true (Standard), postet die Action automatisch die Audit-Tabelle als Kommentar im Pull Request — und aktualisiert denselben Kommentar bei einem erneuten Durchlauf, sodass Sie keinen Kommentar-Spam erhalten. Prüfer sehen die Risikotabelle, ohne den PR zu verlassen.

Eingaben:

Ausgaben: has-critical, critical-count, audit-summary (Markdown-Tabelle, wird auch in die Step Summary geschrieben).

Beispiel für PR-Kommentar / Step Summary Ausgabe:

| Package | Risk        | Score | Maintainers | Downloads/wk | Age   |
|---------|-------------|-------|-------------|--------------|-------|
| chalk   | 🔴 CRITICAL | 75    | 1           | 380M         | 12.7y |
| zod     | 🔴 CRITICAL | 83    | 1           | 133M         | 6.1y  |
| axios   | 🔴 CRITICAL | 89    | 1           | 93M          | 11.6y |

README-Badges

Fügen Sie ein Engagement-Score-Badge zu jedem Paket hinzu, das Sie betreuen oder von dem Sie abhängen:

![commit score](https://poc-backend.amdal-dev.workers.dev/api/badge/npm/YOUR-PACKAGE)

Beispiele:

Farben: 🟢 gesund (75+) · 🟡 gut (60–74) · 🟡 moderat (40–59) · 🟠 hohes Risiko (<40) · 🔴 KRITISCH (einzelner Betreuer + >10 Mio. Downloads/Woche)

Badges werden 5 Minuten am Cloudflare-Edge zwischengespeichert. Kein API-Schlüssel erforderlich.

REST-API

Kein API-Schlüssel. Keine Installation.

curl https://poc-backend.amdal-dev.workers.dev/api/audit \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"packages": ["axios", "zod", "chalk", "lodash", "express"]}'

{
  "count": 5,
  "results": [
    {
      "name": "chalk",
      "ecosystem": "npm",
      "score": 75,
      "maintainers": 1,
      "weeklyDownloads": 398397580,
      "ageYears": 12.7,
      "trend": "stable",
      "riskFlags": ["CRITICAL"]
    },
    ...
  ]
}

7 MCP-Tools

Was der Score misst

Jedes Paket wird auf einer Skala von 0–100 bewertet basierend auf:

• Langlebigkeit — Wie lange existiert das Paket schon? Verlassene Pakete werden für Angriffe reaktiviert.

• Tiefe der Betreuung — Einzelner Betreuer + Millionen wöchentliche Downloads = die Angriffsfläche, die LiteLLM ausgenutzt hat.

• Release-Konsistenz — Regelmäßige Releases signalisieren aktive Überwachung. Lange Pausen = Anhäufung von Schwachstellen.

• Download-Trend — Wachsende Pakete ziehen mehr Aufmerksamkeit (und Angriffe) auf sich. Stabil = niedrigeres Profil.

Risiko-Flags:

• CRITICAL — einzelner Betreuer + >10 Mio. wöchentliche Downloads (exaktes Angriffsprofil von LiteLLM/axios)

• HIGH — Paket <1 Jahr alt + schnelle Verbreitung

• WARN — kein Release in den letzten 12+ Monaten

Echte Datenpunkte

chalk     — score 75, 1 maintainer, 399M/week  ⚑ CRITICAL
zod       — score 83, 1 maintainer, 139M/week  ⚑ CRITICAL
axios     — score 89, 1 maintainer,  96M/week  ⚑ CRITICAL (attacked Apr 1 2026)
lodash    — score 88, 3 maintainers, 68M/week
express   — score 91, 5 maintainers, 35M/week
litellm   — score 74, 1 maintainer           ⚑ CRITICAL (supply chain attack Mar 2026)

Warum Verhaltenssignale

Der LiteLLM-Angriff (März 2026) und der axios-Angriff (April 2026) folgten demselben Muster: gestohlene Anmeldedaten → bösartiges Paket veröffentlicht → 97 Mio.+ Maschinen exponiert. Beide Pakete wurden vor den Angriffen durch diese Metriken als KRITISCH eingestuft.

Deklarative Signale (Sterne, README-Qualität, CI-Badges) erfassen dieses Risiko nicht. Verhaltensbezogenes Engagement schon.

Im offiziellen MCP-Register gelistet

registry.modelcontextprotocol.io → io.github.piiiico/proof-of-commitment

Stack

Die umfassendere Vision

Lieferketten-Audits sind das erste Werkzeug. Das zugrunde liegende Primitiv ist ein Engagement-Graph — Verhaltenssignale, die inhaltsbasiertes Vertrauen über jede Domäne hinweg ersetzen.

Wenn Inhalte leicht zu fälschen sind (Bewertungen, Sterne, READMEs), wird Engagement zum Signal. Ein Betreuer, der in 12 Jahren 847 Releases veröffentlicht hat, zeigt eine andere Art von Engagement als jemand, der 2023 einmal etwas veröffentlicht hat.

Die gleiche Logik gilt für Websites, Unternehmen und KI-Agenten. Zwei Kartennetzwerke haben diese Lücke unabhängig voneinander benannt: Mastercard Verifiable Intent §9.2 listet verhaltensbasiertes Vertrauen explizit als "nicht abgedeckt". Visa TAP identifiziert Agenten, ohne zu beantworten, ob man ihnen vertrauen sollte.

Proof of Commitment ist die Vertrauensebene, auf die sie hinweisen.

→ getcommit.dev

Lokal ausführen

bun install
bun run dev:backend     # local server with SQLite
bun run test:e2e        # E2E test with mock World ID

Bereitstellen:

bun run deploy          # deploys to Cloudflare Workers