Composer: pakethanteraren för PHP

Kort sagt: Composer är pakethanteraren för PHP. Den läser i filen composer.json vilka bibliotek ett projekt behöver, laddar ned dem i mappen vendor, fastlägger de exakta versionerna i composer.lock och skapar en autoloader som hittar klasser automatiskt. Composer förvaltar alltså er applikations kod, inte själva PHP-tolken: En Composer-uppdatering täpper inte till en sårbarhet i PHP som PHP2Shell.

Vad är Composer och vad behövs det till?

Knappt någon PHP-applikation består i dag bara av egen kod. Ramverk, e-postbibliotek, PDF-generering eller betalningsanslutningar tillkommer som färdiga paket. Composer, pakethanteraren för PHP, ser till att paketen kommer ihop i passande versioner och att varje beroende tar med sina egna beroenden.

För beslutsfattare betyder det: En stor del av koden som körs på er server kommer från tredje part. Det är effektivt men kräver underhåll. För administratörer och utvecklare betyder det: Den som använder Composer rent kan när som helst spåra vilken version av vilket bibliotek som körs i produktionen.

Standardkällan för paket är enligt Composer-dokumentationen Packagist.org. Andra källor, till exempel en byrås interna förråd, kan anges i composer.json under repositories.

composer.json, composer.lock och vendor: de tre byggstenarna

Composer arbetar med tre saker som man bör känna till innan man tar över en server eller anlitar en byrå.

Under require står paket som applikationen behöver i drift. Under require-dev står verktyg för utveckling och tester, till exempel testramverk eller statisk analys. Den här uppdelningen är viktig eftersom utvecklingsverktyg inte hör hemma på en produktionsserver.

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

Versionsuppgifterna i exemplet är valda bara för att illustrera. Vilka versioner ert projekt behöver framgår av dess krav.

install eller update: skillnaden i drift

De båda kommandona låter lika men får mycket olika följder.

• composer install läser composer.lock och installerar exakt de versioner som är fastlagda där. Det är reproducerbart och hör hemma i leveransen.
• composer update löser alla beroenden på nytt, hämtar de nyaste passande versionerna och skriver om composer.lock. Det hör hemma i utvecklingen, med efterföljande tester.

Enligt Composer-dokumentationen kör update efter att lock-filen skrivits dessutom en säkerhetskontroll (audit), om den inte stängs av med --no-audit. install kontrollerar inte som standard; för det finns alternativet --audit.

Autoloading: så hittar Composer klasser

Composer skapar filen vendor/autoload.php. När den väl har inkluderats laddar PHP varje klass först när den behövs. För egen kod anges i avsnittet autoload vilken namnrymd som ligger i vilken mapp. Rekommenderat är PSR-4, en standard från PHP-FIG. Hur det fungerar förklaras på sidan Namnrymder och autoloading; en översikt över alla standarder ger sidan PSR-standarder.

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

$log = new Monolog\Logger('app');   // laddas automatiskt vid behov

Composer i produktion: leverera rent

För leveransen har en fast ordningsföljd visat sig fungera. Den körs bäst i en build-pipeline och inte för hand på servern.

1. Kontrollera lock-filen: composer validate säkerställer att composer.json är giltig och composer.lock aktuell.
2. Installera utan utvecklingspaket: composer install --no-dev utelämnar require-dev.
3. Optimera autoloadern: --optimize-autoloader (förkortat -o) omvandlar reglerna till en klasslista. Med --classmap-authoritative laddar PHP klasser uteslutande från den listan.
4. Säkerhetskontroll: composer audit --locked kontrollerar versionerna i lock-filen mot kända säkerhetsmeddelanden och rapporterar övergivna paket.
5. vendor utanför webbroten: Bara den publika mappen med startskriptet bör vara nåbar via URL.

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

composer outdated visar dessutom vilka installerade paket som har nyare versioner. Det är grunden för planerade uppdateringar i stället för hektiska enskilda insatser.

Composer, säkerhet och PHP2Shell

Composer och PHP2Shell berör två olika nivåer. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 ligger i själva PHP-tolken. De är åtgärdade i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35, och alla PHP-processer måste därefter startas om. Ingen composer update och inget paket i vendor ändrar något i det.

Ändå hör Composer hemma i varje granskning efter en incident. Den som för in skadlig kod på en server kan också ändra filer i vendor, och vendor/autoload.php laddas vid varje förfrågan. En ny composer install från den kontrollerade lock-filen till en tom katalog är därför en bra metod för att återställa paketbeståndet. Hur ni regelbundet kontrollerar beroenden mot kända sårbarheter beskrivs i guiden composer audit.

Hur hjälper PHP SOS konkret?

• Vi tar fram PHP-version, Composer-paket och lock-läge för varje applikation och skiljer därvid rent mellan tolk och bibliotek.
• Vi kontrollerar att vendor och lock-filen stämmer överens och om utvecklingspaket eller ändrade filer ligger i produktionen.
• Vi inrättar en reproducerbar leverans med install --no-dev, optimerad autoloader och audit.
• Efter en incident återskapar vi paketbeståndet från den kontrollerade lock-filen och dokumenterar resultatet.

Vanliga frågor

Källor

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