composer audit: kontrollera beroenden efter sårbarheter

Kort sagt: composer audit jämför paketen i ert PHP-projekt med kända säkerhetsmeddelanden och visar berörda versioner. Kör kommandot vid varje build och regelbundet mot produktionsnivån. Viktigt efter PHP2Shell: Kontrollen omfattar bibliotek, inte själva PHP-tolken.

Varför beroenden behöver uppmärksamhet just nu

Moderna PHP-applikationer består till största delen av främmande kod. En butik baserad på Symfony eller en portal med Laravel har snabbt flera dussin till hundratals paket, många av dem indirekt via andra paket. Vart och ett av biblioteken kan innehålla en sårbarhet. OWASP Top 10 för därför upp föråldrade och sårbara komponenter som en egen riskkategori.

I oktober 2026 visade PHP2Shell hur snabbt en kritisk sårbarhet får spridning. De två sårbarheterna CVE-2026-109618 och CVE-2026-109619 berör visserligen PHP självt och inte Composer-paket. Många team gick dock under de dagarna igenom hela sin kedja och upptäckte då att de inte kände till läget för sina beroenden exakt.

Den luckan i överblicken går att täppa till med litet arbete. Composer har redan det rätta verktyget med sig i aktuella versioner.

Vad composer audit kontrollerar och vad det inte gör

Kommandot läser de installerade paketen eller lock-filen och frågar efter kända säkerhetsmeddelanden om de paketen. För varje träff visar det paket, berört versionsintervall, allvarlighetsgrad, meddelandets beteckning och en länk till beskrivningen.

Kommandot beaktar även indirekta beroenden, alltså paket som ni aldrig själva begärt men som följer med via andra paket. Just där finns sårbarheter ofta obemärkta, eftersom ingen i teamet känner till de paketen. Nyare Composer-versioner pekar dessutom ut paket som deras upphovspersoner markerat som övergivna. Sådana paket får i regel inga rättningar längre och bör ersättas.

Ett rent resultat betyder alltså bara att det inte finns något känt meddelande för de installerade paketversionerna. Okända sårbarheter och fel i den egna koden hittar verktyget inte. Hur ni kontrollerar PHP-nivån själva beskriver artikeln Kontrollera PHP-version och patchstatus rätt.

Köra composer audit och läsa resultaten

I projektkatalogen räcker ett kommando. Varianterna skiljer sig åt i vad som kontrolleras och hur resultatet visas.

# Kontrollera installerade paket
composer audit

# Kontrollera bara lock-filen, t.ex. i bygget utan installerade paket
composer audit --locked

# Hoppa över utvecklingsberoenden (nivån som på servern)
composer audit --no-dev

# Maskinläsbar utdata för utvärdering eller ärendesystem
composer audit --format=json > audit-$(date +%F).json

Hittar kommandot sårbarheter avslutas det med en felkod. Det är avsiktligt, för då avbryts en automatiserad build. Bedöm varje träff: Används paketet på servern, används den berörda funktionen, finns det en åtgärdad version?

# Vilka direkta beroenden är föråldrade?
composer outdated --direct
# Varför är ett visst paket installerat?
composer why vendor/paket
# Uppdatera riktat, med beroenden
composer update vendor/paket --with-dependencies

Testa varje uppdatering i en stagingmiljö. Säkerhetsuppdateringar inom samma huvudversion är oftast ukritiska, medan en ny huvudversion kan kräva anpassningar i koden.

Automatisera kontrollen

Ett engångsanrop hjälper föga, för nya sårbarheter blir kända fortlöpande. Bygg därför in composer audit på två ställen: i bygg-pipelinen vid varje ändring och i en regelbunden kontroll av produktionsnivån, även när koden inte ändras.

Ett enkelt skript för en daglig körning på bygg- eller kontrollservern kan se ut så här:

#!/bin/sh
# Daglig audit av den levererade nivån (anpassa sökvägen)
cd /srv/build/meine-anwendung || exit 1
if ! composer audit --locked --no-dev --format=plain > /var/log/composer-audit.log 2>&1; then
  logger -t composer-audit "Lücken in meine-anwendung gefunden, siehe /var/log/composer-audit.log"
fi

Skicka meddelandet från systemloggen vidare till er övervakning, er interna brevlåda eller ert ärendesystem. Viktigt är att någon är ansvarig för att bedöma meddelandena. En audit vars varningar ingen läser skyddar inte.

Leverera rent: deployment utan biverkningar

Även vägen till servern påverkar säkerheten. Några grundregler har visat sig fungera:

• Ta in composer.lock i förvaret och kör på servern bara composer install, aldrig composer update.
• Installera med --no-dev så att test- och felsökningsverktyg inte hamnar på produktionsservern.
• Håll mappen vendor/ utanför webbens rotkatalog så att den inte nås direkt via en URL.
• Kör composer validate i bygget för att tidigt upptäcka felaktiga eller motsägelsefulla uppgifter.

composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction

Var också uppmärksam på stödet för själva PHP-versionen. Bibliotek förutsätter allt oftare aktuella PHP-grenar. Den som fortfarande sitter fast på PHP 8.1 eller äldre får inga officiella uppdateringar för PHP självt längre och kan ofta inte installera nyare paketversioner med säkerhetsrättningar. Planeringen för det beskriver guiden PHP End of Life: risker med föråldrade versioner. Ramverksspecifika anvisningar finns under Säkra Laravel-applikationer.

Hur hjälper PHP SOS konkret?

• Vi kartlägger nivån för alla beroenden och bedömer träffar efter faktisk användning.
• Vi sätter upp automatiserade kontroller i bygget och i driften, med tydligt ansvar för fynd.
• Vi planerar och testar uppdateringar, även när nya huvudversioner kräver anpassningar.
• Vi granskar på begäran även egen kod och konfiguration, där inget automatiskt verktyg tittar.

En granskning av tredje part beskriver tjänsten Säkerhetsgranskning och penetrationstest.

Vanliga frågor

Källor

• OWASP Top 10
• OWASP Cheat Sheet Series
• php.net: säkerhetsmeddelanden
• php.net: versioner som stöds