Ein Coding-Agent kann einen Fehler beheben, indem er eine Bibliothek installiert, eine Lockfile ändert, ein Basis-Image aktualisiert oder einen Befehl im Terminal ausführt. Das Feature funktioniert wieder, die Tests laufen durch und das Team macht weiter. Doch jedes hinzugefügte Paket gelangt in die Supply Chain des Produkts: Code von Drittanbietern, transitive Abhängigkeiten, Installationsskripte, Lizenzen, Schwachstellen und das Verhalten in der Pipeline.

Das Risiko betrifft nicht nur anfällige Pakete. Es entsteht, wenn der Agent Komponenten und Befehle auswählt, um ein Feature schnell zum Laufen zu bringen, ohne Reife, Wartung, Lizenz, Typosquatting, Lockfiles, Container, Registrys, Token, SBOMs und Merge-Kontrollen zu bewerten.

Für DevOps, Security Engineers und CTOs lautet die konkrete Frage vor dem Merge: Welche neuen Abhängigkeiten hat die KI eingeführt, warum werden sie benötigt, was führen sie aus, welche transitiven Komponenten bringen sie mit, welche Skripte starten sie, welche Lizenzen haben sie und wie werden sie nach dem Deployment überwacht?

[Callforaction-WAPT]

Wenn die KI ein Paket installiert, um einen Fehler zu beheben

Das Muster ist üblich: Der Build schlägt fehl, ein Parser fehlt, ein SDK ist nicht konfiguriert, ein Test erfordert ein Mock oder eine Frontend-Komponente benötigt ein Utility. Der Assistent schlägt npm install, pip install, cargo add oder go get vor, aktualisiert die package.json, ändert die requirements.txt, passt eine Lockfile an oder fügt eine Abhängigkeit in das Dockerfile ein.

Diese Abkürzung kann korrekt sein, muss aber wie eine Sicherheitsänderung überprüft werden. Eine Bibliothek ist nicht nur eine zusätzliche Funktion: Sie kann während der Installation Code ausführen, Dutzende transitive Pakete importieren, eine inkompatible Lizenz haben, schlecht gewartet sein oder bekannte Schwachstellen einführen. Die erste Frage lautet nicht “Funktioniert das Paket?”, sondern “Wird es wirklich benötigt?”. Wenn das Projekt bereits eine gleichwertige Bibliothek hat, wenn das Problem mit wenigen Zeilen klarem Code gelöst werden kann oder wenn die Abhängigkeit nur hinzugefügt wird, damit ein Test besteht, können die Kosten für die Supply Chain den Nutzen übersteigen.

Dependency Sprawl: Die versteckten Kosten des “Vibe Coding”

Dependency Sprawl bedeutet, dass Bibliotheken angehäuft werden, weil jede ein kleines lokales Problem löst. Mit KI-Coding-Agenten beschleunigt sich dieses Phänomen, da der Agent nicht die operative Last spürt, Pakete über die Zeit zu warten: Er installiert, passt den Code an und macht weiter.

Die Kosten entstehen später: Sicherheitsupdates, Inkompatibilitäten zwischen Versionen, größere Bundles, langsamere Builds, zu verwaltende Lizenzen, zu triagierende CVEs, zu überwachende transitive Abhängigkeiten, schwerere Container, komplexere SBOMs und eine größere Angriffsfläche. Eine Faustregel hilft: Jede neue Abhängigkeit muss eine Begründung, einen Eigentümer (Owner) und eine bewertete Alternative haben. Wenn niemand weiß, warum sie hinzugefügt wurde oder welches Risiko sie birgt, sollte sie nicht allein deshalb gemergt werden, weil die KI sie vorgeschlagen hat.

Typosquatting und fast gleichnamige Pakete

Modelle können plausible Namen vorschlagen, die manchmal dem korrekten Paket entsprechen, manchmal aber auch einer wenig bekannten Alternative, einem nicht gewarteten Wrapper oder einem Paket, das erstellt wurde, um Tippfehler abzufangen. Das Risiko steigt, wenn der Agent automatisch installiert, ohne dass die Auswahl eine menschliche Kontrolle durchläuft.

Bevor ein Paket akzeptiert wird, müssen Registry, offizielles Repository, Maintainer, aktuelle Releases, offene Issues, Download-Volumen, Signatur oder Provenance (falls verfügbar), Dokumentation und Community überprüft werden. Es reicht nicht aus, dass der Name vertraut klingt: In Ökosystemen wie npm und PyPI können minimale Unterschiede im Namen zu völlig anderen Paketen führen. Bei kritischen Paketen lohnt es sich auch, die Kette der Maintainer zu bewerten, da ein legitimes, aber aufgegebenes Projekt, das übernommen wurde oder nach Jahren der Stille plötzlich neue Releases erhält, sowohl technisch als auch im Hinblick auf das Vertrauen in die Wartung Vorsicht erfordert.

Transitive Abhängigkeiten und Lockfiles

Das Manifest zeigt, was das Team zu verwenden beabsichtigt; die Lockfile zeigt, was tatsächlich in den Build einfließt. Eine einzige Abhängigkeit kann Dutzende oder Hunderte transitive Pakete mit sich bringen, und ein automatisches Update kann ungeplante Versionen ändern. Eine neu generierte Lockfile kann eine weitaus größere Angriffsfläche verbergen als das sichtbare Diff in der package.json.

Die Lockfile muss zusammen mit dem Manifest überprüft werden. Wenn die KI package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, uv.lock, Pipfile.lock, go.sum oder Cargo.lock aktualisiert, muss der Reviewer verstehen, was sich geändert hat: neue Pakete, Major Upgrades, Skripte, Registry-Quellen und Dependency-Trees. Es ist nicht nötig, jede Zeile manuell zu lesen, aber man benötigt Sichtbarkeit darüber, was hinzugekommen ist. Um das Rauschen zu reduzieren, ist es ratsam, bewusste Updates von Features zu trennen: Ein PR, das eine Funktionalität hinzufügt und die halbe Lockfile aktualisiert, ist schwer zu validieren. Daher ist es besser, die notwendige Abhängigkeit zu isolieren, Versionen festzulegen und latest zu vermeiden.

Installationsskripte und Lifecycle-Hooks

Viele Paketmanager erlauben Skripte während der Installations- oder Build-Phase: preinstall, install, postinstall, prepare, Setup-Skripte, Build-Skripte, Plugins und Hooks. Diese Skripte können Code auf den Laptops der Entwickler, in der CI/CD oder in Containern ausführen. Wenn die KI ein Paket hinzufügt, ohne diese Skripte zu prüfen, autorisiert sie faktisch Code von Drittanbietern, im Build-Prozess zu laufen.

Der Review muss nach neuen oder geänderten Skripten in Manifesten und hinzugefügten Paketen suchen. Ein scheinbar harmloser Befehl kann Binärdateien herunterladen, Code generieren, Umgebungsvariablen lesen, Telemetrie senden oder Dateien verändern. In CI-Umgebungen mit Token und Secrets kann ein bösartiges Installationsskript schwerwiegende Auswirkungen haben. Wo immer möglich, sollten Richtlinien eingeführt werden, die die Ausführung von Skripten einschränken, sowie Sandbox-Builds, Token mit minimalem Scope und kontrollierte Registrys verwendet werden.

Lizenzen und Compliance bei Drittanbieter-Code

Bei der Supply Chain geht es nicht nur um Schwachstellen. Eine Bibliothek kann technisch sicher, aber kommerziell problematisch sein: Copyleft-Lizenzen, Nutzungsbeschränkungen, Namensnennungspflichten, Inkompatibilität mit proprietärer Distribution oder Kundenrichtlinien können eine Abhängigkeit für den Kontext ungeeignet machen.

KI-Agenten berücksichtigen nicht immer Lizenzbeschränkungen. Wenn man sie bittet, eine Bibliothek zum Exportieren von PDFs hinzuzufügen, wählt der Assistent das aus, was er kennt oder was funktioniert, nicht unbedingt das, was mit dem Geschäftsmodell oder dem Kundenvertrag kompatibel ist. Für Softwarehäuser und B2B-Produkte sollte jede neue Abhängigkeit einen Lizenz-Scan oder eine Allowlist durchlaufen. Ausnahmen müssen dokumentiert werden, denn ohne Richtlinien tritt das Risiko erst spät zutage: während Due Diligence, Kunden-Audits, Enterprise-Beschaffung oder bei der Release-Vorbereitung.

Container, Basis-Images und Systempakete

Das Supply-Chain-Risiko endet nicht beim Anwendungscode. Ein Agent kann Dockerfiles, Basis-Images, Betriebssystempakete, Installer, Curl-Skripte, Apt-Repositorys, Node- oder Python-Versionen, Build-Stufen und Runtime-Berechtigungen ändern. Er kann latest verwenden, unnötige Tools installieren oder die Anwendung als Root ausführen lassen.

Jedes Image muss als Produktkomponente behandelt werden. Empfohlene Praktiken umfassen minimale und gewartete Basis-Images, Versions-Pins, Container-Scanning, Benutzer ohne Root-Rechte (wo möglich), Reduzierung von Betriebssystempaketen, saubere Multi-Stage-Builds und keine Secrets in den Layern. Wenn die KI ein Muster wie curl | sh hinzufügt, ist es notwendig, innezuhalten und Quelle, Signatur, Prüfsumme und Notwendigkeit zu überprüfen, bevor man fortfährt. Ein Build, der durchläuft, weil der Container “alles Notwendige” installiert, kann im Laufe der Zeit schwer zu patchen und zu überwachen sein.

Unterschiedliche Ökosysteme, unterschiedliche Signale

Die Supply-Chain-Kontrolle ändert sich je nach Stack. In Node.js verläuft das Risiko oft über package.json, Lockfiles, npm-Skripte, transitive Pakete und Frontend-Bundles. In Python muss man requirements.txt, pyproject.toml, Lockfiles, Wheels, native Abhängigkeiten, private Indizes und fast gleichnamige Pakete im Auge behalten. In Go machen go.mod und go.sum den Abhängigkeitsgraphen klarer, aber Modulpfade, Replace-Direktiven und Quellen müssen dennoch kontrolliert werden. In Rust zeigen Cargo.toml und Cargo.lock Crates und aktivierte Features.

Ein KI-Agent kann die Syntax all dieser Ökosysteme kennen, aber er kennt nicht die Richtlinien des Teams. Er kann npm audit fix verwenden und dabei mehr Versionen als nötig ändern, ein nicht genehmigtes Python-Paket installieren, ein Cargo-Feature hinzufügen, das ungeplanten Code mitbringt, oder ein Dockerfile ändern, um Systembibliotheken ohne Pin zu installieren. Für jedes Ökosystem gilt die gleiche Regel: Manifest und Lockfile müssen zusammen gelesen werden, die Paketquellen müssen bekannt sein und automatische Updates müssen von Features getrennt werden. Wenn das Projekt private Registrys verwendet, ist es wichtig, auch Fallbacks und Prioritäten zu prüfen, da eine falsche Konfiguration dazu führen kann, dass ein öffentliches Paket anstelle des internen heruntergeladen wird.

Dependency Confusion und private Registrys

Unternehmen, die interne Pakete verwenden, müssen das Risiko von Dependency Confusion berücksichtigen. Wenn ein privates Paket einen Namen hat, der auch in einer öffentlichen Registry existieren kann, kann eine falsche Konfiguration des Paketmanagers dazu führen, dass die falsche Komponente heruntergeladen wird. KI-Agenten können das Problem verschärfen, indem sie generische Registry-Konfigurationen erstellen oder Einstellungen entfernen, weil sie für den lokalen Build “nicht benötigt” werden.

Es ist notwendig, npm-Scopes, Python-Indizes, Docker-Registrys, GitHub Packages, GitLab Package Registry, Unternehmens-Proxys und Mirror zu kontrollieren. Dabei muss sichergestellt werden, dass interne Pakete von der korrekten Registry aufgelöst werden, Token einen minimalen Scope haben und Logs keine Anmeldedaten preisgeben. Wenn ein Agent .npmrc, pip.conf, poetry config, Docker-Login oder Publish-Workflows ändert, muss diese Änderung als sensibel behandelt werden. Der einfachste Test besteht darin, den Build in einer sauberen Umgebung zu reproduzieren und zu beobachten, woher die Pakete heruntergeladen werden: Ein Build, der auf dem Laptop des Entwicklers funktioniert, aber in der CI andere Quellen verwendet, ist nicht steuerbar.

Registrys, Token und Publish-Anmeldedaten

Supply Chain bedeutet auch, wer herunterladen und veröffentlichen darf. Token für npm, PyPI, GitHub Packages, Docker-Registrys, private Paket-Registrys und CI/CD-Anmeldedaten müssen einen minimalen Scope haben. Ein Agent mit Zugriff auf das Terminal oder die Pipeline kann Token lesen oder verwenden, wenn die Umgebung nicht angemessen getrennt ist.

Es muss überprüft werden, wo Registry-Token leben, wer veröffentlichen darf, welche Branches Releases aktivieren, welche Pakete privat sind, welche Namespaces geschützt sind und welche Logs Anmeldedaten ausgeben könnten. Wenn die KI Publish- oder Versionierungs-Workflows ändert, ist diese Änderung sensibel und erfordert eine explizite Überprüfung. Bei internen Paketen ist der Schutz von Benennungen und Namespaces grundlegend: Ein mehrdeutiger Import oder eine falsche Registry-Konfiguration kann zu Dependency Confusion führen, wobei das Build-System ein öffentliches Paket anstelle des vorgesehenen internen herunterlädt.

SBOM, Provenance und Rückverfolgbarkeit

Wenn man nicht weiß, was in den Build eingeflossen ist, kann man es über die Zeit nicht verwalten. Eine Software Bill of Materials (SBOM) hilft dabei, Komponenten, Versionen und Abhängigkeiten aufzulisten. CycloneDX ist ein etablierter Standard zur Darstellung von SBOMs, während OpenSSF SLSA einen Rahmen bietet, um über Provenance und Integrität des Builds nachzudenken.

Für ein kleines MVP mag eine SBOM übertrieben erscheinen, aber für ein Produkt, das an Kunden geht, ein SaaS mit echten Daten oder ein Softwarehaus, das Code liefert, wird sie zu einem praktischen Werkzeug: Wenn eine CVE auftritt, wenn ein Kunde Nachweise verlangt oder wenn eine Abhängigkeit kompromittiert wird, reduziert das Wissen darüber, was im Release enthalten ist, Zeitaufwand und Unsicherheit. KI-Agenten erhöhen den Bedarf an Rückverfolgbarkeit, da sie häufig Komponenten hinzufügen und ändern können. Ohne SBOM oder Abhängigkeitsinventar ist das Team auf das Gedächtnis derer angewiesen, die das Diff akzeptiert haben.

Automatische Scanner: notwendig, aber nicht ausreichend

SCA, Dependency Scanning, Container Scanning und Lizenz-Scanning sind unverzichtbare Kontrollen: Sie fangen bekannte Schwachstellen, problematische Lizenzen und veraltete Versionen ab. Sie beantworten jedoch nicht alle relevanten Sicherheitsfragen.

Ein Scanner bewertet nicht, ob diese Abhängigkeit wirklich benötigt wird, ob ein fast gleichnamiges Paket versehentlich ausgewählt wurde, ob ein postinstall-Skript mit der Unternehmensrichtlinie übereinstimmt, ob die Lockfile ohne Grund neu generiert wurde, ob eine Lizenz für diesen Kunden akzeptabel ist oder ob der Build Code auf nicht reproduzierbare Weise herunterlädt. Deshalb muss der Supply-Chain-Review automatische Tools und menschliches Urteilsvermögen kombinieren: Der Scanner liefert Signale, aber die Entscheidung zum Merge erfordert Kontext.

Überwachung nach dem Merge

Die Supply Chain endet nicht beim Merge. Eine saubere Abhängigkeit kann heute eine CVE erhalten, den Maintainer wechseln, ein kompromittiertes Release einführen oder mit einem Sicherheits-Patch inkompatibel werden. Deshalb muss man wissen, welche Komponenten sich in Produktion befinden und wer für die Behebung verantwortlich ist.

Die Überwachung muss SBOMs, Scanner, Vulnerability Management, Issue-Tracking und Releases miteinander verknüpfen. Wenn eine Schwachstelle auftritt, muss das Team schnell verstehen, ob die Komponente vorhanden ist, in welcher Version, in welchem Dienst, ob sie erreichbar ist, ob ein aktiver Exploit existiert, welche Schadensbegrenzung anzuwenden ist und wer das Update genehmigen muss. KI-Agenten können bei der Vorbereitung von Upgrades helfen, sollten diese aber nicht ohne Review anwenden: Ein automatisches Update kann eine CVE beheben und gleichzeitig Auth, Parsing, Serialisierung, Uploads oder die Runtime-Kompatibilität beschädigen. Der Patch muss als Produktänderung behandelt werden, nicht als einfaches Aufräumen.

Wenn das Paket die Anwendungssicherheit berührt

Einige Abhängigkeiten erfordern erhöhte Aufmerksamkeit, da sie direkt in die Sicherheitsgrenzen eingreifen: Auth-Bibliotheken, JWT, Krypto, HTML-Sanitizer, Template-Engines, Markdown-Parser, Uploads, Input-Validierung, ORMs, Datenbank-Treiber, HTTP-Clients, CORS-Middleware, Rate-Limiting, Logging und Secret-Management.

Wenn die KI eine dieser Bibliotheken ersetzt oder neu konfiguriert, muss der Review auch das Anwendungsverhalten lesen. Ein neuer Parser kann die XSS-Behandlung ändern; eine CORS-Middleware kann ungeplante Domänen öffnen; ein ORM-Update kann Abfragen oder Escaping verändern; ein Upload-Paket kann MIME-Types oder Pfade anders akzeptieren; eine JWT-Bibliothek kann explizite Konfigurationen für Algorithmus, Audience oder Issuer erfordern. Diese Abhängigkeiten sollten nicht nur deshalb genehmigt werden, weil sie keine bekannten CVEs haben: Die Frage ist, ob sie korrekt für das Produkt konfiguriert sind. Hier treffen Supply Chain und Application Security aufeinander.

Von Agenten automatisch generierte Befehle

Wenn ein Agent Zugriff auf das Terminal hat, kann er Installationen, Updates, Migrationen, Tests, Build-Skripte, Cloud-Befehle und Konfigurationsänderungen ausführen. Das Befehls-Log wird Teil des Reviews: Es reicht nicht, sich den finalen Code anzusehen, man muss wissen, was ausgeführt wurde.

Ein Befehl kann unerwartete Dateien ändern, Lockfiles aktualisieren, globale Pakete installieren, lokale Konfigurationen ändern, Artefakte generieren, Caches erstellen oder Daten an externe Dienste senden. In Umgebungen mit Secrets, Token oder Cloud-Anmeldedaten steigt das Risiko weiter. Für operative Agenten ist es notwendig, Allowlists für Befehle zu definieren, Genehmigungen für Installationen und Deployments zu verlangen, Sandbox-Umgebungen und Token mit minimalem Scope zu verwenden sowie Logs aufzubewahren. Wenn der Agent Pakete ohne Genehmigung installiert, beginnt der Review-Prozess bereits zu spät.

Merge-Richtlinien für KI-generierte Abhängigkeiten

Eine effektive Richtlinie sollte nicht jede Änderung blockieren, sondern Entscheidungen explizit machen. Jede neue Abhängigkeit, die von der KI vorgeschlagen oder installiert wird, sollte Folgendes angeben: Grund, Paketmanager, Version, Lizenz, Maintainer, berücksichtigte Alternativen, Auswirkungen auf die Lockfile, SCA-Ergebnisse, eventuelle Skripte und interner Owner.

Abhängigkeiten mit hohem Risiko sollten eine explizite Genehmigung erfordern: nicht gewartete Pakete, Bibliotheken mit wenigen Downloads, Sicherheits-Wrapper, Parser, Template-Engines, Upload-Handler, Krypto, Auth, Networking, Pakete, die Skripte ausführen, neue Basis-Images und Tools, die in die CI/CD gelangen. Für Teams, die KI-Coding kontinuierlich nutzen, wird diese Richtlinie Teil des Software Assurance Lifecycle: Es ist nicht nötig, jedes Mal eine Ausnahme zu machen, sondern einen wiederholbaren Pfad zu haben, um zu installieren, zu bewerten, zu genehmigen und zu überwachen.

Wie ISGroup die Supply Chain und KI-generierte Abhängigkeiten überprüft

ISGroup kann einen PR, ein Repository oder einen Release-Prozess überprüfen, bei dem KI-Agenten Abhängigkeiten, Lockfiles, Dockerfiles, Workflows, Skripte oder Paket-Registrys ändern. Die Kontrolle betrifft sowohl den Code als auch die Kette, die ihn in die Produktion bringt.

Wenn die KI Folgendes geändert hat…	Hauptrisiko	Empfohlene Kontrolle
Manifest, Lockfile, Paket, Skript, Dockerfile oder Dependency Tree	Anfällige, unnötige oder nicht verwaltete Abhängigkeiten	Code Review
Online exponierte Komponenten, Dienste, Bibliotheken und Versionen	Bekannte ausnutzbare Schwachstellen	Vulnerability Assessment
Abhängigkeiten und Komponenten in Produktion, die überwacht werden müssen	Wiederkehrende Schwachstellen und Patch-Management	Vulnerability Management Service
Pipeline, Merge-Richtlinien, SCA-Kontrollen, SBOM und Release-Gates	Nicht wiederholbarer Prozess bei Releases	Software Assurance Lifecycle
Cloud, Container-Registry, IAM, Token, Artefakte und Deployments	Fehlkonfiguration oder übermäßige Privilegien	Cloud Security Assessment

Die Wahl der Kontrolle hängt davon ab, an welchem Punkt das Risiko eintritt: Code und Manifest, exponierte Komponenten, Patching-Prozess, Pipeline oder Cloud. Vor dem Merge sollte man wissen, ob das Paket wirklich benötigt wird und ob der Build steuerbar bleibt. Wenn Sie einen von KI generierten PR haben, der Pakete hinzufügt, Lockfiles ändert oder Pipelines verändert, kann ISGroup Ihnen helfen, Abhängigkeiten, Skripte, Container, SBOMs und Merge-Kontrollen vor dem Release zu überprüfen.

Für eine Überprüfung vorzubereitende Nachweise

Um eine effektive Überprüfung zu starten, ist es nützlich, Repositorys, Branches, PRs, Manifeste, Lockfiles, Dependency Trees, Dockerfiles, CI/CD-Workflows, verwendete Scanner, SCA-Berichte, Lizenzberichte, SBOMs (falls vorhanden), vom Agenten ausgeführte Befehle, beteiligte Token, verwendete Registrys und die Begründung für neue Abhängigkeiten zu sammeln.

Für jedes hinzugefügte Paket ist es nützlich, Name, Version, Registry, Maintainer, Repository, Lizenz, verfügbare Alternativen, technischen Grund, transitive Abhängigkeiten, Installationsskripte und internen Owner zu dokumentieren. Wenn der Agent Befehle ausgeführt hat, ist es wichtig, Logs und Ausgaben aufzubewahren. Diese Nachweise ermöglichen es, eine notwendige Abhängigkeit von einer generierten Abkürzung, ein blockierendes Risiko von einem planbaren Update und eine bekannte Schwachstelle von einem Prozessproblem zu unterscheiden.

Wann der Merge blockiert werden sollte

Blockieren Sie den Merge, wenn eine neue Abhängigkeit verdächtig, unnötig, nicht gewartet, mit inkompatibler Lizenz, mit nicht verifizierten Skripten, mit nicht geminderter kritischer Schwachstelle, mit zu umfangreicher Lockfile ohne Erklärung versehen ist oder wenn die Pipeline geändert wurde, um Kontrollen zu umgehen.

Sie können Aktivitäten mit geringem Restrisiko nach dem Merge planen: Dokumentation verbessern, SBOM generieren (wenn das Release nicht unmittelbar bevorsteht), Richtlinien verfeinern, Scanning-Muster hinzufügen oder nicht kritische Abhängigkeiten mit Owner und Frist reduzieren. Abhängigkeiten, die Code ausführen, die Sicherheit berühren oder in die Produktion gelangen, müssen vorher geklärt sein.

Supply-Chain-Checkliste für von Agenten generierte PRs

• Jede neue Abhängigkeit hat einen Grund, einen Owner und eine bewertete Alternative.
• Manifest und Lockfile werden zusammen überprüft.
• Paketname, Maintainer, Registry und Repository sind verifiziert.
• preinstall-, install-, postinstall-, prepare-Skripte und Builds sind kontrolliert.
• SCA, Lizenz-Scanning und Container-Scanning sind durchgeführt.
• Versionen und Basis-Images haben explizite Pins, ohne unbegründetes latest.
• SBOM generiert oder aktualisiert, wenn das Produkt dies erfordert.
• Registry-Token und CI/CD haben minimalen Scope.
• Vom Agenten ausgeführte Befehle sind protokolliert und wo nötig genehmigt.
• KI-generierte Abhängigkeiten durchlaufen vor dem Merge eine obligatorische Überprüfung.

Häufig gestellte Fragen

• Wenn der SCA-Scanner sauber ist, kann ich die Abhängigkeit akzeptieren?
• Nicht automatisch. Der Scanner bewertet nicht Notwendigkeit, Lizenz, Maintainer, Typosquatting, Installationsskripte, Konsistenz der Lockfile und Auswirkungen auf das Produkt. Er ist ein unterstützendes Werkzeug, keine grüne Ampel.
• Muss die Lockfile wirklich überprüft werden?
• Ja. Die Lockfile zeigt, was tatsächlich in den Build einfließt, einschließlich transitiver Abhängigkeiten und indirekter Updates, die nicht im Manifest erscheinen.
• Kann ein Agent Pakete alleine installieren?
• Er kann es nur, wenn der Prozess dies zulässt. Bei Projekten mit echten Daten oder in der Produktion sollten Installationen und Befehle, die Abhängigkeiten ändern, eine explizite Genehmigung und aufbewahrte Logs erfordern.
• Wann wird eine SBOM benötigt?
• Wenn Sie Software liefern, auf Enterprise-Kundenanfragen antworten, Schwachstellen über die Zeit verwalten oder schnell wissen müssen, ob eine CVE ein spezifisches Release betrifft.
• Was ändert sich im Vergleich zu einem normalen Code Review?
• Das Code Review liest den Code. Das Supply-Chain-Review liest auch Manifeste, Lockfiles, Skripte, Registrys, Container, SBOMs, Lizenzen, ausgeführte Befehle und Pipelines.
• Wann wird der Vulnerability Management Service benötigt?
• Wenn das Problem nicht nur darin besteht, einen PR zu kontrollieren, sondern kontinuierlich Komponenten, Versionen und Schwachstellen in der Produktion über die Zeit zu überwachen.

[Callforaction-WAPT-Footer]

Quellen und nützliche Referenzen

• OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/
• OWASP CycloneDX: https://owasp.org/www-project-cyclonedx/
• OpenSSF Scorecard: https://openssf.org/scorecard/
• OpenSSF SLSA: https://openssf.org/projects/slsa/
• OWASP SAMM: https://owasp.org/www-project-samm/
• OWASP Top 10 – Vulnerable and Outdated Components: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/