Composer: het pakketbeheer voor PHP

Kort gezegd: Composer is het pakketbeheer voor PHP. Het leest uit het bestand composer.json welke bibliotheken een project nodig heeft, laadt ze in de map vendor, legt de exacte versies vast in de composer.lock en maakt een autoloader die klassen automatisch vindt. Composer beheert daarmee de code van uw toepassing, niet de PHP-interpreter zelf: een Composer-update sluit geen lek in PHP zoals PHP2Shell.

Wat is Composer en waarvoor heeft men het nodig?

Nauwelijks een PHP-toepassing bestaat tegenwoordig nog alleen uit eigen code. Frameworks, mailbibliotheken, pdf-generatie of betaalkoppelingen komen als kant-en-klare pakketten erbij. Composer, het pakketbeheer voor PHP, zorgt ervoor dat deze pakketten in passende versies samenkomen en dat elke afhankelijkheid zijn eigen afhankelijkheden meebrengt.

Voor beslissers betekent dit: een groot deel van de code die op uw server draait, komt van derden. Dat is efficiënt, maar vraagt onderhoud. Voor beheerders en ontwikkelaars betekent het: wie Composer netjes inzet, kan op elk moment nagaan welke versie van welke bibliotheek in productie draait.

Standaardbron voor pakketten is volgens de Composer-documentatie Packagist.org. Andere bronnen, bijvoorbeeld interne repositories van een bureau, kunnen in de composer.json onder repositories worden opgenomen.

composer.json, composer.lock en vendor: de drie bouwstenen

Composer werkt met drie dingen die men moet kennen voordat men een server overneemt of een bureau opdracht geeft.

Onder require staan pakketten die de toepassing in bedrijf nodig heeft. Onder require-dev staan hulpmiddelen voor ontwikkeling en tests, bijvoorbeeld testframeworks of statische analyse. Deze scheiding is belangrijk, omdat ontwikkelhulpmiddelen op een productieserver niets te zoeken hebben.

{
    "require": {
        "php": ">=8.3",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}

De versieaanduidingen in het voorbeeld zijn alleen ter illustratie gekozen. Welke versies uw project nodig heeft, volgt uit zijn eisen.

install of update: het verschil in bedrijf

De twee opdrachten klinken vergelijkbaar, maar hebben zeer verschillende gevolgen.

• composer install leest de composer.lock en installeert precies de daarin vastgelegde versies. Dat is reproduceerbaar en hoort bij de uitlevering.
• composer update lost alle afhankelijkheden opnieuw op, haalt de nieuwste passende versies op en schrijft de composer.lock opnieuw. Dat hoort bij de ontwikkeling, met aansluitend tests.

Volgens de Composer-documentatie voert update na het schrijven van het lockbestand bovendien een beveiligingscontrole (audit) uit, tenzij die met --no-audit wordt uitgeschakeld. install controleert standaard niet; daarvoor is de optie --audit.

Autoloading: hoe Composer klassen vindt

Composer maakt het bestand vendor/autoload.php. Wordt het eenmaal ingebonden, dan laadt PHP elke klasse pas wanneer die nodig is. Voor eigen code wordt in de sectie autoload vastgelegd welke namespace in welke map staat. Aanbevolen is daarvoor PSR-4, een standaard van de PHP-FIG. Hoe dat precies werkt, legt de pagina Namespaces en autoloading uit; een overzicht van alle standaarden geeft de pagina PSR-standaarden.

<?php
require __DIR__ . '/../vendor/autoload.php';

$log = new Monolog\Logger('app');   // wordt bij behoefte automatisch geladen

Composer in productie: netjes uitleveren

Voor de uitlevering heeft een vaste volgorde zich bewezen. Ze loopt het best in een buildpipeline en niet met de hand op de server.

1. Lockbestand controleren: composer validate stelt vast dat composer.json geldig en de composer.lock actueel is.
2. Zonder ontwikkelpakketten installeren: composer install --no-dev laat require-dev weg.
3. Autoloader optimaliseren: --optimize-autoloader (kort -o) zet de regels om in een klassenlijst. Met --classmap-authoritative laadt PHP klassen uitsluitend uit deze lijst.
4. Beveiligingscontrole: composer audit --locked toetst de versies uit het lockbestand aan bekende beveiligingsmeldingen en meldt verlaten pakketten.
5. vendor buiten de webroot: Alleen de openbare map met het instapscript mag via URL bereikbaar zijn.

composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev

composer outdated toont bovendien welke geïnstalleerde pakketten nieuwere versies hebben. Dat is de basis voor geplande updates in plaats van hectische losse acties.

Composer, beveiliging en PHP2Shell

Composer en PHP2Shell raken twee verschillende niveaus. De lekken CVE-2026-109618 en CVE-2026-109619 zitten in de PHP-interpreter zelf. Verholpen zijn ze in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, en alle PHP-processen moeten daarna opnieuw worden gestart. Geen enkele composer update en geen enkel pakket in vendor verandert daar iets aan.

Toch hoort Composer bij elke controle na een incident. Wie schadelijke code op een server brengt, kan ook bestanden in vendor wijzigen, en vendor/autoload.php wordt bij elk verzoek geladen. Een verse composer install uit het gecontroleerde lockbestand in een lege map is daarom een goede methode om het pakketbestand te herstellen. Hoe u afhankelijkheden regelmatig op bekende lekken controleert, beschrijft de gids composer audit.

Hoe helpt PHP SOS concreet?

• Wij leggen voor elke toepassing PHP-versie, Composer-pakketten en lockstand vast en scheiden daarbij zuiver tussen interpreter en bibliotheken.
• Wij controleren of vendor en lockbestand bij elkaar passen en of ontwikkelpakketten of gewijzigde bestanden in productie staan.
• Wij richten een reproduceerbare uitlevering in met install --no-dev, geoptimaliseerde autoloader en audit.
• Na een incident herstellen wij het pakketbestand uit het gecontroleerde lockbestand en documenteren het resultaat.

Veelgestelde vragen

Bronnen

• Composer: Basic usage
• Composer: Command-line interface
• Composer: The composer.json schema