Sicherheitsrisiken in Abhängigkeiten: Automatisierte Vertrauensbewertung im CI-Prozess

Die meisten Lieferkettenangriffe folgen keinem Muster wie Zero-Day-Exploits. Stattdessen nutzen Angreifer vorhersehbare Schwachstellen: Ein Paket mit einem einzelnen Maintainer, stagnierender Aktivität und 50 Millionen Downloads pro Woche ändert plötzlich den Besitzer. Tools wie npm audit zeigen keine Probleme an – denn es existiert noch kein CVE-Eintrag.

Genau hier setzt das Tool proof-of-commitment an. Es bewertet Abhängigkeiten anhand verhaltensbasierter Signale wie der Anzahl der Maintainer, Download-Trends, Wartungsaktivität und historischen Vorfällen. Mit nur minimalem Aufwand lässt sich diese Bewertung in bestehende CI-Pipelines integrieren. Zwei Methoden stehen zur Auswahl – eine GitHub-Action oder ein CLI-Tool für alle CI-Systeme.

GitHub Action: Automatisierte Sicherheitsprüfung für Abhängigkeiten

Die einfachste Methode, die Vertrauensbewertung in die Entwicklungsumgebung einzubinden, ist eine GitHub Action. Diese prüft automatisch alle Abhängigkeiten bei Pull Requests und liefert sofortige Rückmeldung.

# .github/workflows/supply-chain-audit.yml
name: Abhängigkeitsprüfung

on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'
      - 'bun.lock'
      - 'requirements.txt'
      - 'pyproject.toml'
  push:
    branches: [main]
  workflow_dispatch: {}

jobs:
  audit:
    name: Abhängigkeitsaudit
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write  # Erlaubt Kommentare in Pull Requests
    steps:
      - uses: actions/checkout@v4
      - name: Commit Supply Chain Audit
        uses: piiiico/proof-of-commitment@main
        with:
          fail-on-critical: false  # Blockiert Merge bei kritischen Paketen
          max-packages: '20'       # Maximale Anzahl geprüfter Pakete
          comment-on-pr: true      # Kommentiert Ergebnisse in Pull Requests

Diese Konfiguration funktioniert out-of-the-box. Das Tool erkennt automatisch die verwendeten Paketmanager (npm, PyPI etc.) und prüft die Top-20-Abhängigkeiten. Bei jedem Pull Request, der Abhängigkeiten ändert, wird ein detaillierter Kommentar mit Risikobewertung generiert.

Optionale Parameter und ihre Funktionen

• `packages` (Standard: auto): Kommagetrennte Liste von Paketnamen. Wird nicht benötigt, da die Erkennung automatisch aus den Lock-Dateien erfolgt.
• `ecosystem` (Standard: auto): Gibt den Paketmanager an (npm, pypi). Wird automatisch aus den Projektdateien abgeleitet.
• `fail-on-critical` (Standard: true): Beendet den Workflow mit einem Fehler, wenn kritische Pakete gefunden werden. Deaktivieren Sie diese Option, um nur eine Meldung zu erhalten, ohne den Merge zu blockieren.
• `max-packages` (Standard: 20): Legt fest, wie viele Abhängigkeiten maximal geprüft werden. Ideal für große Projekte mit vielen indirekten Abhängigkeiten.
• `comment-on-pr` (Standard: true): Aktiviert die automatische Kommentarfunktion in Pull Requests.

Beispielausgabe in Pull Requests

Die Action hinterlässt einen detaillierten Kommentar mit Risikobewertung für jedes geprüfte Paket:

## Commit Supply Chain Audit

| Paket      | Bewertung | Risiko     | Wöchentliche Downloads | Maintainer |
|------------|-----------|------------|-------------------------|------------|
| axios      | 42        | KRITISCH   | 101 Mio.                | 2          |
| lodash     | 71        | MODERAT    | 54 Mio.                 | 4          |
| chalk      | 58        | HOCH        | 413 Mio.                | 1          |
| zod        | 89        | NIEDRIG    | 18 Mio.                 | 2          |
| react      | 94        | NIEDRIG    | 70 Mio.                 | 8          |

⚠️ 1 KRITISCHES Paket gefunden. Bitte vor dem Merge prüfen.

Die Bewertungen basieren auf strukturellen Risikosignalen wie der Maintainer-Anzahl im Verhältnis zu den Downloads oder der Aktivität in den letzten 90 Tagen. Die Tabelle wird bei jedem neuen Commit automatisch aktualisiert.

CLI-Tool: Flexible Integration in jede CI-Umgebung

Für Teams, die nicht auf GitHub setzen oder andere CI-Systeme nutzen, steht ein universelles CLI-Tool zur Verfügung. Es funktioniert in GitHub Actions, GitLab CI, CircleCI und Buildkite – überall, wo Node.js verfügbar ist.

Grundlegende Befehle

• Einfache Prüfung eines npm-Projekts:

npx proof-of-commitment --file package.json

• Prüfung eines Python-Projekts:

npx proof-of-commitment --file requirements.txt

• Prüfung mit Ausgabe in eine Datei:

npx proof-of-commitment --file package.json --output audit-results.md

Das CLI-Tool beendet die Ausführung mit einem Fehlercode, falls kritische Pakete gefunden werden. Dies ermöglicht eine nahtlose Integration in alle CI-Pipelines, die Exit-Codes auswerten.

Echtzeit-Bewertungen: Badges für README-Dateien

Um das Vertrauenslevel direkt im Projekt sichtbar zu machen, können Entwickler Badges in die README-Datei integrieren. Diese laden die Bewertung dynamisch von einer API und aktualisieren sich automatisch bei Änderungen.

• Für npm-Pakete:

!Commit Trust Score

• Für PyPI-Pakete:

!Commit Trust Score

Die Badges sind mit Shields.io kompatibel und unterstützen benutzerdefinierte Schwellenwerte. Weitere Optionen finden sich unter /badges.

Verständnis der Bewertungsskala: Was bedeuten die Scores?

Die Bewertungen reichen von 0 bis 100 und sind in vier Risikokategorien unterteilt:

• 80–100 (NIEDRIG): Starke verhaltensbasierte Signale – das Paket gilt als vertrauenswürdig.
• 60–79 (MODERAT): Einige Risikosignale vorhanden – empfohlen vor größeren Versionsupgrades.
• 40–59 (HOCH): Mehrere Risikosignale – Alternativen sollten in Betracht gezogen oder Versionen fest gepinnt werden.
• 0–39 (KRITISCH): Schwere strukturelle Risiken – oft nur ein Maintainer, hohe Downloads, geringe Aktivität.

Die Bewertung berücksichtigt Faktoren wie:

• Anzahl der Maintainer im Verhältnis zu den Downloads (Bus-Faktor)
• Aktivität der Maintainer in den letzten 90 Tagen
• Historische Vorfälle oder Sicherheitsvorfälle
• Download-Trends (plötzliche Spitzen oder Stagnation)

Wichtig: Die Bewertung basiert nicht auf CVE-Datenbanken. Ein Paket kann trotz fehlender bekannter Schwachstellen als KRITISCH eingestuft werden – genau hier setzt das Tool an. Die vollständige Methodik ist unter getcommit.dev/thesis einsehbar.

Fazit: Proaktive Sicherheit für Software-Lieferketten

Software-Supply-Chain-Angriffe nehmen zu – oft durch vermeidbare strukturelle Schwächen in Abhängigkeiten. Tools wie proof-of-commitment ergänzen bestehende Sicherheitsmaßnahmen, indem sie verhaltensbasierte Risiken erkennen, bevor CVEs existieren. Mit minimalem Aufwand integrieren Entwicklerteams diese Prüfung in ihre CI-Pipelines und erhalten sofortige Transparenz über die Vertrauenswürdigkeit ihrer Abhängigkeiten. Die Kombination aus automatischer Prüfung, Echtzeit-Feedback und dynamischen Badges schafft eine neue Ebene der Lieferketten-Sicherheit – ohne manuelle Überprüfungen oder wartungsintensive Prozesse.