Thema: supply-chain
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
Ein nicht vertrauenswürdiges Repository öffnen: die Dateien, die beim Installieren, Bauen, Testen oder blossen Betreten Code ausführen
Ein Repository zu klonen führt nichts aus, aber viele routinemässige Folgeschritte tun das: Paket-Installationsskripte, Build-Dateien, Testkonfiguration, Editor-Tasks, Environment-Loader und manche Git-Einstellungen. Ein Agent, der in einem fremden Repository arbeitet, sollte diese Ausführungspunkte kennen und sie nur innerhalb einer Sandbox ausführen.
-
Reproduzierbare Builds und fixierte Abhängigkeiten
Ein Build ist reproduzierbar, wenn derselbe Quellcode und dieselbe Build-Umgebung ein bitgenau identisches Ergebnis erzeugen; Lockfiles mit Hashes, fixierte Basisimages und feste Zeitstempel sind die praktischen Schritte dorthin.
Maschinenlesbar: JSON