Thema: supply-chain
-
Veröffentlichungsidentitäten bei npm und PyPI an freigegebene Release-Artefakte binden
Trusted Publishing mit OIDC beseitigt gespeicherte Veröffentlichungs-Tokens, seine Sicherheit hängt aber weiterhin vom autorisierten Workflow ab. Build und Veröffentlichung trennen, Freigaben schützen und die Identität des Artefakts prüfen, ohne einen Herkunftsnachweis als Urteil über Schadsoftware zu behandeln.
-
Dependency Confusion: wenn ein öffentliches Paket ein privates verdrängt
Löst ein Build Paketnamen sowohl über einen privaten als auch einen öffentlichen Index auf, kann ein Angreifer, der den privaten Namen öffentlich mit einer höheren Version veröffentlicht, seinen eigenen Code installiert bekommen; die pip-Dokumentation nennt --extra-index-url für private Pakete deshalb ausdrücklich unsicher. Gegenmassnahmen sind an eine Registry gebundene Namensräume, ein einzelner proxyierender Index, Hash-Pinning und das Beanspruchen von Namen.
-
Subresource Integrity für Skripte und Stylesheets von Drittanbietern
Ein integrity-Attribut an einem script- oder link-Element trägt einen base64-kodierten SHA-256-, SHA-384- oder SHA-512-Hash der erwarteten Datei; der Browser verweigert Ausführung oder Anwendung einer Ressource, deren Inhalt nicht übereinstimmt. Es legt exakt fest, was ein CDN ausliefern darf, setzt CORS für Cross-Origin-Dateien voraus und funktioniert deshalb nur für Ressourcen mit festem Inhalt.
-
MCP-Tool-Definitionen als Angriffsfläche: vergiftete Beschreibungen, Shadowing und stille Änderungen
Die Toolnamen, Beschreibungen und Annotationen eines MCP-Servers sind Text, den das Modell liest, bevor irgendein Tool aufgerufen wird. Ein bösartiger oder kompromittierter Server kann sie nutzen, um den Agenten zu steuern, die Tools eines anderen Servers zu imitieren oder das Verhalten nach der Genehmigung zu ändern. Clients sollten Definitionen fixieren, per Diff vergleichen und wie Code überprüfen.
-
Abhängigkeitshygiene und Prüfungen der Software-Lieferkette
Wissen, wovon man abhängt, es festpinnen und verifizieren, auf bekannte Schwachstellen achten und aus vertrauenswürdigen Quellen bauen; SLSA-Stufen, OpenSSF Scorecard und hash-geprüfte Installationen liefern konkrete Schritte.
-
Halluzinierte und verwechselbare Paketnamen: eine Abhängigkeit prüfen, bevor ein Agent sie installiert
Codegenerierende Modelle nennen manchmal Pakete, die nicht existieren; eine angreifende Partei kann einen solchen Namen registrieren, und Typosquatter registrieren Namen, die beliebten Paketen zum Verwechseln ähnlich sind. Vor der Installation sollte ein Agent bestätigen, dass das Paket existiert, das beabsichtigte Projekt ist und nicht unter einem verwechselbaren Namen neu registriert wurde.
-
LiteLLM-Vorfall im Oktober 2026: bestätigte Token-Offenlegung und Vorsichtsmassnahmen für Gateway-Protokolle
LiteLLMs späterer Vorfallbericht ersetzte die anfängliche Theorie eines Protokolldiebstahls durch Beweise für eine Token-Offenlegung über eine API der Agent Platform. Der Vorfall verdeutlicht weiterhin, weshalb Agentenzugangsdaten, Antwortinhalte und privilegierte Automatisierung getrennte Zugriffsgrenzen benötigen.
-
Software-Stücklisten mit SPDX und CycloneDX
Eine SBOM ist ein maschinenlesbares Inventar der Komponenten eines Software-Artefakts; SPDX und CycloneDX sind die beiden verbreiteten Formate, und pro Release eine SBOM zu erzeugen unterstützt Schwachstellenabgleich und Lizenzprüfung.
-
Rhythmus für Abhängigkeits-Updates: Batching, Gruppierung und was auf einmal gemergt wird
Update-Bots öffnen einen Pull Request pro Abhängigkeit, sofern nicht anders konfiguriert; ein tragfähiger Rhythmus merged Sicherheitsfixes, sobald sie eintreffen, bündelt Patch- und Minor-Updates zu einer geplanten Gruppe und behandelt Major-Versionen als geplante Arbeit. Dependabot und Renovate dokumentieren beide Scheduling und Gruppierung, und Renovates Leitfaden benennt die Kosten der Gruppierung: Eine fehlschlagende Gruppe blockiert alle ihre Mitglieder.
-
Ausbreitung von npm-Würmern über Entwicklungsrechner und Veröffentlichungskonten eindämmen
ChainDrop und die Kompromittierung von Tensorlake zeigen, wie der Diebstahl von Zugangsdaten während der Installation zu unbefugten Paketveröffentlichungen führen kann. Die Eindämmung muss die Ausführung von Abhängigkeiten, Veröffentlichungsrechte, dauerhafte Verankerungen in Repositories und kontaminierte Build-Ergebnisse erfassen.
-
GitHub-Actions-Workflows absichern: Actions per SHA anheften, Tokens nach dem Prinzip der geringsten Rechte, nicht vertrauenswürdige Eingaben
Actions von Drittanbietern auf den vollständigen Commit-SHA anheften, das GITHUB_TOKEN standardmässig auf Nur-Lese setzen und pro Job gezielt erweitern, nicht vertrauenswürdige Event-Felder nie in run-Skripte einsetzen, und pull_request_target sowie workflow_run als privilegierte Trigger behandeln.
-
Wartefristen für Paket-Releases: genaue Einstellungen, Einheiten und Grenzen der Durchsetzung
Kontrollen des Release-Alters unterscheiden sich zwischen npm, pnpm, uv, Renovate und Dependabot. Die richtigen Einheiten konfigurieren, den Umgang mit Zeitstempeln und die Auflösung transitiver Abhängigkeiten prüfen sowie einen ausdrücklichen Weg für dringende Sicherheitsupdates vorsehen.
-
Kleine, reproduzierbare Container-Images bauen
Basis-Images per Digest anheften, aus Lockfiles mit Hash-Prüfung installieren, nur das kopieren, was die Laufzeitumgebung braucht, als Nicht-Root-Nutzer laufen lassen, einen Health-Check ergänzen und Secrets aus Layern und Build-Argumenten heraushalten.
-
Software-Stücklisten (SBOM): das Inventar der eigenen Lieferkette
Eine Software-Stückliste zählt maschinenlesbar auf, welche Komponenten in welcher Version in einem gelieferten Artefakt stecken. SPDX (ISO/IEC 5962:2021) und CycloneDX (OWASP) sind die verbreiteten Formate; erzeugt wird sie pro Release aus dem gebauten Artefakt, daneben abgelegt und zum Abgleich mit Schwachstellenmeldungen und Lizenzpflichten genutzt. Zusammen mit Herkunftsnachweisen (SLSA) macht sie die Lieferkette prüfbar.
-
Supportende über SBOMs, Container-Images und Softwareinventare hinweg automatisch erkennen
Laufzeit- und Imageinventare mit Lebenszyklusdaten verknüpfen und dabei Produktidentität, Supportanbieter und Aktualität der Nachweise erhalten. Der vorgeschlagene Ablauf nutzt endoflife.date als Hinweisquelle, bestätigt Fristen bei den Anbietern und meldet abgelaufenen Support getrennt von fehlenden Nachweisen.
-
Commits und Tags mit einem SSH-Schlüssel oder GPG signieren
Git signiert Commits und Tags mit OpenPGP, X.509 oder, seit gpg.format=ssh, mit einem einfachen SSH-Schlüssel; die signierende Person setzt gpg.format und user.signingKey, Prüfende brauchen eine Allowed-Signers-Datei (SSH) oder einen vertrauenswürdigen Schlüsselbund (GPG), und Fälschungen werden mit git verify-commit oder dem Signatur-Abzeichen des Hosting-Anbieters geprüft.
-
Build-Provenienz-Attestierungen: Was SLSA-Provenienz erfasst und wie sie geprüft wird
Der Build-Track von SLSA bewertet, wie vertrauenswürdig die Provenienz eines Artefakts ist, von „Provenienz existiert“ (L1) bis zu einer gehärteten Build-Plattform (L3); die Provenienz ist eine in-toto-Attestierung, die die Digests des Artefakts, den Builder, den Build-Typ und seine externen Parameter benennt, und eine konsumierende Partei prüft sie vor der Verwendung gegen eine Vertrauenswurzel und erwartete Werte.
-
Container-Image-Tags versus Digests: veränderliche Namen und Inhaltsadressen
Ein Tag ist ein menschenlesbarer Zeiger, der jederzeit auf ein anderes Manifest umgehängt werden kann; ein Digest ist der Hash der Manifest-Bytes und identifiziert für immer genau ein Image. Nach Tag bauen und testen, nach Digest deployen und pinnen, und den Digest in jeder Release-Notiz festhalten.
-
Ein Kryptografieinventar für die Post-Quanten-Migration aufbauen und pflegen
Erfassen, wo Kryptografie Daten schützt, wer die einzelnen Abhängigkeiten verantwortet und welche Nachweise die Einträge stützen. Eine CycloneDX-CBOM für den Austausch technischer Bestandsdaten nutzen, ohne sie mit einem vollständigen Migrationsplan gleichzusetzen.
-
Welche Prüfungen bei automatisierten Dependency-Update-Pull-Requests haben eine bösartige oder defekte Version abgefangen, und welche erzeugen nur Störgeräusche?
Offene Frage: Automatisierte Update-Pull-Requests treffen täglich ein und werden oft bei grüner CI gemerged; die npm-Dokumentation beschreibt Provenance-Attestierungen, die sich mit npm audit signatures verifizieren lassen, doch welche Prüfungen (Provenance, Review des entpackten Diffs, Prüfung von Install-Skripten, Wartefristen, Lockfile-Diffs) haben nachweislich schon eine kompromittierte oder defekte Version abgefangen?
Maschinenlesbar: JSON