Schulung · Aufbau

Dependency Management & Supply Chain Security

Abhängigkeiten beherrschen, die Lieferkette absichern, Updates automatisieren

Updates aufgeschoben, Lieferkette unklar, KI-Agenten fügen Pakete hinzu? Lerne, Abhängigkeiten mit Composer zu beherrschen, und sichere deine Software-Lieferkette gegen reale Angriffe ab.

  • Umfang 6 Sitzungen à 2 Stunden
  • Format Live über Zoom
  • Sprache Deutsch
  • Preis pro Person 1.199 €

Der Termin ab dem findet noch in der bisherigen Fassung mit 5 Sitzungen statt: Details zu diesem Termin.

Worum es geht

Frameworks, Bibliotheken, ein transitives Geflecht aus Abhängigkeiten: 80 bis 95 Prozent deiner Anwendung stammen nicht von dir. Wird dieser Code kompromittiert, ist deine Anwendung kompromittiert.

  • Schnellere Funde. Sicherheitslücken werden immer schneller gefunden, durch bessere statische Analyse und durch LLM-basierte Werkzeuge. Für Twig sind 2026 bis Ende September 17 Security Advisories erschienen, in allen Jahren davor zusammen 9.
  • Mehr Angriffe. Supply Chain-Angriffe auf Open-Source-Pakete nehmen zu, von Typosquatting bis Account-Hijacking. Auch auf Packagist: 2026 trafen sie intercom/intercom-php und die laravel-lang-Pakete.
  • Agenten ohne Aufsicht. Coding Agents fügen Abhängigkeiten hinzu, ohne dass jemand die Konsequenzen prüft.
  • Aufgeschobene Updates. Updates werden so lange aufgeschoben, bis irgendwann nichts mehr zusammenpasst.

In dieser Schulung denkst du Dependency Management und Supply Chain Security zusammen: was Composer bei jeder Installation tut, wie du Abhängigkeiten so einbaust, dass ein Update keine Kettenreaktion auslöst, welche Angriffe es auf die Lieferkette gibt und was gegen welchen hilft, und wie Updates zur Routine werden. Die letzte Sitzung gehört den Coding Agents: was sie an deinen Abhängigkeiten ändern dürfen, und wie du verhinderst, dass sie zum Einfallstor werden.

Das Beispielprojekt

Ein durchgängiges Beispielprojekt begleitet dich durch alle sechs Sitzungen: Faktura, das Rechnungswerkzeug einer fiktiven Firma. Ein Kommandozeilenprogramm, das Rechnungen als PDF erzeugt, per Mail verschickt und die Wechselkurse der Europäischen Zentralbank lädt, 2021 für PHP 7.4 geschrieben und zuletzt 2022 aktualisiert. Es funktioniert, und es benutzt Bibliotheken, die du aus deinen eigenen Projekten kennst: Dompdf, Twig, Guzzle, Monolog, Swift Mailer, Carbon und die Console-Komponente von Symfony.

Jede Sitzung bringt Faktura eine Station weiter: verstanden, konfiguriert, entkoppelt, abgesichert, automatisiert und schließlich agentenfest. Du arbeitest selbst daran, in deiner eigenen Kopie auf GitHub, mit CI und Renovate wie in einem echten Projekt, und nimmst Faktura am Ende als Referenz mit. Ein Container für Podman oder Docker bringt alles mit, was die Übungen brauchen, und nach jeder Sitzung gibt es ihren Stand als eigenen Branch.

Ablauf

  1. Sitzung 1: Lagebild & Composer-Fundament

    Was geschieht bei require, install und update wirklich, und warum ist das sicherheitsrelevant?

    • Reale Vorfälle als Lagebild: was bei Supply Chain-Angriffen tatsächlich passiert
    • Composer-Mechanik unter der Haube
    • composer.json und composer.lock: warum der Unterschied sicherheitsrelevant ist
    • Semantic Versioning, Versionsbeschränkungen und Plattform-Anforderungen gezielt einsetzen

    Ergebnis: Eine Befundliste für Faktura, aus der der Plan für die folgenden Sitzungen folgt, und Versionsbeschränkungen, die begründet statt kopiert sind

  2. Sitzung 2: Composer für reale Projekte

    Welcher Code läuft bei jeder Installation, und wer darf woher installieren?

    • Private Repositories und Authentifizierung: ein internes Paket mit einem Token, das nur lesen darf und in keinem Repository liegt
    • Composer-Plugins als Sicherheitsthema: Code, der bei jeder Installation läuft
    • Autoloading-Strategien und ihre Auswirkungen
    • Scripts und Hooks: Automatisierung mit Augenmaß

    Ergebnis: Eine composer.json, die beschreibt, was gilt, und das interne Paket über Composer statt kopiert

  3. Sitzung 3: Architektur: Entkopplung

    Wie wechselst du eine Bibliothek, ohne eine Kettenreaktion auszulösen?

    • Abhängigkeiten mit Adapter, Facade und Anti-Corruption Layer entkoppeln
    • Updates und Wechsel von Bibliotheken ohne Kettenreaktion
    • Wo Entkopplung sich lohnt und wo sie nur Komplexität hinzufügt
    • Am Beispielprojekt: Dompdf hinter einem Adapter, der Mailversand hinter einer Facade, die Wechselkurse hinter einem Anti-Corruption Layer

    Ergebnis: Eine Abhängigkeitskarte und zwei Major-Wechsel, die jeweils eine Stelle im Code berühren statt vier

  4. Sitzung 4: Supply Chain Security

    Ist dein Projekt von diesem Fund tatsächlich betroffen?

    • Bedrohungsmodell mit Tiefe: SBOM, SLSA, Typosquatting, Account-Hijacking
    • composer audit in der Praxis: Funde fundiert bewerten statt blind reagieren
    • Der Türsteher im Resolver: verwundbare, bösartige und aufgegebene Versionen mit Composer-Policies blockieren
    • Abhängigkeiten sorgfältig auswählen, bevor sie ins Projekt kommen: Update-Historie, Maintainer, Abgleich mit Schwachstellendatenbanken
    • Wenn du selbst eine Schwachstelle in einer Abhängigkeit findest: die Maintainer informieren und den Fix teilen

    Ergebnis: Ein Bedrohungsmodell für Faktura, eine Composer-Policy mit begründeten Entscheidungen, eine SBOM und ein Release-Gate

  5. Sitzung 5: Updates automatisieren

    Wie bleibt ein Projekt aktuell, ohne die Stabilität zu riskieren?

    • Renovate konfigurieren: vom ersten Pull Request bis zur Merge-Strategie
    • CI als Sicherheitsnetz für automatisierte Updates, und die CI selbst gegen Angriffe härten
    • Update-Strategien: Abhängigkeiten laufend aktuell halten, statt Updates aufzuschieben, bis nichts mehr zusammenpasst
    • PHP-Major-Updates mit Rector bewältigen

    Ergebnis: Ein gehärteter Workflow, eine renovate.json mit begründeter Merge-Strategie und ein Plan für das nächste PHP-Major-Update

  6. Sitzung 6: Agenten in der Lieferkette

    Was darf ein Coding Agent an deinen Abhängigkeiten ändern?

    • Coding Agents, die Abhängigkeiten hinzufügen: Vorgehen und Review-Regeln für neue Pakete
    • Guardrails für Coding Agents im Update-Prozess
    • Berechtigungen und Sandboxing: Composer-Plugins und Scripts führen bei der Installation Code aus
    • Prompt Injection über Issues, Kommentare und Abhängigkeiten
    • LLM-basierte Sicherheitswerkzeuge: was sie leisten und wo ihre Grenzen sind

    Ergebnis: Guardrails für Faktura, die festlegen, was ein Agent an den Abhängigkeiten ändern darf und wer das prüft, erprobt an einem präparierten Issue mit Prompt Injection

Für wen

  • PHP-Entwicklerinnen und -Entwickler, die Composer nutzen, aber bei Konfiguration und Versionsbeschränkungen unsicher sind
  • Teams, die Updates immer wieder aufschieben, weil sie Breaking Changes erwarten
  • Entwicklerinnen und Entwickler, die Supply Chain-Risiken ernst nehmen und ihre Lieferkette absichern wollen
  • Tech Leads, Architektinnen und Architekten, die einen tragfähigen Update- und Audit-Prozess etablieren wollen
  • Teams, in denen Coding Agents Abhängigkeiten hinzufügen, ohne dass jemand die Konsequenzen prüft
  • Sicherheitsverantwortliche, die verstehen wollen, was in der Composer-Welt möglich und üblich ist

Voraussetzungen

  • Ein paar Monate Erfahrung mit PHP oder einer ähnlichen Programmiersprache
  • Grundlegende Composer-Kenntnisse sind hilfreich, aber keine Voraussetzung: Wir beginnen bei dem, was Composer bei install und update tatsächlich tut
  • Eine lokale Entwicklungsumgebung mit PHP 8.2 oder neuer, Composer 2.10 oder neuer, Git und einem Terminal, oder Podman bzw. Docker für den Container, der alles mitbringt
  • Ein GitHub-Konto für deine eigene Kopie des Beispielprojekts; ein kostenloses genügt
  • Keine Erfahrung mit automatisierten Tests: Das Beispielprojekt bringt seine Tests mit
  • Für die letzte Sitzung hilfreich: erste Erfahrung mit einem Coding Agent

Das nimmst du mit

  • Du konfigurierst Composer gezielt für reale Anforderungen, inklusive privater Repositories, Plattform-Anforderungen und Authentifizierung
  • Du setzt Versionsbeschränkungen bewusst ein und weißt, wann welcher Operator passt
  • Du entkoppelst Abhängigkeiten architektonisch, sodass Updates und Wechsel keine Kettenreaktion auslösen
  • Du verstehst das Bedrohungsmodell der Software Supply Chain und bewertest einen Audit-Fund danach, ob dein Projekt tatsächlich betroffen ist
  • Du automatisierst Updates mit Renovate, abgesichert durch CI, sodass dein Projekt dauerhaft aktuell bleibt
  • Du hast ein schriftliches Vorgehen dafür, was Coding Agents an deinen Abhängigkeiten ändern dürfen und wer das prüft
  • Du nimmst Faktura im Endstand als Referenz mit: Composer-Policies, SBOM, gehärtete CI, Renovate und Guardrails für Agenten

Verwandte Schulungen

Diese Schulung ist Teil der Lernpfade Sicherheit, Auf dem aktuellen Stand bleiben.

Dein Trainer

Sebastian Bergmann beantwortet die Frage eines Teilnehmers am Laptop
Foto: Filip Kovačević

Sebastian Bergmann ist der Schöpfer von PHPUnit, dem De-facto-Standard für das Testen von PHP-Code. Seit 2001 hilft er Teams als Berater und Trainer dabei, wartbare und gut getestete Software zu bauen, seit 2009 als Mitgründer von thePHP.cc.

Über Supply Chain Security mit Composer und sichere CI/CD-Pipelines spricht er 2026 auf der FrOSCon, der heise devSec, der International PHP Conference und der betterCode() PHP. Was er dort vertritt, steht auch in seinen Artikeln zu Supply Chain Security.