The situation
Most of the code is not your code
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
From poorly maintained to production-ready
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. 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.
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, and you work on it yourself: in your own copy on GitHub, with CI and Renovate as in a real project. In the end, Faktura is production-ready, secured, and automated, and you take it away as a reference.
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 at the start of the next session.
The programme
Five sessions, one common thread
From the symptom to the solution, from securing to automating. Each session lasts two hours, live and interactive, and delivers a concrete artefact that you can apply in your own projects afterwards.
The situation & the Composer foundation
2 hours- 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, andupdate composer.jsonvs.composer.lock: why the difference is relevant to security- Using semantic versioning, version constraints, and platform requirements deliberately
- Your result: the list of findings for Faktura from which the plan for the remaining sessions follows
Composer for real projects
2 hours- 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
- Your result: a
composer.jsonthat describes what actually applies, and the internal package via Composer instead of copied
Architecture
2 hours- 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
- Your result: a dependency map and two major version changes that each touch one place in the code instead of four
Supply chain security
2 hours- The threat model in depth: SBOM, SLSA, typosquatting, account hijacking
composer auditin 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
- Your result: a threat model for Faktura, a Composer policy with justified decisions, an SBOM, and a release gate
Automating updates
2 hours- 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
- Your result: a hardened workflow, a
renovate.json, and guardrails that even an AI agent cannot get around
Who it is for
Who should attend?
- 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
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
What you bring
- 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
installandupdate - 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
Your trainer
Sebastian Bergmann
Sebastian is the creator of PHPUnit, the de facto standard for testing PHP code. Since 2001 he has been helping teams build maintainable and well-tested software as a consultant and trainer, since 2009 as a co-founder of thePHP.cc.
In 2026 he speaks about supply chain security with Composer and secure CI/CD pipelines at FrOSCon, heise devSec, the International PHP Conference, and betterCode() PHP. What he argues there is also in his articles on supply chain security.
In this training you develop a poorly maintained project with him, step by step, into a production-ready, secured, and automated project. Live, on real code, with your questions.
Registration
Five interactive live sessions of two hours each, as a Zoom meeting. Small group, a real project, your questions.
Next German-language date: