KI & Sicherheit

Drittanbieter, Updates und Supply Chain

Warum Dependencies, Lockfiles, CI Actions und Images bewusst geprüft statt nebenbei aktualisiert werden sollten.

Stand: 2026-06-03

Kurzfassung

  • Jede neue Dependency ist neuer Fremdcode.
  • Standardtechnologien und bestehender Projektcode haben Vorrang.
  • Deployment installiert aus Lockfiles, Updates passieren im PR.
  • Dependency-Updates möglichst eigene PRs oder eigene Commits.
  • Lockfile-Änderungen werden bewusst reviewed.
  • KI-Agenten dürfen Dependency-Updates nicht nebenbei ausführen.
  • Keine latest-Images und keine @main/@master Actions in produktionsnahen Pfaden.

Thema

Drittanbieter, automatische Updates und Software Supply Chain in Kundenprojekten.

Ausgangslage

In Kundenprojekten werden Drittanbieter-Komponenten regelmäßig genutzt:

  • npm/pnpm Packages,
  • Tailwind-/Frontend-Komponenten,
  • Composer Packages,
  • Symfony Bundles,
  • TYPO3 Extensions,
  • Docker Images,
  • GitHub Actions oder vergleichbare CI Actions,
  • Build- und Release-Tools.

Deployments laufen grundsätzlich über CI/CD-Prozesse auf Git-Repositories. Virtuelle Maschinen oder Build-Umgebungen werden gebaut und geprüft, Assets werden vorab kompiliert. Im Deployment wird grob gesagt nicht composer update, sondern composer install auf Basis von Lockfiles genutzt.

Die wichtigste praktische Erkenntnis:

Nicht Deployment ist der Update-Ort. Der Pull Request ist der Update-Ort.

Risiko in einem Satz

Kompromittierte oder unbewusst aktualisierte Drittanbieter-Komponenten können über Dependency-Updates, Lockfile-Änderungen, CI Actions, Docker Images oder KI-Agenten in Kundenprojekte gelangen.

Grundsatz

Standardtechnologien und bestehender Projektcode haben Vorrang vor neuen Dependencies.

Das bedeutet nicht, dass Fremdtools verboten sind. Es bedeutet:

Jede zusätzliche Abhängigkeit ist zusätzlicher Fremdcode, zusätzlicher Update-Aufwand und zusätzliche Supply-Chain-Angriffsfläche.

Eine neue Dependency braucht einen klaren Grund.

Empfehlung

Dependency-Updates dürfen nicht nebenbei passieren. Sie sollen möglichst in eigenen PRs oder eigenen Commits erfolgen.

Ausnahmen sind möglich, wenn eine neue Dependency zwingend Teil einer Feature-Änderung ist. Dann muss sie im PR klar benannt und begründet werden.

Für Release-Builds gilt:

  • keine Updates im Deployment,
  • Installation aus Lockfiles,
  • reproduzierbare Builds,
  • geprüfte Dependency-Änderungen vor dem Release.

Deployment-Regel

Deployment und Release-Builds ziehen keine neuen Dependency-Versionen.

Composer:

  • composer.lock ist committed.
  • CI/Release nutzt composer install, nicht composer update.

npm:

  • package-lock.json ist committed.
  • CI/Release nutzt npm ci, nicht npm install oder npm update.

pnpm:

  • pnpm-lock.yaml ist committed.
  • CI/Release nutzt pnpm install --frozen-lockfile, nicht pnpm update.

Wandregel:

Release-Builds installieren aus Lockfiles, nicht aus Hoffnung.

Pull-Request-Regel

Lockfile-Änderungen sind reviewpflichtig.

Besonders prüfen bei Änderungen an:

  • composer.json,
  • composer.lock,
  • package.json,
  • package-lock.json,
  • pnpm-lock.yaml,
  • yarn.lock.

Review-Fragen:

  • Warum ist das Update nötig?
  • Welche direkten Pakete wurden geändert?
  • Welche transitiven Pakete kamen dazu?
  • Ist es Patch, Minor oder Major?
  • Gibt es neue Maintainer, Registries oder Repository-Quellen?
  • Gibt es neue Scripts oder Plugins?
  • Gibt es Security Advisories?
  • Hat KI das Update ausgelöst?
  • Wurde lokal und in CI getestet?

KI-Agent-Regel

KI-Agenten dürfen Dependency-Updates nicht selbstständig oder nebenbei ausführen.

Riskante Commands:

  • composer update
  • composer require
  • npm install
  • npm update
  • pnpm add
  • pnpm update
  • npm audit fix --force

Wenn ein Agent solche Commands vorschlägt oder ausführen will, muss er vorher:

  • Zweck nennen,
  • betroffene Pakete nennen,
  • erwartete Dateien nennen,
  • auf Lockfile-Änderungen hinweisen,
  • auf Scripts/Plugins hinweisen,
  • Freigabe abwarten.

Nach der Ausführung muss der Agent zusammenfassen:

  • welche Dateien geändert wurden,
  • welche Pakete neu oder aktualisiert wurden,
  • warum die Änderung nötig war,
  • ob Lockfiles geändert wurden,
  • ob Scripts, Plugins oder externe Quellen betroffen sind.

GitHub Actions und CI Actions

CI Actions sind ausführbarer Fremdcode.

P0-Regeln:

  • Kein @main oder @master.
  • Keine unbekannte Marketplace-Action ohne Review.
  • Keine neue CI Action nebenbei in einem Feature-PR.
  • Actions mit Zugriff auf Secrets oder Deployment besonders prüfen.

P1-Regeln:

  • Häufig genutzte Actions inventarisieren.
  • Actions in sensiblen Projekten auf Commit-SHA pinnen.
  • Drittanbieter-Actions mit hoher Berechtigung minimieren oder ersetzen.
  • CI Permissions explizit setzen.

Wandregel:

CI Actions sind ausführbarer Fremdcode.

Docker und Build Images

Auf latest und Image-Pinning wird wahrscheinlich noch nicht konsequent geachtet. Das sollte systematisch geprüft werden.

P0-Regeln:

  • Keine latest-Images in Deployment- oder produktionsnahen Builds.
  • Keine neuen latest-Images durch KI-Agenten oder Copy/Paste übernehmen.
  • Build- und Deploy-Images müssen mindestens auf eine konkrete Version festgelegt sein.

P1-Regeln:

  • CI/CD und Dockerfiles auf latest prüfen.
  • ddev/docker-compose Dateien prüfen.
  • Basisimages inventarisieren.
  • Bei sensiblen Projekten Images auf Digest pinnen.
  • Updates von Build Images wie Dependency-Updates behandeln.

Wandregel:

Keine latest-Images in produktionsnahen Builds.

npm/pnpm Scripts

postinstall, prepare, preinstall und andere Package-Scripts werden aktuell eher nicht bewusst geprüft. Das ist ein relevanter Supply-Chain-Punkt.

Risiko:

  • Pakete können beim Installieren Code ausführen.
  • Dieser Code läuft auf Entwicklerrechnern oder in CI.
  • Er kann Dateien lesen, Netzwerkzugriffe machen oder Build-Artefakte manipulieren.

P0-Regeln:

  • Neue npm/pnpm Dependencies mit Install-Scripts brauchen besondere Prüfung.
  • KI-Agenten dürfen neue Dependencies nicht hinzufügen, ohne auf Scripts hinzuweisen.
  • Keine unbekannten UI-/Tailwind-/Component-Packages blind installieren.
  • Kein npm audit fix --force ohne Review.

P1-Regeln:

  • pnpm approve-builds prüfen, falls pnpm genutzt wird.
  • ignore-scripts für bestimmte Install-Situationen prüfen.
  • Dependency-Review-Tooling prüfen.
  • CI-Umgebungsrechte minimieren, damit Install-Scripts nicht unnötig Secrets sehen.

Wandregel:

Neue Dependencies mit Install-Scripts sind ausführbarer Fremdcode.

Composer, Symfony und TYPO3

Composer-Änderungen laufen bisher eher im normalen Code Review mit, aber nicht immer als eigener Supply-Chain-Prüfpunkt.

P0-Regeln:

  • Neue Composer Plugins brauchen explizite Freigabe.
  • Neue TYPO3 Extensions und Symfony Bundles brauchen bewussten Review.
  • composer require und composer update durch KI nur nach Freigabe.
  • Composer Scripts werden bei Änderungen bewusst geprüft.
  • Keine neuen privaten Repositories oder Forks ohne Begründung.

P1-Regeln:

  • composer audit in CI prüfen.
  • composer.lock-Änderungen gezielt reviewen.
  • Composer Plugins inventarisieren.
  • TYPO3 Extensions inventarisieren.
  • Bei kritischen Kundenprojekten prüfen, ob nur bekannte Repositories erlaubt sind.

Wandregel:

Composer-Updates sind Codeänderungen, nicht Wartungsrauschen.

Frontend- und UI-Dependencies

Fertige Komponenten werden eher über npm/pnpm Dependencies eingebunden als unkontrolliert kopiert. Das macht Änderungen besser prüfbar, aber nicht automatisch sicher.

P0-Regeln:

  • Neue UI-/Tailwind-/Frontend-Pakete brauchen Review.
  • Keine Pakete nur wegen KI-Vorschlag installieren.
  • Keine unbekannten Component-Packages ohne Zweck und Maintainer-Check.
  • Keine unnötigen Dependencies für kleine UI-Probleme.

P1-Regeln:

  • Etablierte und gepflegte Pakete bevorzugen.
  • Kleine Komponenten bei Bedarf selbst schreiben statt Dependency aufnehmen.
  • Neue Frontend-Pakete in eigenen PR/Commit aufnehmen.
  • Lockfile-Diff prüfen.

Wandregel:

Weniger Fremdcode, weniger Angriffsfläche.

Dependabot und Renovate

Automatische Update-PRs werden vermutlich aktuell nicht oder nicht bewusst genutzt.

Einordnung:

  • kein akutes Risiko durch automatische Update-PR-Flut,
  • aber mögliches Risiko verpasster Security-Updates,
  • später als P2-Thema prüfen.

Wenn eingeführt:

  • keine Auto-Merges,
  • Security-Updates priorisieren,
  • Major Updates separat behandeln,
  • Update-PRs getrennt nach Package Manager und Risiko,
  • Lockfile-Änderungen trotzdem reviewen.

P0-No-Gos

  • Kein composer update, npm update oder pnpm update im Deployment.
  • Keine blind übernommenen Lockfile-Änderungen.
  • Keine neuen Dependencies nur wegen KI-Vorschlag.
  • Keine Dependency-Updates nebenbei in Feature-PRs verstecken.
  • Keine latest-Images in produktionsnahen Builds.
  • Keine @main/@master Actions.
  • Keine unbekannten Marketplace Actions ohne Review.
  • Keine KI-Agent-Updates ohne Freigabe.
  • Kein npm audit fix --force ohne Review.

Vorgeschlagene Wandregel

Dependency-Updates sind eigene Änderungen. Nicht nebenbei mergen.

Alternative Kurzregeln:

Jede neue Dependency ist neuer Fremdcode.

Weniger Fremdcode, weniger Angriffsfläche.

Teamfragen zur Entscheidung

  • Welche Package Manager sind je Projekt verbindlich?
  • Welche Lockfiles müssen committed sein?
  • Sollen Dependency-Updates verpflichtend eigene PRs oder eigene Commits sein?
  • Welche Commands sind für KI-Agenten blockiert oder nur nach Freigabe erlaubt?
  • Wie prüfen wir Lockfile-Änderungen im Review?
  • Welche GitHub Actions oder CI Actions nutzen wir?
  • Wo gibt es noch latest-Images?
  • Wollen wir composer audit, npm audit, pnpm approve-builds oder andere Checks in CI nutzen?
  • Welche Dependencies sind in bestehenden Projekten unnötig und könnten reduziert werden?