Composer: pakkestyringen til PHP

Kort sagt: Composer er pakkestyringen til PHP. Den læser i filen composer.json, hvilke biblioteker et projekt har brug for, henter dem ind i mappen vendor, fastholder de nøjagtige versioner i composer.lock og genererer en autoloader, der finder klasser automatisk. Composer administrerer dermed jeres applikations kode, ikke selve PHP-fortolkeren: En Composer-opdatering lukker ingen sårbarhed i PHP som PHP2Shell.

Hvad er Composer, og hvad bruger man det til?

Næppe nogen PHP-applikation består i dag kun af egen kode. Frameworks, mail-biblioteker, PDF-generering eller betalingsintegrationer kommer til som færdige pakker. Composer, pakkestyringen til PHP, sørger for, at disse pakker kommer sammen i passende versioner, og at hver afhængighed medbringer sine egne afhængigheder.

For beslutningstagere betyder det: En stor del af den kode, der kører på jeres server, stammer fra tredjepart. Det er effektivt, men kræver vedligeholdelse. For administratorer og udviklere betyder det: Den, der bruger Composer rent, kan til enhver tid spore, hvilken version af hvilket bibliotek der kører i produktion.

Standardkilden til pakker er ifølge Composer-dokumentationen Packagist.org. Yderligere kilder, f.eks. et bureaus interne repositories, kan indføres i composer.json under repositories.

composer.json, composer.lock og vendor: de tre byggesten

Composer arbejder med tre ting, som man bør kende, før man overtager en server eller beder et bureau om en opgave.

Under require står pakker, som applikationen har brug for i drift. Under require-dev står værktøjer til udvikling og test, f.eks. testframeworks eller statisk analyse. Denne adskillelse er vigtig, fordi udviklingsværktøjer intet har at gøre på en produktionsserver.

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

Versionsangivelserne i eksemplet er kun valgt til illustration. Hvilke versioner jeres projekt har brug for, fremgår af dets krav.

install eller update: forskellen i drift

De to kommandoer lyder ens, men har meget forskellige følger.

• composer install læser composer.lock og installerer præcis de dér fastholdte versioner. Det er reproducerbart og hører hjemme i leverancen.
• composer update løser alle afhængigheder på ny, henter de nyeste passende versioner og skriver composer.lock om. Det hører hjemme i udviklingen, med efterfølgende tests.

Ifølge Composer-dokumentationen udfører update efter skrivningen af lock-filen desuden en sikkerhedskontrol (audit), medmindre den slås fra med --no-audit. install kontrollerer ikke som standard; til det findes indstillingen --audit.

Autoloading: hvordan Composer finder klasser

Composer genererer filen vendor/autoload.php. Bliver den inkluderet én gang, indlæser PHP hver klasse først, når den bruges. For egen kode fastlægges i afsnittet autoload, hvilket namespace der ligger i hvilken mappe. Anbefalet er hertil PSR-4, en standard fra PHP-FIG. Hvordan det præcist fungerer, forklarer siden Namespaces og autoloading; et overblik over alle standarder giver siden PSR-standarder.

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

$log = new Monolog\Logger('app');   // indlæses automatisk ved behov

Composer i produktion: lever rent

Til leveringen har en fast rækkefølge vist sig at fungere. Den kører bedst i en build-pipeline og ikke i hånden på serveren.

1. Kontrollere lock-filen: composer validate sikrer, at composer.json er gyldig, og at composer.lock er aktuel.
2. Installere uden udviklingspakker: composer install --no-dev udelader require-dev.
3. Optimere autoloaderen: --optimize-autoloader (kort -o) omdanner reglerne til en klasseliste. Med --classmap-authoritative indlæser PHP udelukkende klasser fra denne liste.
4. Sikkerhedskontrol: composer audit --locked kontrollerer versionerne fra lock-filen mod kendte sikkerhedsmeddelelser og melder opgivne pakker.
5. vendor uden for webroot: Kun den offentlige mappe med indgangsscriptet bør kunne nås via URL.

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

composer outdated viser desuden, hvilke installerede pakker der har nyere versioner. Det er grundlaget for planlagte opdateringer i stedet for hektiske enkeltaktioner.

Composer, sikkerhed og PHP2Shell

Composer og PHP2Shell angår to forskellige niveauer. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 ligger i selve PHP-fortolkeren. De er rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35, og alle PHP-processer skal derefter genstartes. Ingen composer update og ingen pakke i vendor ændrer noget herved.

Alligevel hører Composer med i enhver undersøgelse efter en hændelse. Den, der bringer skadelig kode på en server, kan også ændre filer i vendor, og vendor/autoload.php indlæses ved hver forespørgsel. En ny composer install fra den kontrollerede lock-fil i en tom mappe er derfor en god metode til at genskabe pakkebeholdningen. Hvordan I regelmæssigt kontrollerer afhængigheder for kendte sårbarheder, beskriver guiden composer audit.

Hvordan hjælper PHP SOS konkret?

• Vi registrerer for hver applikation PHP-version, Composer-pakker og lock-status og skelner herved rent mellem fortolker og biblioteker.
• Vi kontrollerer, om vendor og lock-filen passer til hinanden, og om udviklingspakker eller ændrede filer ligger i produktion.
• Vi indfører en reproducerbar levering med install --no-dev, optimeret autoloader og audit.
• Efter en hændelse genskaber vi pakkebeholdningen fra den kontrollerede lock-fil og dokumenterer resultatet.

Ofte stillede spørgsmål

Kilder

• Composer: Grundlæggende brug
• Composer: Kommandolinjegrænsefladen
• Composer: Skemaet for composer.json