Kort gezegd: composer audit vergelijkt de pakketten van uw PHP-project met bekende beveiligingsmeldingen en toont getroffen versies. Voer de opdracht bij elke build uit en regelmatig op de productiestand. Belangrijk na PHP2Shell: de controle omvat bibliotheken, niet de PHP-interpreter zelf.
Waarom afhankelijkheden juist nu aandacht nodig hebben
Moderne PHP-toepassingen bestaan voor het grootste deel uit code van anderen. Een webshop op basis van Symfony of een portaal met Laravel brengt snel enkele tientallen tot honderden pakketten mee, veel daarvan indirect via andere pakketten. Elke bibliotheek kan een kwetsbaarheid bevatten. De OWASP Top 10 voeren verouderde en kwetsbare componenten daarom als eigen risicocategorie.
In oktober 2026 liet PHP2Shell zien hoe snel een kritieke kwetsbaarheid zich verspreidt. De twee kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 betreffen weliswaar PHP zelf en niet Composer-pakketten. Veel teams hebben in die dagen echter hun hele keten gecontroleerd en daarbij ontdekt dat ze de stand van hun afhankelijkheden helemaal niet precies kennen.
Dit gat in het overzicht is met weinig moeite te dichten. Composer levert in actuele versies al het passende hulpmiddel mee.
Wat composer audit controleert en wat niet
De opdracht leest de geïnstalleerde pakketten of het lockbestand en vraagt bekende beveiligingsmeldingen over die pakketten op. Bij elke treffer toont ze pakket, getroffen versiebereik, ernst, kenmerk van de melding en een link naar de beschrijving.
| Laag | Gecontroleerd door composer audit? | Hoe anders controleren |
|---|---|---|
| Composer-pakketten in het project | ja | composer audit |
| PHP-interpreter (bijv. PHP2Shell) | nee | Pakketstand, bevestiging van de hoster |
| PHP-extensies uit het systeem | nee | Pakketbeheer van de distributie |
| JavaScript-pakketten in de frontend | nee | Hulpmiddel van de betreffende pakketbeheerder |
| Eigen toepassingscode | nee | Code review, beveiligingsaudit |
De opdracht houdt ook rekening met indirecte afhankelijkheden, dus pakketten die u nooit zelf hebt opgevraagd maar die via andere pakketten meekomen. Juist daar zitten kwetsbaarheden vaak onopgemerkt, omdat niemand in het team die pakketten kent. Nieuwere Composer-versies wijzen bovendien op pakketten die door hun auteurs als verlaten zijn gemarkeerd. Zulke pakketten krijgen in de regel geen correcties meer en moeten worden vervangen.
Een schoon resultaat betekent dus alleen dat er voor de geïnstalleerde pakketversies geen bekende melding bestaat. Onbekende kwetsbaarheden en fouten in de eigen code vindt het hulpmiddel niet. Hoe u de PHP-stand zelf controleert, beschrijft het artikel PHP-versie en patchstand goed controleren.
composer audit uitvoeren en resultaten lezen
In de projectmap volstaat één opdracht. De varianten verschillen in wat er wordt gecontroleerd en hoe het resultaat wordt weergegeven.
# Geïnstalleerde pakketten controleren
composer audit
# Alleen het lockbestand controleren, bijv. in de build zonder geïnstalleerde pakketten
composer audit --locked
# Ontwikkelafhankelijkheden weglaten (stand zoals op de server)
composer audit --no-dev
# Machineleesbare uitvoer voor analyse of ticketsysteem
composer audit --format=json > audit-$(date +%F).json
Vindt de opdracht kwetsbaarheden, dan eindigt ze met een foutcode. Dat is de bedoeling, want zo breekt een geautomatiseerde build af. Beoordeel elke treffer: is het pakket op de server in gebruik, wordt de getroffen functie gebruikt, bestaat er een verholpen versie?
# Welke directe afhankelijkheden zijn verouderd?
composer outdated --direct
# Waarom is een bepaald pakket geïnstalleerd?
composer why vendor/paket
# Gericht bijwerken, met afhankelijkheden
composer update vendor/paket --with-dependencies
Test elke update in een stagingomgeving. Beveiligingsupdates binnen dezelfde hoofdversie zijn meestal onkritisch; een nieuwe hoofdversie kan daarentegen aanpassingen aan de code vereisen.
De controle automatiseren
Een eenmalige aanroep helpt weinig, want nieuwe kwetsbaarheden worden voortdurend bekend. Neem composer audit daarom op twee plekken op: in de buildpipeline bij elke wijziging en in een regelmatige controle van de productiestand, ook als er aan de code niets verandert.
Een eenvoudig script voor een dagelijkse run op de build- of controleserver kan er zo uitzien:
#!/bin/sh
# Dagelijkse audit van de uitgeleverde stand (pad aanpassen)
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
Stuur de melding uit het systeemlogboek door naar uw monitoring, uw interne mailbox of uw ticketsysteem. Belangrijk is dat iemand verantwoordelijk is om meldingen te beoordelen. Een audit waarvan niemand de waarschuwingen leest, beschermt niet.
Leg in composer.json onder config.platform.php de PHP-versie vast die op de server draait. Dan lost Composer alleen pakketten op die bij die stand passen, en composer check-platform-reqs toont afwijkingen.
Netjes uitleveren: deployment zonder bijwerkingen
Ook de route naar de server beïnvloedt de veiligheid. Enkele basisregels hebben zich bewezen:
composer.lockin de repository opnemen en op de server alleencomposer installuitvoeren, nooitcomposer update.- Met
--no-devinstalleren, zodat test- en debughulpmiddelen niet op de productieserver terechtkomen. - De map
vendor/buiten de webroot houden, zodat ze niet rechtstreeks via een URL bereikbaar is. composer validatein de build uitvoeren om foutieve of tegenstrijdige gegevens vroeg te herkennen.
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
Let bovendien op de ondersteuning van de PHP-versie zelf. Bibliotheken vereisen steeds vaker actuele PHP-takken. Wie nog op PHP 8.1 of ouder vastzit, krijgt voor PHP zelf geen officiële updates meer en kan nieuwere pakketversies met beveiligingscorrecties vaak niet meer installeren. De planning daarvoor beschrijft de gids PHP end-of-life: risico's van verouderde versies. Frameworkspecifieke aanwijzingen vindt u onder Laravel-toepassingen beveiligen.
Hoe helpt PHP SOS concreet?
- We inventariseren de stand van alle afhankelijkheden en beoordelen treffers naar daadwerkelijk gebruik.
- We richten geautomatiseerde controles in bij build en bedrijf, met duidelijke verantwoordelijkheid voor bevindingen.
- We plannen en testen updates, ook als nieuwe hoofdversies aanpassingen vereisen.
- Op verzoek controleren we ook eigen code en configuratie, waar geen automatisch hulpmiddel naar kijkt.
Een controle door derden beschrijft de dienst Beveiligingsaudit en penetratietest.
Veelgestelde vragen
Vindt composer audit ook PHP2Shell?
Nee. composer audit controleert de pakketten in uw project, niet de PHP-interpreter op de server. PHP2Shell zit in PHP zelf en wordt alleen verholpen door een update van PHP en een herstart van alle PHP-processen.
Moet composer.lock in de repository?
Bij toepassingen wel. Het lockbestand legt vast welke versies precies zijn geïnstalleerd. Alleen zo controleert composer audit de stand die werkelijk op de server draait, en installeert elke deployment dezelfde versies.
Wat als er voor een getroffen pakket geen update bestaat?
Controleer of uw project de getroffen functie wel gebruikt en documenteer de beoordeling. Is er geen fix, dan komen een vervangend pakket, een eigen patch of een tijdelijke beveiliging op serverniveau in aanmerking.
Hoe vaak moet ik composer audit uitvoeren?
Bij elke build en daarnaast regelmatig, bijvoorbeeld dagelijks, ook zonder codewijziging. Nieuwe kwetsbaarheden worden voortdurend gemeld en een stand die gisteren schoon was, kan vandaag getroffen zijn.