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

> Med composer audit kontrollerer I PHP-afhængigheder for sårbarheder. Kommandoer, integration i CI og deployment og hvorfor PHP selv patches separat.

Kilde: https://phpsos.de/da/ratgeber/composer-abhaengigkeiten-pruefen/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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.

| Niveau | Kontrolleret af composer audit? | Hvordan kontrollerer man i stedet |
|---|---|---|
| Composer-pakker i projektet | ja | composer audit |
| PHP-fortolker (f.eks. PHP2Shell) | nej | Pakkestatus, hosterens bekræftelse |
| PHP-udvidelser fra systemet | nej | Distributionens pakkehåndtering |
| JavaScript-pakker i frontend | nej | Den pågældende pakkehåndterings værktøj |
| Egen applikationskode | nej | Kodegennemgang, sikkerhedsaudit |

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](https://phpsos.de/da/php2shell/php-version-pruefen/).

## 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.

```bash
# 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?

```bash
# 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:

```bash
#!/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.

> **Tip:**
> Fastlæg i `composer.json` under `config.platform.php` den PHP-version, der kører på serveren. Så løser Composer kun pakker, der passer til denne status, og `composer check-platform-reqs` viser afvigelser.

## 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.

```bash
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](https://phpsos.de/da/ratgeber/php-end-of-life-risiken/). Frameworkspecifikke henvisninger finder I under [Sikr Laravel-applikationer](https://phpsos.de/da/plattformen/laravel/).

## 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](https://phpsos.de/da/leistungen/sicherheitsaudit-penetrationstest/).


## Ofte stillede spørgsmål

**Finder composer audit også PHP2Shell?**  
Nej. composer audit kontrollerer pakkerne i jeres projekt, ikke PHP-fortolkeren på serveren. PHP2Shell sidder i selve PHP og udbedres kun ved en opdatering af PHP og en genstart af alle PHP-processer.

**Skal composer.lock ligge i repositoriet?**  
Ved applikationer ja. Lock-filen fastholder, hvilke versioner der præcis er installeret. Kun sådan kontrollerer composer audit den status, der faktisk kører på serveren, og hvert deployment installerer de samme versioner.

**Hvad gør jeg, hvis der ikke findes en opdatering til en berørt pakke?**  
Undersøg, om jeres projekt overhovedet bruger den berørte funktion, og dokumentér vurderingen. Findes der ingen rettelse, kommer en erstatningspakke, en egen patch eller en midlertidig sikring på serverniveau på tale.

**Hvor ofte bør jeg køre composer audit?**  
Ved hvert build og desuden regelmæssigt, f.eks. dagligt, også uden kodeændringer. Nye sårbarheder meldes løbende, og en status, der var ren i går, kan være berørt i dag.

## Kilder

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [php.net: Understøttede versioner](https://www.php.net/supported-versions.php)