Dependency Management & Supply Chain Security

What it is about

Frameworks, libraries, a transitive web of dependencies: the largest part of your application does not come from you. When that code is compromised, your application is compromised. And the threat situation is getting worse.

• Faster discoveries. Security vulnerabilities are found faster and faster, through better static analysis and through LLM-based tools. For Twig, 17 security advisories were published in 2026 up to the end of September, against 9 in all the years before combined.
• More attacks. Supply chain attacks on open source packages are increasing, from typosquatting to account hijacking. On Packagist, too: in 2026 they hit intercom/intercom-php and the laravel-lang packages.
• AI without oversight. AI agents add dependencies without anyone checking the consequences.
• Postponed updates. Updates are postponed until at some point nothing fits together any more.

In this training you learn to think about dependency management and supply chain security as a whole: what Composer does on every installation, how to integrate dependencies so that an update does not trigger a chain reaction, which attacks on the supply chain exist and what helps against which, and how updates become routine. 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.

The example project

One 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, and it uses libraries you know from your own projects: Dompdf, Twig, Guzzle, Monolog, Swift Mailer, Carbon, and Symfony's Console component.

• Vulnerable, yet installed. composer install installs every locked version, including those with known vulnerabilities. composer update refuses, because the resolver no longer lets them in.
• Open doors. allow-plugins: true, minimum-stability: dev, a version constraint of *, and a script that downloads something from the internet on every installation.
• Code that bypasses Composer. A copied library with two known vulnerabilities that composer audit does not report, because Composer does not know about it.
• Stuck. Dompdf in four places in the code, an abandoned mailer, the platform pinned to PHP 7.4. Every update turns into a chain reaction.

Each session moves Faktura one station further: understood, configured, decoupled, secured, and automated. You work on it yourself, in your own copy on GitHub, with CI and Renovate as in a real project, and take Faktura away as a reference at the end.

A container for Podman or Docker brings everything the exercises need. After each session, its state is available as a branch of its own: if you did not finish, you pick up from there the next morning.

Programme

1. 1

   Session 1: The situation & the Composer foundation

   What really happens on require, install, and update, and why does it matter for security?

   • Real incidents as a picture of the situation: what actually happens in supply chain attacks
   • Composer mechanics under the hood: what really happens on require, install, and update
   • composer.json and composer.lock: why the difference is relevant to security
   • Using semantic versioning, version constraints, and platform requirements deliberately

   Result: The list of findings for Faktura from which the plan for the week follows

2. 2

   Session 2: Composer for real projects

   Which code runs on every installation, and who may install from where?

   • Setting up private repositories and authentication cleanly: an internal package with a token that can only read and lives in no repository
   • Composer plugins as a security topic: code that runs on every installation
   • Autoloading strategies and their consequences
   • Scripts and hooks: automation in moderation

   Result: A composer.json that describes what actually applies, and the internal package via Composer instead of copied

3. 3

   Session 3: Architecture

   How do you swap a library without triggering a chain reaction?

   • Decoupling dependencies with adapter, facade, and anti-corruption layer
   • Updating and swapping libraries without a chain reaction
   • Where decoupling pays off and where it only adds complexity
   • On the example project: Dompdf behind an adapter, sending email behind a facade, the exchange rates behind an anti-corruption layer

   Result: A dependency map and two major version changes that each touch one place in the code instead of four

4. 4

   Session 4: Supply chain security

   Is your project actually affected by this finding?

   • The threat model in depth: SBOM, SLSA, typosquatting, account hijacking
   • composer audit in practice: assessing findings soundly instead of reacting blindly
   • The bouncer in the resolver: blocking vulnerable, malicious, and abandoned versions with Composer policies
   • LLM-based security tools: what they can do and where their limits are

   Result: A threat model for Faktura, a Composer policy with justified decisions, an SBOM, and a release gate

5. 5

   Session 5: Automating updates

   How does a project stay up to date without risking its stability?

   • Configuring Renovate: from the first pull request to the merge strategy
   • CI as a safety net for automated updates, and hardening the CI itself against attacks
   • Handling PHP major updates with Rector
   • Establishing guardrails for AI agents in the update process

   Result: A hardened workflow, a renovate.json, and guardrails that even an AI agent cannot get around

Who it is for

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

Prerequisites

• A few months of experience with PHP or a similar programming language
• Basic Composer knowledge is helpful, but not a requirement: we start with what Composer actually does on install and update
• A local development environment with PHP 8.2 or newer, Composer 2.10 or newer, Git, and a terminal, or Podman or Docker for the container that brings everything along
• A GitHub account for your own copy of the example project; a free one is enough
• An editor of your choice
• No experience with automated tests: the example project comes with its own tests

What you take away

• You configure Composer specifically for real requirements, including private repositories, platform requirements, and authentication
• You use version constraints deliberately and know which operator fits when
• You decouple dependencies architecturally, so that updates and swaps do not trigger a chain reaction
• You understand the threat model of the software supply chain and assess audit findings soundly
• You automate updates with Renovate, secured by CI, so that your project stays up to date permanently
• You know what LLM-based security tools can do and where their limits are
• You have an approach for AI agents that add dependencies
• You take Faktura in its final state away as a reference for your own projects: Composer policies, SBOM, hardened CI, Renovate, and guardrails