composer audit: kontrollér afhængigheder for sårbarheder

Kort sagt: composer audit sammenholder pakkerne i jeres PHP-projekt med kendte sikkerhedsmeddelelser og viser berørte versioner. Kør kommandoen ved hvert build og regelmæssigt på produktionsstatus. Vigtigt efter PHP2Shell: Kontrollen omfatter biblioteker, ikke selve PHP-fortolkeren.

Hvorfor afhængigheder har brug for opmærksomhed netop nu

Moderne PHP-applikationer består for det meste af fremmed kode. En shop på basis af Symfony eller en portal med Laravel medbringer hurtigt flere dusin til hundredvis af pakker, mange af dem indirekte via andre pakker. Hvert af disse biblioteker kan indeholde en sårbarhed. OWASP Top 10 fører derfor forældede og sårbare komponenter som en egen risikokategori.

I oktober 2026 viste PHP2Shell, hvor hurtigt en kritisk sårbarhed breder sig. De to sårbarheder CVE-2026-109618 og CVE-2026-109619 berører rigtignok PHP selv og ikke Composer-pakker. Mange teams gennemgik dog i de dage hele deres kæde og opdagede, at de slet ikke kender status for deres afhængigheder præcist.

Dette hul i overblikket kan lukkes med lidt arbejde. Composer har det passende værktøj allerede med i aktuelle versioner.

Hvad composer audit kontrollerer, og hvad ikke

Kommandoen læser de installerede pakker eller lock-filen og slår kendte sikkerhedsmeddelelser op for disse pakker. For hvert fund viser den pakke, berørt versionsområde, alvorlighed, meddelelsens betegnelse og et link til beskrivelsen.

Kommandoen tager også hensyn til indirekte afhængigheder, altså pakker, som I aldrig selv har anmodet om, men som følger med via andre pakker. Netop dér ligger sårbarheder ofte ubemærket, fordi ingen i teamet kender disse pakker. Nyere Composer-versioner gør desuden opmærksom på pakker, som deres forfattere har markeret som opgivet. Sådanne pakker får som regel ikke længere rettelser og bør erstattes.

Et rent resultat betyder altså kun, at der for de installerede pakkeversioner ikke foreligger en kendt meddelelse. Ukendte sårbarheder og fejl i egen kode finder værktøjet ikke. Hvordan I selv kontrollerer PHP-status, beskriver indlægget Kontrollér PHP-version og patchstatus korrekt.

Kør composer audit og læs resultaterne

I projektmappen er én kommando nok. Varianterne adskiller sig i, hvad der kontrolleres, og hvordan resultatet udskrives.

# Kontrollér installerede pakker
composer audit

# Kontrollér kun lock-filen, f.eks. i buildet uden installerede pakker
composer audit --locked

# Udelad udviklingsafhængigheder (status som på serveren)
composer audit --no-dev

# Maskinlæsbart output til evaluering eller ticketsystem
composer audit --format=json > audit-$(date +%F).json

Finder kommandoen sårbarheder, slutter den med en fejlkode. Det er tilsigtet, for så afbrydes et automatiseret build. Vurdér hvert fund: Bruges pakken på serveren, anvendes den berørte funktion, findes der en rettet version?

# Hvilke direkte afhængigheder er forældede?
composer outdated --direct
# Hvorfor er en bestemt pakke installeret?
composer why vendor/paket
# Opdatér målrettet, med afhængigheder
composer update vendor/paket --with-dependencies

Test hver opdatering i et staging-miljø. Sikkerhedsopdateringer inden for samme hovedversion er som regel uproblematiske, en ny hovedversion kan derimod kræve tilpasninger i koden.

Automatisér kontrollen

Et enkeltstående kald hjælper kun lidt, for nye sårbarheder bliver løbende kendt. Integrér derfor composer audit to steder: i build-pipelinen ved hver ændring og i en regelmæssig kontrol af produktionsstatus, også når koden ikke ændres.

Et enkelt script til en daglig kørsel på build- eller kontrolserveren kan se sådan ud:

#!/bin/sh
# Daglig audit af den leverede status (tilpas stien)
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

Led meddelelsen fra systemloggen videre til jeres overvågning, jeres interne postkasse eller jeres ticketsystem. Vigtigt er, at nogen er ansvarlig for at vurdere meddelelser. En audit, hvis advarsler ingen læser, beskytter ikke.

Lever rent: deployment uden bivirkninger

Også vejen til serveren påvirker sikkerheden. Nogle grundregler har vist sit værd:

• Tag composer.lock med i repositoriet, og kør på serveren kun composer install, aldrig composer update.
• Installér med --no-dev, så test- og fejlsøgningsværktøjer ikke havner på produktionsserveren.
• Hold mappen vendor/ uden for web-rodmappen, så den ikke kan nås direkte via en URL.
• Kør composer validate i buildet for tidligt at opdage fejlbehæftede eller modstridende oplysninger.

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

Vær desuden opmærksom på understøttelsen af selve PHP-versionen. Biblioteker forudsætter i stigende grad aktuelle PHP-grene. Den, der stadig hænger fast på PHP 8.1 eller ældre, får ikke længere officielle opdateringer til PHP selv og kan ofte ikke længere installere nyere pakkeversioner med sikkerhedsrettelser. Planlægningen beskriver vejledningen PHP end-of-life: risici ved forældede versioner. Frameworkspecifikke henvisninger finder I under Sikr Laravel-applikationer.

Hvordan hjælper PHP SOS konkret?

• Vi kortlægger status for alle afhængigheder og vurderer fund efter faktisk brug.
• Vi opsætter automatiserede kontroller i build og drift, med klart ansvar for resultater.
• Vi planlægger og tester opdateringer, også når nye hovedversioner kræver tilpasninger.
• Vi gennemgår efter ønske også egen kode og konfiguration, hvor intet automatisk værktøj kigger.

En kontrol foretaget af tredjepart beskriver ydelsen Sikkerhedsaudit og penetrationstest.

Ofte stillede spørgsmål

Kilder

• OWASP Top 10
• OWASP Cheat Sheet Series
• php.net: Sikkerhedsmeddelelser
• php.net: Understøttede versioner