Dependency Management & Supply Chain Security

Worum es geht

Frameworks, Bibliotheken, ein transitives Geflecht aus Abhängigkeiten: Der größte Teil deiner Anwendung stammt nicht von dir. Wenn dieser Code kompromittiert wird, ist deine Anwendung kompromittiert. Und die Bedrohungslage verschärft sich.

• 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.
• KI ohne Aufsicht. KI-Agenten 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 lernst du, Dependency Management und Supply Chain Security zusammen zu denken: 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. Denn wer Abhängigkeiten nicht versteht, kann sie nicht absichern. Und wer sie absichert, aber nicht aktualisiert, steht beim nächsten Advisory wieder am Anfang.

Das Beispielprojekt

Ein durchgängiges Beispielprojekt begleitet dich durch alle fünf 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.

• Verwundbar, aber installiert. composer install installiert jede gelockte Version, auch die mit bekannten Lücken. composer update verweigert sich, weil der Resolver sie nicht mehr hereinlässt.
• Offene Türen. allow-plugins: true, minimum-stability: dev, eine Versionsbeschränkung * und ein Script, das bei jeder Installation etwas aus dem Netz lädt.
• Code an Composer vorbei. Eine kopierte Bibliothek mit zwei bekannten Lücken, die composer audit nicht meldet, weil Composer sie nicht kennt.
• Festgefahren. Dompdf an vier Stellen im Code, ein aufgegebener Mailer, die Plattform auf PHP 7.4 festgenagelt. Jedes Update wird zur Kettenreaktion.

Jede Sitzung bringt Faktura eine Station weiter: verstanden, konfiguriert, entkoppelt, abgesichert und automatisiert. 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. Nach jeder Sitzung gibt es ihren Stand als eigenen Branch: Wer nicht fertig geworden ist, steigt am nächsten Morgen damit wieder ein.

Ablauf

1. 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: was bei require, install und update wirklich geschieht
   • composer.json und composer.lock: warum der Unterschied sicherheitsrelevant ist
   • Semantic Versioning, Versionsbeschränkungen und Plattform-Anforderungen gezielt einsetzen

   Ergebnis: Die Befundliste für Faktura, aus der der Plan für die Woche folgt

2. 2

   Sitzung 2: Composer für reale Projekte

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

   • Private Repositories und Authentifizierung sauber einrichten: 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. 3

   Sitzung 3: Architektur

   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. 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
   • LLM-basierte Sicherheitswerkzeuge: was sie leisten und wo ihre Grenzen sind

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

5. 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
   • PHP-Major-Updates mit Rector bewältigen
   • Guardrails für KI-Agenten im Update-Prozess etablieren

   Ergebnis: Ein gehärteter Workflow, eine renovate.json und Guardrails, die auch ein KI-Agent nicht umgeht

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 KI-Agenten 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
• Einen Editor deiner Wahl
• Keine Erfahrung mit automatisierten Tests: Das Beispielprojekt bringt seine Tests mit

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 Audit-Funde fundiert
• Du automatisierst Updates mit Renovate, abgesichert durch CI, sodass dein Projekt dauerhaft aktuell bleibt
• Du weißt, was LLM-basierte Sicherheitswerkzeuge leisten und wo ihre Grenzen sind
• Du hast ein Vorgehen für KI-Agenten, die Abhängigkeiten hinzufügen
• Du nimmst Faktura im Endstand als Referenz für deine eigenen Projekte mit: Composer-Policies, SBOM, gehärtete CI, Renovate und Guardrails