Sicherheit der Software-Lieferkette: Erkennung bösartiger Pakete & Modelle

Moderne Software besteht überwiegend aus Code von Dritten, und Angreifer veröffentlichen Pakete mit Tippfehler-Namen (Typosquatting), gekaperte oder mit Hintertüren versehene Pakete sowie vergiftete Modelldateien, die Code ausführen, sobald sie installiert oder geladen werden. Klassische Scanner gleichen nur bekannte CVEs ab. KI-gestützte Verhaltensanalyse prüft, was ein Paket oder Modell tatsächlich tut, blockiert verdächtige Versionen am Repository-Tor und hält SBOM- und Herkunftsnachweise fest, die der EU Cyber Resilience Act (CRA) und NIS2 zunehmend verlangen.

Problem & Nutzen

• Heute: Entwickler installieren pro Projekt Hunderte transitiver Abhängigkeiten. Die Abwehr stützt sich auf CVE- Datenbanken (die nur Schwachstellen kennen, nicht bösartige Absicht), den Ruf der Maintainer und manuelle Prüfung, die nicht skaliert. Bösartige Releases sind meist Stunden oder Tage online, bevor Registries sie entfernen, und Installationsskripte (postinstall, setup.py) laufen mit den Rechten der Entwickler oder der CI, wo Geheimnisse und Cloud-Tokens vorhanden sind.
• Modellartefakte sind ein zweiter Kanal: Viele Modellformate (insbesondere Python-Pickle) können beim Laden Code ausführen, daher ist der Download eines Modells aus einem öffentlichen Hub mit dem Ausführen einer unbekannten Binärdatei vergleichbar [4][5].
• KI-Nutzen: LLMs und ML-Klassifikatoren lesen Code semantisch (Verschleierung, Datenabfluss, unerwartete Netzwerkaufrufe, Dropper-Muster), vergleichen ein neues Release mit seiner Historie und fassen Befunde für die Triage zusammen; das verkürzt die Zeit zwischen Veröffentlichung und Sperre. Compliance-Nachweise fallen nebenbei an.
• Warum jetzt (EU): Der CRA verpflichtet Hersteller von Produkten mit digitalen Elementen zur Sorgfalt bei Komponenten Dritter, einschließlich Open Source, und zum Führen einer SBOM; die Meldepflichten für Schwachstellen und Vorfälle beginnen im September 2026, die Hauptpflichten folgen im Dezember 2027 [1]. NIS2 nennt die Sicherheit der Lieferkette ausdrücklich unter den Maßnahmen des Risikomanagements [2].

Varianten

• KMU / Softwarehaus: ein Registry-fähiger Scanner bei Pull Requests plus eine Regel, neue Abhängigkeiten festzuschreiben und zu prüfen.
• Großunternehmen / Plattformteam: eine Repository-Firewall vor Artifactory/Nexus, die neue Pakete und Modelle in Quarantäne nimmt, mit einem internen Katalog freigegebener Pakete.
• ML-/KI-Teams: Kontrolle am Modell-Hub, Umwandlung in sichere Formate (safetensors), ML-BOM und Herkunft von Datensätzen; Verweise auf SEC-013 und SEC-014.
• Hersteller (CRA): SBOM-, VEX- und Attestierungs-Pipeline je Produktfreigabe.
• Öffentlicher Sektor: kuratierte Spiegel freigegebener Open-Source-Software, im Einklang mit nationalen Beschaffungs- und Open-Source-Sicherheitsleitlinien.
• Private / Hobby-Entwickler: kostenlose Scanner in der IDE und Installations-Hooks des Paketmanagers.

So funktioniert es

1. developer / CI requests dependency or model
2. proxy / firewall intercepts (npm, PyPI, Maven, container, model hub)
3. metadata signals (age, maintainer change, name similarity, download anomalies)
4. static + sandboxed dynamic analysis (install script, network, filesystem, process behaviour)
5. ML/LLM scoring (obfuscation, exfiltration, capability diff vs previous release)
6. model-file scan (unsafe pickle opcodes/imports, format conversion, hash and signature check)
7. policy engine: allow | warn | quarantine | block
8. SBOM / VEX / attestation written to evidence store
9. human review of quarantined items (security + developer)

• Verhaltensklassifikatoren: auf gelabelten bösartigen und harmlosen Releases trainiert; Merkmale sind unter anderem neue Fähigkeiten (Shell, Netzwerk, Zugriff auf Umgebungsvariablen), die zwischen Versionen hinzukamen.
• LLM-Triage: erklärt, warum ein Diff verdächtig ist, entwirft den Bericht und senkt Fehlalarme; sie muss Paketinhalte als nicht vertrauenswürdige Eingabe behandeln, da Code und README-Text Prompt Injection enthalten können (siehe SEC-010).
• Mensch-in-der-Schleife (Human-in-the-Loop): Entscheidungen über Quarantäne und Ausnahmen bleiben bei einer benannten verantwortlichen Person; automatisches Blockieren gilt nur bei Urteilen mit hoher Sicherheit, mit schnellem Übersteuerungsweg, um Releases nicht unnötig zu blockieren.

Datenaufbereitung

Die Eingaben sind Abhängigkeitsmanifeste und Lock-Dateien (package.json, requirements.txt, pom.xml), Build- und CI-Konfiguration, die genutzten Paket-Registries und bei KI-Projekten auch die von Hugging Face geladenen Modelldateien. In einem KMU liegen diese in Git-Repositories, auf einem CI-Server und manchmal nur auf dem Laptop eines Entwicklers.

Typische Lücken: keine vollständige Liste der Repositories und Verantwortlichen, nicht festgeschriebene Versionen oder fehlende Lock-Dateien, Builds, die direkt aus dem Internet laden, keine SBOM und vergessene Altprojekte ohne Maintainer.

Schritte zur Vorbereitung: 1. Alle Repositories, Sprachen und Verantwortlichen inventarisieren (PREP-001, PREP-004). 2. Lock-Dateien einchecken und Versionen festschreiben; Installationen über einen Proxy oder Spiegel leiten. 3. Eine erste SBOM je Projekt erzeugen (Syft, CycloneDX) und mit dem Build speichern. 4. Interne Pakete kennzeichnen, um Dependency-Confusion-Angriffe zu verhindern. 5. Akzeptierte Ausnahmen mit Verantwortlichem und Ablaufdatum festhalten.

Werkzeuge: Git-Plattform, CI, Syft, Dependency-Track. Grober Aufwandsanteil: 10–20 Prozent, vor allem Aufräumen der Repositories; siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A — Registry-Proxy- und Abhängigkeits-Scan-Dienste (Snyk, Socket, integrierte Funktionen von GitHub/GitLab, JFrog Xray) sind ausgereift, je Entwickler günstig und fügen sich in bestehende Pipelines ein; der Prozess ist Standard.
• Großunternehmen: Weg A — eine kommerzielle Plattform für Software-Composition-Analyse und Artefakt-Firewall einkaufen, die bereits Bedrohungsinformationen zu bösartigen Paketen enthält; Komponenten von Weg C wie Dependency-Track für das SBOM-Management bei Bedarf ergänzen.
• Entwickler: Weg C — OSV-Scanner, Syft/Grype, GuardDog, Dependency-Track und ein selbst betriebener Proxy (Nexus, Open-Source-Alternativen zu Artifactory) laufen auf einem kleinen Server und sind die übliche Werkzeugkette.
• Öffentlicher Sektor: Weg C — selbst betriebenes Scannen und ein interner Paketspiegel halten Quellcode und Abhängigkeitslisten auf souveräner Infrastruktur und vermeiden Beschaffungshürden ausländischer SaaS.

Weg A — Kaufen (Standardsoftware)

• Paketverhalten / Repository-Firewalls: Socket (npm/PyPI/Maven/Go, PR-Bot, Firewall), Sonatype Repository Firewall und Lifecycle, JFrog Xray und Curation (mit Modell-Scan für Hugging Face), Snyk, Mend, Checkmarx, Phylum (jetzt Teil von Veracode), ReversingLabs Spectra Assure (Software- und Modell- Lieferkette), Cloudsmith, GitHub Dependabot mit Malware-Advisories.
• Modellartefakte: Protect AI Guardian (jetzt Palo Alto Networks), HiddenLayer Model Scanner, JFrog-ML- Modell-Scan sowie der Scan, den Hugging Face selbst auf hochgeladenen Repositories ausführt [5].
• EU-Hosting: Die meisten Anbieter sitzen in den USA; prüfen Sie Datenresidenz und AVV-Bedingungen (sie verarbeiten überwiegend öffentliche Paketmetadaten).
• A wählen, wenn: Sie Schutz in wenigen Tagen wollen und kein eigenes Lieferketten-Team haben.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Feeds: OSV.dev und das OpenSSF-Repository malicious-packages, GitHub Advisory Database, deps.dev, Registry-APIs (npm, PyPI) für Metadaten und Veröffentlichungsereignisse [3].
• LLM-Triage: Spitzenmodelle über EU-Regionen oder EU-Anbieter (z. B. Mistral), um Diffs zusammenzufassen und Code-Schnipsel zu entschleiern, mit strikter Regel „nichts ausführen“ und strukturierten Ausgaben.
• Orchestrierung: CI-Plug-in oder Proxy-Hook; Urteile nach Slack/Jira; SBOM über Syft oder cdxgen in Dependency-Track.

Weg C — Selbst betreiben (Open Source)

• Erkennung: OpenSSF Package Analysis (dynamische Analyse in der Sandbox), GuardDog (Datadog, Heuristiken plus Semgrep), OSV-Scanner, Trivy, Grype; Modell-Scan mit ModelScan, picklescan und Fickling (Trail of Bits).
• Herkunft: Sigstore (cosign), SLSA-Verifizierung, in-toto, OpenSSF Scorecard.
• Tor und SBOM: Nexus/Artifactory oder devpi/Verdaccio als Spiegel, Syft, cdxgen, OWASP Dependency-Track.
• LLM-Schicht: offene Code-Modelle (Qwen-Coder-Familie, DeepSeek-Coder, Codestral-Klasse), betrieben mit vLLM oder Ollama für die Diff-Triage. HW2 (eine GPU mit 24 GB) genügt; die Sandbox-Analyse braucht isolierte VMs (z. B. gVisor, Firecracker) ohne Zugang zum Produktionsnetz.

Weg D — Eigenes Training

Lohnt sich nur für Anbieter oder große Organisationen mit proprietären Registries: Klassifikatoren auf gelabelten bösartigen/harmlosen Releases trainieren (öffentliche Datensätze von OpenSSF und aus der Wissenschaft plus interne Vorfälle), mit Merkmalen aus Fähigkeitsunterschieden zwischen Versionen. Erfordert Tausende gelabelter Beispiele und laufendes Nachtrainieren, weil Angreifer sich anpassen.

Stand der Technik (2026)

• Verhalten schlägt Signaturen: Anbieter berichten, neue bösartige Releases anhand von Verhalten und Fähigkeitsänderungen zu erkennen, bevor es eine CVE oder ein Advisory gibt; einen unabhängigen Benchmark mit vereinbarten Kennzahlen gibt es nicht, behandeln Sie Erkennungsversprechen der Anbieter daher als ungeprüft und testen Sie mit Ihrer eigenen Historie.
• Härtung auf Registry-Seite: npm und PyPI führten Trusted Publishing (OIDC), Herkunftsnachweise und Zwei-Faktor-Pflicht ein, doch Kontoübernahmen und der Missbrauch von Installationsskripten bleiben häufig.
• Modell-Lieferkette: Der Wechsel von Pickle zu safetensors sowie Scans auf Seiten der Hubs verringert das Risiko, beseitigt es aber nicht; Forschung hat gezeigt, dass Scanner umgangen werden können (z. B. durch ungewöhnliche Pickle-Konstrukte), daher bleibt das Laden nicht vertrauenswürdiger Modelle in Isolation notwendig [5].
• Angriffe auf KI-Werkzeuge: KI-Coding-Assistenten können Paketnamen erfinden, die Angreifer dann registrieren (Slopsquatting); Positivlisten und Firewall-Prüfungen fangen das ab.
• Grenzen: Fehlalarme bei legitim verschleierten oder nativen Binärpaketen, verzögert aktivierte Nutzlasten, Sandbox-Umgehung, gezielte Angriffe auf bestimmte Build-Umgebungen und Fehler der LLM-Triage. Erkennung ergänzt Festschreiben von Versionen, Lockfiles, reproduzierbare Builds und CI mit geringsten Rechten, ersetzt sie aber nie.

Gemeinsame Bausteine & Kombinationen

• SEC-004 (Scan des eigenen Codes und von CVEs) teilt SBOM-Erzeugung, SCA und das CI-Tor; die Malware-Analyse in SEC-003 teilt Sandbox und Klassifikator-Assets; SEC-008 nutzt Advisories und Kampagnen-Erkenntnisse.
• SEC-009 nutzt SBOM- und Attestierungsnachweise für NIS2/DORA/CRA wieder; SEC-013 und SEC-014 behandeln Modellinventar und adversariale Tests; SEC-010 schützt die LLM-Triage-Schicht; SEC-012 liefert Entscheidungen der Entwurfsprüfung zur Wahl von Abhängigkeiten.
• Gemeinsamer Stack: llm-code auf HW2, Sandbox-Cluster, Artefakt-Repository.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Preis je Entwickler oder je Repository; der meiste Aufwand ist die Feinabstimmung der Richtlinie.
• Weg B: 1–3 Monate für Proxy-Integration, SBOM-Pipeline und Triage-Ablauf.
• Weg C: 2–4 Monate; bescheidene GPU plus Sandbox-Infrastruktur und laufende Regelpflege.
• Kennzahlen: Zeit von der bösartigen Veröffentlichung bis zur Sperre, Anteil der vom Tor abgedeckten Abhängigkeiten, Fehlalarmrate und Blockadezeit für Entwickler, Anzahl der in Quarantäne genommenen Versionen, SBOM-Abdeckung je Release, Anteil der Modelle in sicheren Formaten mit geprüften Hashes.

Menschen & Veränderung

Geschäftsführung und Entwicklungsleitung entscheiden über die Regel „Was darf in den Build gelangen?“; IT-Sicherheit und IT betreiben Proxy und Scanner; Recht und Compliance verfolgen die Nachweispflichten aus dem Cyber Resilience Act und NIS2; Entwickler sind die täglichen Nutzer und entscheiden, ob das Werkzeug akzeptiert wird. Binden Sie Entwickler ab dem Pilot ein, denn ein Tor, das Builds ohne Erklärung blockiert, wird schnell umgangen.

Betriebsrat: abhängig vom Einzelfall. Der Scanner prüft vor allem Pakete, aber Logs darüber, wer welche Abhängigkeit installiert oder angefordert hat, sind einzelnen Personen zuordenbar, daher kann §87 Abs. 1 Nr. 6 BetrVG in Unternehmen mit Betriebsrat greifen. Informieren Sie ihn früh (§90 Abs. 1 Nr. 3) und vereinbaren Sie, dass Logs der Sicherheit dienen, nicht der Leistungsbeurteilung (GUIDE-004). Personenbezogene Daten beschränken sich auf Entwicklernamen in Logs; eine Datenschutz-Folgenabschätzung (DSFA) ist normalerweise nicht nötig, doch die bzw. der Datenschutzbeauftragte sollte dies bestätigen, und für SaaS-Anbieter ist ein Auftragsverarbeitungsvertrag (AVV) erforderlich (GUIDE-005, GUIDE-010).

Beginnen Sie im reinen Warnmodus auf zwei oder drei aktiven Repositories (GUIDE-009) und setzen Sie Sperren dann für eindeutig bösartige Pakete durch. Typische Sorgen: langsamere Builds und Fehlalarme; begegnen Sie ihnen mit einem schnellen Ausnahmeprozess und sichtbaren Kennzahlen. Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung), indem Sie erklären, dass die Urteile probabilistisch sind, und Entwickler zu Typosquatting und Risiken von Modelldateien schulen (GUIDE-006, GUIDE-013). Menschen verantworten die Ausnahmen und die endgültige Freigabeentscheidung.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko (keine Verwendung nach Anhang III; Pflicht zur KI-Kompetenz nach Art. 4). Keine verbotene Praxis. Beim Einsatz in Sicherheitskomponenten kritischer Infrastruktur neu bewerten.
• CRA (Verordnung (EU) 2024/2847): SBOM, Sorgfalt bei Komponenten, Umgang mit Schwachstellen und Meldung aktiv ausgenutzter Schwachstellen; dieser Anwendungsfall liefert die Nachweise, macht ein Produkt aber nicht selbst konform [1].
• NIS2 / DORA: Pflichten zum Risikomanagement der Lieferkette; Verweis auf SEC-009 [2].
• DSGVO: hauptsächlich Paketmetadaten; Namen oder E-Mail-Adressen von Maintainern und Entwickler-Telemetrie (IDE-/CI-Logs) können personenbezogene Daten sein, daher AVV, Datenminimierung und möglichst EU-Hosting nutzen.
• Betriebliche Risiken: zu häufiges Blockieren stoppt Releases (gestufte Richtlinie und Übersteuerung nutzen), Sandbox-Ausbruch (strikt isolieren), Prompt Injection durch Paketinhalte, Anbieterbindung und zu großes Vertrauen in Anbieterversprechen.
• Lizenzierung: Dieselbe Pipeline kann Lizenzkonflikte markieren; behandeln Sie Urteile nicht als Rechtsberatung.

Erste Schritte

1. SBOMs für Ihre wichtigsten Repositories erzeugen (Syft oder cdxgen) und in Dependency-Track laden.
2. Einen Verhaltensscanner (z. B. Socket oder OpenSSF/GuardDog) im reinen Berichtsmodus bei Pull Requests erproben.
3. Einen internen Spiegel oder eine Firewall vor npm/PyPI setzen und ein kurzes Quarantänefenster für neue Versionen einrichten.
4. Modell-Downloads auf eine freigegebene Liste beschränken, safetensors bevorzugen, Hashes prüfen und nicht vertrauenswürdige Modelle nur in Isolation laden.
5. Verantwortliche, Übersteuerungsregeln und die Aufbewahrung von CRA-/NIS2-Nachweisen festlegen, dann die Kennzahlen monatlich prüfen.

Quellen

1. European Commission - Cyber Resilience Act - https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
2. Directive (EU) 2022/2555 (NIS2), Art. 21 - https://eur-lex.europa.eu/eli/dir/2022/2555/oj
3. OpenSSF - malicious-packages and Package Analysis projects - https://github.com/ossf/package-analysis
4. OWASP - Software Component Verification Standard / CycloneDX (ML-BOM) - https://cyclonedx.org/capabilities/mlbom/
5. Hugging Face - Pickle scanning documentation - https://huggingface.co/docs/hub/security-pickle
6. Socket - documentation - https://docs.socket.dev
7. Datadog GuardDog - https://github.com/DataDog/guarddog
8. SLSA framework - https://slsa.dev
9. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj