Van NCSC CSAF-feed naar een onderbouwd patchticket

Je ziet “PHP” in een NCSC-advies. Je assetregister noemt php-fpm, distributiepakketten of containerimages. Een productnaam alleen kan verkeerde servers naar de patchwachtrij sturen; een onbekende versie kan een getroffen systeem verbergen.

Op 11 november 2026 om 09:12 CET publiceerde het NCSC een Security Advisory voor N-able N-central met als opgeloste versie 2026.4.1.26. De bestaande gegevensstroom is dus actief. De aangekondigde NCSC-netwerkscan blijft een verkenning zonder vastgelegde doelgroep, scope of startdatum; je patchproces kan beginnen op basis van data die je vandaag al kunt ophalen.

Een CSAF-koppeling vertaalt een NCSC-kwetsbaarheidsrecord naar een gecontroleerde assetmatch en herstelactie. Je haalt het CVE-bestand op, bewaart de revisie en vergelijkt leverancier, product en pakketversie met één asset voordat je een ticket maakt. Een onbekende versie, afwijkende productnaam of tegenstrijdige status gaat naar een beheerder.

De NCSC-kwetsbaarhedenservice biedt brede CVE-data als CSAF 2.0, adviseert die als basis te gebruiken en overschrijft oudere bestanden. Het afzonderlijke kanaal Security Advisories bevat een selectie van hoogrisicozaken. Verwerk je beide, koppel op CVE en houd de herkomst apart om dubbele tickets te voorkomen. De Security Advisories zijn publiek beschikbaar via RSS en CSAF; de aanvullende API is bedoeld voor NIS2-organisaties en de Rijksoverheid.

Wat je nodig hebt

Je verbindt de NCSC-bron, inventaris en ticketwachtrij. De inventaris levert leverancier, versie en installatie; de wachtrij registreert eigenaar, test en uitkomst.

• De juiste NCSC-bron. Voor alle CVE-data gebruik je de publieke CSAF-directory van vulnerabilities.ncsc.nl; de provider-metadata bevat de actuele directoryverwijzing. Daar staan onder meer index.txt, changes.csv, one-day-changes.csv en priority-changes.csv. Het kanaal Security Advisories heeft een eigen RSS-feed. Kies welke stroom leidend is. Voor een brede bewakingsroute begin je bij de CVE-data, voor een beperkte spoedwachtrij kun je met de geselecteerde advisories starten.

• Een assetregister met herleidbare versies. Bewaar per installatie een vast asset_id, leverancier, productfamilie, productnaam, editie, volledige versie of pakketbuild, distributie of installatiebron, omgeving, laatste inventarisdatum en eigenaar. Neem ook op of het systeem webverzoeken verwerkt, vanaf internet bereikbaar is en welke dienst ervan afhankelijk is. Een rij met alleen “PHP” of “Linux-server” is geen bruikbare match.

• Een bestaande patchwachtrij. Gebruik het ticketsysteem dat je team al beheert, bijvoorbeeld Jira Service Management, Freshservice of ServiceNow. De koppeling moet een ticket kunnen maken én daarna teruglezen. Je hebt een testproject of acceptatiequeue nodig, plus een API-gebruiker met alleen de rechten voor de benodigde projecten en velden.

• Een eigenaar voor elk soort besluit. Wijs een beheerder aan voor de bronimport, een applicatie- of systeemeigenaar voor de asset, een securityverantwoordelijke voor uitzonderingen en iemand die het onderhoudsvenster goedkeurt. Een record zonder eigenaar blijft een open actie. Het wordt geen ticket zonder verantwoordelijke.

• Een versie van de bron en een proefset. Bewaar de ongewijzigde CSAF-invoer, het moment waarop je die ophaalde en de revisie. Leg ook minstens 30 gelabelde combinaties klaar van CVE, product, editie en versie. Neem bekende getroffen versies, bekende opgeloste versies, een distributiepakket met backport en onbekende productnamen op. Je hebt hiermee een meetpunt vóórdat de koppeling tickets mag aanmaken.

• Een testafspraak voor productie. Spreek per applicatie af wat een geslaagde update is: teruggelezen pakketversie, gezondheidstest, functionele controle en terugvalplan. Plan een eigenaar en venster voordat je een patchticket verstuurt. Een advisoriescore maakt die keuzes niet voor jouw bedrijf.

Concrete stappen: van wijzigingsbestand naar gecontroleerd patchticket

1. Ontdek wijzigingen via de NCSC-directory

Haal eenmalig https://vulnerabilities.ncsc.nl/.well-known/csaf/provider-metadata.json op en bewaar de waarde van distributions[].directory_url. Op 11 november 2026 wijst die naar https://vulnerabilities.ncsc.nl/csaf/v2/. De directory toont de volledige lijst index.txt en aparte wijzigingsbestanden voor de laatste dag, zeven dagen en hogere prioriteit. Het NCSC vermeldt CSAF 2.0, een grens van 2.000 verzoeken per minuut en dat gegevens in korte tijd vaak kunnen veranderen.

Voor de brede stroom poll je one-day-changes.csv elke 30 minuten; gebruik priority-changes.csv als extra onderzoekssignaal. Koppel CSV-velden op hun koptekst, niet op positie. Haal index.txt elke nacht op als volledige vergelijking. Dit is je doelinterval, geen NCSC-publicatiegarantie. Log tijdstip, HTTP-status, aantal regels en indexhash. Alarm na twee mislukte intervallen. Een lege import bewijst niet dat er geen wijzigingen zijn.

Klaar als je import het directorybestand kan ophalen, de actuele directory_url volgt en een mislukte run zichtbaar maakt. De provider-metadata van NCSC wijst naar de CSAF-directory en noemt de publieke sleutels van de aanbieder. De directory zelf toont op 11 november de index- en wijzigingsbestanden. Volg de huidige verwijzing uit metadata; zet geen veronderstelde bestandsroute vast in je code.

2. Bewaar elke revisie voordat je de vorige vervangt

De NCSC-service overschrijft oudere CSAF-bestanden zodra een nieuwe versie verschijnt. Archiveer elk opgehaald document onder bron, jaar, CVE, releasedatum en hash. Bewaar document.tracking.id, current_release_date, revision_history, csaf_version en de generatorversie.

Overschrijf de actieve werkstatus, niet je archief. Bewaar leverancierstekst en beslisuitkomst naast de bronversie, zodat je later kunt aantonen welk bewijs de ticketbeslissing droeg. Op de peildatum gebruikt de service CSAF 2.0 en generator 1.7; log de generatormetadata, maar laat de parser niet stoppen bij een latere versie.

De NCSC-registratie van CVE-2026-109618 kreeg op 11 november om 07:20 CET een nieuwe current_release_date; het trackingblok toont die revisie. Bewaar de gebruikte bronstand naast de ticketdatum.

Klaar als je een herhaalde import van hetzelfde document zonder dubbele wijziging kunt uitvoeren, maar een nieuwe revisie als nieuwe bronstand opslaat. Test ook dat je bij een mislukte download de oude status als oud markeert, in plaats van hem als actueel te presenteren.

3. Lees CSAF-velden en bronstatussen apart

Valideer eerst document.csaf_version, document.category en document.tracking.id. De brede NCSC-stroom bevat meestal csaf_base-bestanden, één per CVE. Een Security Advisory is een ander documenttype, csaf_security_advisory, dat meer kwetsbaarheden en de samenvatting van het NCSC kan bundelen. De parser kan beide lezen, maar moet het brontype bewaren.

Voor de productmatch lees je product_tree en de statusvelden van iedere kwetsbaarheid, waaronder known_affected, known_not_affected, fixed, first_affected en first_fixed. In CSAF beschrijft een product_id een product binnen het huidige document. De waarde is niet vanzelf een blijvende sleutel tussen verschillende CVE-bestanden. De OASIS-specificatie behandelt product-ID’s als verwijzingen binnen het document en kent afzonderlijke velden toe aan productversies en versiegebieden. Gebruik dus een eigen product- en versiekaart.

Het NCSC zet EPSS, CVSS 4.0, de NCSC-score en leveranciersbeoordelingen soms in notes. Lees categorie en titel en bewaar de ruwe tekst. Een score kan in notes staan en ontbreken in vulnerabilities[].scores.

Bewaar ook de oorspronkelijke bronreferentie naast de genormaliseerde waarde. De NCSC-normalisatie kan uiteenlopende invoer omzetten naar één productstatus. Wanneer bronnen elkaar tegenspreken, geeft de NCSC KNOWN_AFFECTED voorrang boven andere statussen; bij een conflict tussen FIXED en KNOWN_NOT_AFFECTED krijgt FIXED voorrang. Die regel voorkomt dat een mogelijke treffer stil verdwijnt. Ze bewijst nog niet welke versie op jouw server draait.

Klaar als je voor één CVE de originele referentie, ruwe status, genormaliseerde NCSC-status en parseruitkomst naast elkaar kunt tonen. Als je parser twee bronuitspraken tot één onherleidbare booleaanse waarde samenvoegt, is hij nog niet klaar voor ticketaanmaak.

4. Maak het assetregister matchbaar

Maak een canonieke kaart voor productnamen in je inventaris. Koppel bijvoorbeeld PHP-FPM, php8.3-fpm en een containerimage met PHP-runtime aan dezelfde productfamilie. Bewaar de oorspronkelijke naam als bewijs. Leg distributie, editie, versiebeheerwijze en pakketbron vast. PHP 8.3.35 uit upstream is niet automatisch gelijk aan een Linux-distributiepakket dat een beveiligingsfix heeft teruggeplaatst zonder hetzelfde upstream-versienummer.

Koppel elke asset aan precies één eigenaar en een inventarisbron. De eigenaar kan de versie bevestigen of de hoster aanschrijven. De inventarisbron kan bijvoorbeeld een agent, pakketmanager of declaratie uit een containerbestand zijn. Een applicatie die door een hostingpartij wordt beheerd, heeft vaak geen betrouwbare lokale pakketuitvoer. Zet die dan op “bevestiging leverancier nodig” en maak niet zelf een versie af uit een webserverbanner.

Stel een lokale actualiteitsgrens in. Voor een extern bereikbare productieserver vereist de proef een inventarisdatum van maximaal 24 uur oud. Voor een intern systeem kan je team bijvoorbeeld zeven dagen toestaan. Dit zijn werkafspraken om oude gegevens uit de automatische route te houden, geen NCSC-norm. Een verouderd record gaat terug naar de eigenaar voor herbevestiging. Dat maakt het assetregister ook bruikbaar als je de asset-, supply-chain- en patchlaag van je bredere beveiligingsproces periodiek nalooopt.

Klaar als je per kandidaat de originele inventarisregel, eigenaar, volledige versie, pakketbron en laatste waarneming kunt openen. Een match op naam zonder versie, editie of bewijs krijgt de status “beoordelen”, geen “geraakt”.

5. Match op product, versie en toepassingsgebied

Laat de matchmotor achtereenvolgens leverancier/productfamilie, editie/onderdeel en getroffen versie toetsen. Een productmatch zonder versiegrond blijft een beoordelingskandidaat, geen patchticket.

Gebruik een versieparser die past bij het product. Een tekstvergelijking ziet bijvoorbeeld 8.10 soms als kleiner dan 8.9, en distributies voegen eigen revisies toe. Vergelijk niet op basis van lexicografische volgorde. Gebruik de vendor- of pakketmanagersemantiek en sla de bronversie op waarmee de parser vergeleek. Behandel een vers-range alleen automatisch als het schema en de gebruikte versievariant bekend zijn.

Een concreet voorbeeld staat in NCSC-2026-0443. De CSAF-boom noemt Open Source PHP en PHP; beide krijgen vers:unknown/*, terwijl de twee kwetsbaarheden known_affected naar die product-ID’s verwijzen. Het advies bevat elders wel precieze herstelversies. Een regel die known_affected vertaalt naar “iedere lokale PHP-versie patchen” mist dus het versiebewijs dat je voor een veilige ticketactie nodig hebt.

Routeer een onduidelijke productnaam, versie of installatiebron, verouderde inventaris en statusconflict naar beoordeling. Leg per geval vast: getroffen, buiten scope of onbevestigd. Noteer bij onbevestigd een eigenaar en hercontroledatum.

Klaar als 30 gelabelde CVE-product-versieproeven geen foutieve treffer opleveren. Tot die tijd maak je alleen concepttickets of beoordelingsitems.

6. Bepaal urgentie na toepasbaarheid

Bepaal eerst of product en versie binnen scope vallen; rangschik daarna op ernst, blootstelling en exploitinformatie. Zo start een hoge score op een ongebruikt product geen onnodige patchronde en raakt misbruik op een publiek systeem niet uit beeld.

Bewaar de NCSC-beoordeling naast de lokale prioriteit. In de Security Advisories gebruikt het NCSC de labels Urgent en Normaal; de brede stroom kan ook CVSS, EPSS, exploitstatus of de NCSC-score als afzonderlijke gegevens bevatten. EPSS schat de kans dat een gepubliceerde CVE in de komende 30 dagen wordt uitgebuit; het antwoordt niet of je installatie die software bevat. CISA’s KEV-catalogus registreert kwetsbaarheden waarvan misbruik is vastgesteld; ook dat is een dreigingssignaal, geen assetregister. FIRST omschrijft EPSS als een voorspelling voor de komende 30 dagen, terwijl CISA organisaties de KEV-catalogus als invoer voor hun eigen prioritering aanbeveelt.

Zet een lokale responstabel op. Een voorbeeld voor een klein beheerteam is: urgent of aantoonbaar actief misbruik op een extern bereikbaar systeem krijgt binnen één uur een eigenaar en dezelfde werkdag een gekozen patch- of mitigatievenster. Een bekende getroffen versie zonder actief misbruik krijgt een goedgekeurd venster binnen vijf werkdagen. Bij een onbekende versie krijgt de asset binnen één werkdag een beoordelaar. Dit zijn voorbeeld-SLA’s voor je eigen beleid, geen wettelijke termijnen.

Een vaste patchronde blijft geschikt voor de lange staart, maar niet als enige route voor een lek dat tijdens een onderhoudsweekend actief wordt uitgebuit. De kern van een spoedbaan naast de gewone patchcadans is dat je sneller beoordeelt welke kwetsbaarheid echt jouw systeem raakt, niet dat je ieder CVE-record onmiddellijk installeert.

Klaar als een beheerder in het ticket kan aanwijzen welke bronstatus, assetkenmerken, blootstelling en exploitinformatie de prioriteit hebben bepaald. Een kale CVSS-score is onvoldoende motivatie voor “patch deze host”.

7. Maak een ticket met eigenaar, venster en bewijs

Maak één ticket per combinatie van patchactie, doelversie, eigenaar en onderhoudsvenster. Voeg CVE, bron-ID, bronrevisie, bronlink, leverancier, product, asset-ID, waargenomen versie, doelversie, getroffen reden, NCSC-status, lokale prioriteit, eigenaar, gepland venster, teststappen en terugvalplan toe. Groepeer assets alleen als dezelfde patch, eigenaar, test en terugvalprocedure gelden. Anders wordt een geslaagd resultaat op één server onterecht bewijs voor alle servers.

Leg vóór de API-aanroep een unieke verwerkingssleutel vast, bijvoorbeeld NCSC-CVE | asset_id | target_version. Controleer eerst of die sleutel al een open ticket heeft. Gebruik bij een timeout dezelfde sleutel bij de controle en de nieuwe poging. Een tweede poging met een nieuwe willekeurige sleutel kan een dubbel ticket opleveren. De Jira Service Management Cloud-API biedt acties om aanvragen aan te maken en bestaande aanvraagstatussen bij te werken; controleer in je eigen project welke aanvraagsoort en verplichte velden het team daarvoor heeft ingericht.

Zet twijfelgevallen in een apart type “beoordeling” met de bron, afwijkende productnaam en reden voor twijfel. Ontbreekt eigenaar of onderhoudsvenster, maak dan eerst een eigenaarschapstaak.

Klaar als de API één volledig ticket aanmaakt en de eigenaar het ontvangt. Probeer dezelfde verwerkingssleutel opnieuw; er mag geen duplicaat ontstaan. Controleer dat het ticket verwijst naar de bewaarde bronrevisie én de leesbare NCSC-pagina.

8. Lees de ticket- en patchstatus terug

Een 201 Created of groen vinkje in Make is geen bevestiging dat de juiste patchtaak bestaat. Lees na het schrijven het ticket terug op basis van het aangemaakte ID. Vergelijk asset_id, CVE, doelversie, eigenaar, venster, prioriteit en bronlink met de invoer. Als één veld ontbreekt, zet het ticket in een technische uitzonderingsstatus en stuur geen patchgoedkeuring.

Na het onderhoudsvenster haalt de koppeling een verse versie uit dezelfde assetbron die de eerste match leverde. Vergelijk die met de afgesproken doelversie en voer de applicatiecontrole uit. Markeer het ticket pas als opgelost wanneer beide controles slagen. Als de versie gelijk bleef, de healthcheck faalt of de asset niet meer rapporteert, houd de status open en maak een actie voor de eigenaar.

Gebruik vaste tussenstatussen, bijvoorbeeld ontvangen, gevalideerd, beoordeling nodig, ticket aangemaakt, ingepland, gepatcht, teruggelezen en afwijking. Schrijf iedere status terug naar het assetregister met bron-ID en tijdstip. De systemen blijven dan gelijklopen; dat is ook de kern van een koppeling tussen bestaande systemen. Plan ten slotte een steekproef van vijf gesloten tickets per maand. Controleer of de assetversie, de testuitkomst en de ticketstatus nog bij elkaar passen.

Klaar als een tweede beheerder op basis van asset-ID en CVE kan terugvinden welke revisie leidde tot welk ticket en welke gemeten versie het ticket uiteindelijk sloot.

De route raakt brondata, inventaris, versieregels, API-rechten en wijzigingsbeheer. Als je die hele keten wilt koppelen, bouw dan eerst de bewijs- en uitzonderingsstappen mee.

Valkuilen

Een productstatus wordt een versieoordeel

Als de import known_affected omzet naar een host-level treffer, negeert hij editie, pakketbuild en herkomst. Bewaar de bronverwijzing en stuur product- of versieconflicten naar beoordeling.

De parser leest unknown als alle versies

vers:unknown/* geeft ook bij known_affected geen bewezen versiegebied. Haal de volledige pakketbuild op en controleer die in de securitytracker van de distributie of bij de hoster; rond pas daarna de beoordeling af.

Versies worden als tekst vergeleken

Een tekstvergelijking kan 8.10 onder 8.9 sorteren; een backport kan het upstream-nummer onveranderd laten. Vergelijk de volledige pakketrelease volgens de semantiek van de leverancier of distributie.

Een feedupdate maakt weer een patchticket

De service overschrijft oudere CSAF-versies. Als elke wijzigingsregel een nieuw ticket wordt, ontstaan duplicaten na revisies en indeximports. Gebruik document-ID | asset-ID | doelversie als vaste sleutel, werk open tickets bij en bewaar oude beslissingen in de auditgeschiedenis.

De ticket-API krijgt een timeout na de write

Na een timeout kan de write al zijn opgeslagen. Zoek met dezelfde verwerkingssleutel, lees het ticket terug en maak alleen een nieuw item als er geen bestaat. Ook een formele bron kan worden gecorrigeerd: NCSC trok in 2026 een SQLite-advisory in nadat de CVE zeer waarschijnlijk verzonnen bleek en foutieve scannerresultaten veroorzaakte.

Een advies wordt behandeld als een scanrapport

De geselecteerde Security Advisories en de brede CSAF-service leveren geen inventaris of patchstatus van jouw servers. Gebruik je assetbron om aanwezigheid en eigenaar vast te stellen.

Beslis-kader: welke koppeling past bij jouw patchwachtrij?

Kies de eenvoudigste route die de versie en eigenaar aantoonbaar goed krijgt. Laat een product nooit automatisch patchen op basis van een CVE-match. De automatie mag een ticket maken wanneer leverancier, product, editie en getroffen versie bewezen zijn, de eigenaar bestaat en de proef geen foutieve match heeft opgeleverd. Onbekenden blijven zichtbaar voor een mens.

De drempels hieronder zijn startwaarden voor een pilot, geen branchegemiddelden. Meet ze vier weken met jouw eigen feed en team.

Handmatige triage op de geselecteerde advisory-feed

Dit past als je maximaal vier relevante Security Advisories per maand verwerkt en per advies hoogstens 25 assets hoeft na te lopen. Eén beheerder moet elke beoordeling binnen twee uur kunnen afronden. Werk vanuit de openbare NCSC-RSS en de gekoppelde CSAF- of HTML-pagina. Houd een spreadsheet bij met advisory-ID, product, kandidaat-assets, conclusie, eigenaar en ticketnummer.

Voor een kleine beheeromgeving is dit de goedkoopste start wanneer je al een ticketpakket hebt. Gebruik deze route niet om ieder CVE-record uit de brede kwetsbaarhedenservice met de hand te beoordelen. Die dataset is juist bedoeld voor eigen filtering en geautomatiseerde verwerking.

Kant-en-klaar kwetsbaarhedenbeheer met geteste NCSC-CSAF-import

Kies dit als je al een kwetsbaarhedenplatform hebt of honderden productinstallaties beheert, meerdere mensen de wachtrij delen en de leverancier aantoonbaar CSAF 2.0 uit de NCSC-directory kan verwerken. Laat het platform in een proef 20 echte NCSC-documenten afhandelen, waaronder revisies, vers:unknown/*, een bronstatusconflict en een Linux-backport. Eis dat het laat zien waarom een asset matcht en hoe je een foutieve match terugdraait.

Een demonstratie met één bekende CVE is onvoldoende. Als de leverancier de bronstatus, originele referentie, versiegrond en asset-eigenaar niet samen toont, koop je een lijst met kwetsbaarheden zonder betrouwbare patchbeslissing.

Low-code koppeling met menselijke uitzonderingswachtrij

Gebruik Make of n8n wanneer je één betrouwbaar assetregister, één ticketwachtrij en maximaal 1.000 beheerde assetrecords hebt. Houd de import als één workflow met een duidelijke uitzonderingswachtrij. Laat een beheerder de 30 gelabelde proefgevallen controleren; automatische ticketaanmaak begint pas na nul foutieve treffers en 100 procent correcte teruglezing in die proef.

Deze route past wanneer API’s en veldnamen stabiel zijn, maar er nog geen kant-en-klaar product is dat jouw inventaris goed kent. Make rekent per uitgevoerde moduleactie in credits. n8n rekent bij de cloudplannen per workflow-uitvoering. Schat de vaste pollingruns daarom mee voordat je een interval kiest.

Maatwerk-koppeling voor afwijkende productversies en statusconflicten

Maatwerk begint logisch als je twee of meer inventaris- of ticketbronnen moet combineren. Het kan ook lonen als meer dan 10 procent van de kandidaten onduidelijk blijft. Een derde signaal is meer dan acht uur per maand aan handmatige uitzonderingen, twee maanden achter elkaar. Het loont ook als productnamen, containerimages en backported Linux-pakketten per leverancier anders moeten worden vertaald.

Laat het ontwerp eerst de gegevenscontracten vastleggen: welke feedvelden zijn leidend, welke assetbron bezit de versie, wat betekent een onbekende status, wie neemt de uitzondering en hoe wordt het ticket teruggelezen? Bouw een menselijk controlepad in voordat je writes automatiseert. Vergelijk de investering met je eigen kosten per beheeruur en de bestaande abonnementen. Er is geen bruikbare algemene eurogrens zolang die twee bedragen per organisatie verschillen.

Deze keuzehulp volgt dezelfde routes.

Uitgewerkt voorbeeld: PHP-advies met twee versietakken

Dit is een fictieve oefencasus met echte NCSC-product- en herstelgegevens. Organisatie Noordlicht Webbeheer heeft 24 assetrecords. Ze wil NCSC-2026-0443 verwerken, het advies van 21 oktober 2026 over twee ernstige PHP-kwetsbaarheden die op afstand code-uitvoering mogelijk maken zonder authenticatie. Het advies noemt vier upstream-doelversies: 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Linux-distributies en LTS-gebruikers moeten de beveiligingsupdate van hun eigen leverancier toepassen.

De CSAF-advisory gebruikt voor de twee PHP-productvermeldingen vers:unknown/*, ondanks known_affected voor beide CVE’s. De ticketmotor kan uit dat document dus de pakketversie van Noordlicht niet afleiden. De NCSC-pagina geeft de getroffen software, twee CVE’s en het hersteladvies; het CSAF-bestand laat de onbekende productversie en statuskoppeling zien. De upstreammelding van het PHP-team bevestigt die vier doelversies voor CVE-2026-109618. Voor de tweede CVE bewaart de beheerder de aparte NCSC-referentie uit de advisory. Het assetregister moet in beide gevallen de lokale versie en distributie bevestigen.

In de fictieve inventaris verwerken 7 webservers PHP-verzoeken. Vier draaien upstream PHP 8.3.35, twee draaien upstream PHP 8.4.26 en één Linux-server vermeldt alleen PHP 8.2 zonder volledige pakketbuild. Eén extra asset draait PHP uitsluitend voor opdrachtregeltaken. De overige 16 assets bevatten geen PHP-runtime. De optelsom is 7 webservers + 1 opdrachtregelserver + 16 overige assets = 24 records.

De matchmotor maakt twee patchtickets voor de zes exact herkende webservers: één ticket voor vier systemen met PHP 8.3.35 naar 8.3.36 en één voor twee systemen met PHP 8.4.26 naar 8.4.27. Beide tickets noemen NCSC-2026-0443, revisie 1.0.0, de twee CVE’s, de huidige versies, de doelversies, de applicatie-eigenaar, het testvenster op 28 oktober 2026 van 20.00 tot 21.00 CET en de terugvalstappen. Het Linux-pakket krijgt geen upstream-doelversie toegewezen. De Linux-beheerder haalt eerst de volledige pakketidentiteit op en controleert de beveiligingsupdate van de distributie. Dat blijft één open beoordelingstaak totdat de build is bevestigd.

Ook het opdrachtregelsysteem krijgt een scopecontrole. Het NCSC-advies zegt dat PHP-installaties die webverzoeken verwerken geraakt zijn. De beheerder bevestigt uit de configuratie dat deze asset uitsluitend opdrachten verwerkt en geen webverzoeken of webworkers heeft. De scopebeslissing wordt met de configuratiebron vastgelegd, waarna het record buiten de patchactie blijft. De zestien overige systemen krijgen geen patchticket omdat de productmatch ontbreekt.

Leg ook de adviesdatum in het ticket vast. In een NCSC-update van 23 oktober over de PHP-kwetsbaarheden staat één melding van mogelijk misbruik in het buitenland, zonder bevestiging dat de aanval slaagde; het patchadvies bleef gelden. Dit nuanceert de prioriteit, maar verandert de assetmatch niet.

Na het venster haalt de assetagent zes versies terug. Alle vier upstream-systemen melden 8.3.36 en beide andere systemen 8.4.27. De gezondheidstest slaagt op alle zes. De teruggelezen versie en testuitkomst sluiten de twee patchtickets. De Linux-versie blijft in beoordeling tot de volledige pakketbuild is gecontroleerd. De opdrachtregelserver blijft buiten scope met bewijs. De zestien assets zonder PHP blijven zonder ticket. De telling blijft daarmee gelijk: zes patchdoelen, één versiebeoordeling, één scopebesluit en zestien niet-matchende assets, samen 24.

Vergelijkingstabel

Productprijzen en limieten gecontroleerd op 11 november 2026. Bedragen blijven in de valuta van de leverancier. De berekende aantallen in de tabel zijn planningsrekenwerk op basis van de gepubliceerde limieten, geen extra prijsbelofte.

Make Free verbruikt credits per moduleactie en pauzeert scenario’s als ze op zijn; de maandlimiet is 1.000 credits. n8n Starter kost €20 per maand bij jaarlijkse betaling, voor 2.500 workflow-uitvoeringen. Atlassian Standard toont 5.000 Assets-objecten en $21,50 per agent per maand. Geen van deze producten matcht vanzelf NCSC-versies aan jouw assets.

Begin daarom met het systeem dat de actuele versie werkelijk kent. Een ticket met een eigenaar is een afspraak. Alleen de teruggelezen pakketversie plus de geslaagde test bewijst dat de kwetsbare installatie hersteld is.