Dependency Management & Supply Chain Security

80 to 95 percent of your application is code you did not write – frameworks, libraries, a transitive web of dependencies. If that code is compromised, your application is compromised.

Security vulnerabilities are found faster and faster – through better static analysis and through LLM-based tools. Supply chain attacks on Open Source packages are on the rise. AI agents add dependencies without anyone reviewing the consequences. And updates keep getting postponed until nothing fits together any more.

In this training, you will learn to think about dependency management and supply chain security as one whole. We cover advanced Composer usage, design patterns such as the Adapter for decoupling dependencies, the threat model of the software supply chain, and the automation of safe updates. If you do not understand your dependencies, you cannot secure them. And if you secure them but do not update them, you are back to square one with the next advisory.

A continuous example project accompanies you through all five sessions: Faktura, the invoicing tool of a fictitious company. A command-line program that renders invoices as PDF, sends them by email and loads the exchange rates of the European Central Bank, written for PHP 7.4 in 2021 and last updated in 2022. It works. Nobody likes touching it. And it uses libraries you know from your own projects: Dompdf, Twig, Guzzle, Monolog, Swift Mailer, Carbon, and Symfony's Console component.

composer install installs Faktura without complaint, dozens of known vulnerabilities included. composer update refuses, because the resolver no longer lets vulnerable versions in. On top of that come allow-plugins: true, a version constraint of *, a script that downloads something from the internet on every installation, a copied library that composer audit cannot see, and Dompdf in four places in the code.

Each session moves Faktura one station further: understood, configured, decoupled, secured, automated. You work on it yourself, in your own copy on GitHub, with CI and Renovate as in a real project. A container for Podman or Docker brings everything the exercises need. After each session, its state is available as a branch of its own, so that everybody continues from the same point in the next session. In the end, Faktura is production-ready, secured, and automated, and you take it home as a reference.

Five two-hour online sessions, moving from symptom to solution to safeguarding to automation. Each session delivers a concrete artefact that you can apply in your own projects afterwards.

• Session 1 – Situation & Composer foundations: Real-world incidents as a situational picture, Composer mechanics under the hood, composer.json vs. composer.lock, Semantic Versioning, and platform requirements. Your result: the list of findings for Faktura from which the plan for the remaining sessions follows.
• Session 2 – Composer for real-world projects: Private repositories and authentication, Composer plugins as a security topic, autoloading strategies, scripts and hooks. Your result: a composer.json that describes what actually applies, and an internal package from a private repository, with a token that lives nowhere in the code.
• Session 3 – Architecture: Decouple dependencies with Adapter, Facade, and Anti-Corruption Layer so that updates and replacements do not trigger a chain reaction, and recognise where decoupling only adds complexity. Your result: a dependency map and two major version changes that each touch one place in the code instead of four.
• Session 4 – Supply chain security: An in-depth threat model (SBOM, SLSA, typosquatting, account hijacking), composer audit in practice, Composer policies against vulnerable, malicious, and abandoned versions, LLM-based security tools. Your result: a threat model, a Composer policy with justified decisions, an SBOM, and a release gate.
• Session 5 – Automating updates: Configuring Renovate, CI as a safety net and hardening the CI itself, PHP major updates with Rector, guardrails for AI agents in the update process. Your result: a hardened workflow, a renovate.json, and guardrails that even an AI agent cannot get around.

• Understand Semantic Versioning and use version constraints in Composer effectively
• Configure Composer for real-world projects: private repositories, platform requirements, authentication, autoloading
• Decouple dependencies architecturally with Adapter, Facade, and Anti-Corruption Layer
• Understand the threat model of the software supply chain and assess audit findings soundly
• Automate updates with Renovate, safeguarded by CI
• Recognise what LLM-based security tools can do and where their limits are
• Establish guardrails for AI agents that add dependencies

• PHP developers who use Composer but are unsure about configuration and version constraints
• Teams that keep postponing updates because they expect breaking changes
• Developers who take supply chain risks seriously and want to secure their software supply chain
• Tech leads and architects who want to establish a sustainable update and audit process
• Teams where AI agents add dependencies without anyone reviewing the consequences
• Security professionals who want to understand what is possible and common in the Composer world

You should have several months of experience programming in PHP or a similar programming language. Basic Composer knowledge (require, install, update) is helpful but not required: we start with what Composer actually does on install and update. You do not need any experience with automated tests, the example project comes with its own tests.

For the exercises you need a local PHP development environment (PHP 8.2 or newer, Composer 2.10 or newer, Git, a terminal) and an editor of your choice. Instead of PHP and Composer, Podman or Docker will do: a container with everything the exercises need is ready for you. You also need a GitHub account for your own copy of the example project; a free one is enough.

• Configure Composer specifically for real-world requirements, including private repositories, platform requirements, and authentication
• Set version constraints deliberately and know when which operator is the right one
• Decouple dependencies architecturally so that updates and replacements do not trigger a chain reaction
• Understand the threat model of the software supply chain and assess audit findings soundly
• Automate updates with Renovate, safeguarded by CI, so that your project stays up to date for good
• Recognise what LLM-based security tools can do and where their limits are
• Develop a process for AI agents that add dependencies
• Take Faktura in its final state home as a reference for your own projects: Composer policies, SBOM, hardened CI, Renovate, and guardrails