Wie ziet eerst waar het draait?
De meeste securityteams herkennen dit moment meteen. Er komt een kritiek advisory binnen. De CVSS-score is hoog genoeg om ieders aandacht te trekken. Iedereen begrijpt dat er iets moet gebeuren.
En toch stokt het vaak niet op techniek, maar op iets veel simpels: wie kan binnen een uur aantonen waar het component draait, wie eigenaar is, en of het productie raakt of alleen ergens in een teststraat hangt?
Dat is de ongemakkelijke vraag. Niet omdat hij moeilijk is. Wel omdat hij eigenaarschap afdwingt.
NCSC-2026-0392 maakt dat concreet
De aanleiding is helder. In NCSC-2026-0392 meldt het NCSC dat IBM 12 kwetsbaarheden heeft verholpen in IBM MQ, IBM MQ Appliance en Langflow OSS. Vier daarvan zijn als kritiek aangemerkt.
Eén kwetsbaarheid, CVE-2026-10747, heeft een CVSS-score van 10,0 en zit in IBM MQ als heap-based buffer overflow. Drie kwetsbaarheden in Langflow OSS — CVE-2026-79724, CVE-2026-85025 en CVE-2026-81204 — hebben een score van 9,8. Die kunnen volgens het advies zonder authenticatie op afstand worden misbruikt om willekeurige code of OS-commando’s uit te voeren.
Dat zijn geen details voor een postmortem. Dat zijn details die een organisatie dwingen om snel te weten: staat dit ergens live, en zo ja, waar precies?
Waarom “kritiek” intern vaak toch een debat wordt
Op papier is het eenvoudig. Kritiek advies binnen, patchen, klaar.
In de praktijk ontstaat er eerst een inventarisatievergadering. Security wil weten of het geraakt is. Platform zoekt in deploymentoverzichten. Een teamlead kijkt naar de releaseplanning. Iemand zegt dat het vast in een oude omgeving staat. Iemand anders weet zeker dat het alleen een interne tool is.
Tegen de tijd dat de eerste zekerheid op tafel ligt, is de echte vertraging al gevallen: niet in het installeren van een patch, maar in het vinden van de juiste eigenaar.
Dat is precies waarom dit soort advisories zo vaak onderschat worden. De technische ernst is duidelijk. De operationele route niet.
En hoe groter je softwarelandschap, hoe duurder dat gat wordt. Niet alleen in tijd, maar ook in verstoring. Want als je pas na de eerste escalatie ontdekt waar iets draait, ga je sneller grof werken: breed uitzetten, breed patchen, breed afstemmen. Dat voelt daadkrachtig. Het is vooral een teken dat het overzicht te laat kwam.
Open source is niet het probleem. Onzichtbaarheid wel.
Langflow OSS is hier een goed voorbeeld van, juist omdat het de reflex ontmaskert. Veel organisaties behandelen open source nog steeds alsof het automatisch een categorie is in plaats van een concrete plek in hun stack.
Maar een component is geen label. Het is een runtime, een eigenaar, een omgeving en een wijzigingspad.
Zolang dat niet direct aan elkaar hangt, blijft “we gebruiken het niet bewust” een zin die te vaak als geruststelling wordt uitgesproken. In werkelijkheid betekent het meestal: iemand heeft het ooit toegevoegd, ergens draait het nog, en niemand voelt zich primair verantwoordelijk voor de vraag wat er gebeurt als het kritisch wordt.
Dat is geen complianceprobleem. Dat is een stuurprobleem.
Het echte verschil zit in beslissen, niet in verzamelen
Veel teams investeren in meer signalen. Meer scanners. Meer meldingen. Meer dashboards.
Maar bij een advies als NCSC-2026-0392 is het zinvoller om één vraag sneller te beantwoorden dan tien vragen tegelijk: waar draait dit component, en wie kan daarover beslissen?
Dat klinkt bescheiden. In de praktijk is het een harde scheidslijn tussen volwassen en fragiel.
Volwassen teams hoeven niet eerst te bewijzen dat het gevaarlijk is. Ze kunnen direct laten zien of het geraakt is, welke service het betreft, welke omgeving het is, en wie de wijziging moet dragen. Fragiele teams hebben misschien wel alle tooling, maar geen directe koppeling tussen advisory, asset en owner.
Dan wordt een CVSS 10,0 alsnog een interne discussie over prioriteit.
Wat je hier als leider van moet onthouden
De belangrijkste consequentie van dit soort advisories is niet dat je “sneller moet patchen”. Dat is te vaag en te laat.
De consequentie is dat je je organisatie moet kunnen laten handelen op bewijs. Niet op vermoedens. Niet op herinneringen van een engineer die vorig kwartaal nog iets in een Slack-thread zag. Bewijs van waar het draait. Bewijs van wie het beheert. Bewijs van wat de business-impact is als je het nu wijzigt.
Wie dat niet scherp heeft, betaalt altijd dezelfde rekening: vertraging, extra afstemming en verstoring van werk dat eigenlijk gewoon door moest.
Daar zit voor softwareleiders de echte spanning. Niet in de melding zelf, maar in de vraag of je organisatie er een besluit van kan maken zonder eerst een halve middag te zoeken.
Security-volwassenheid laat zich hier verrassend simpel zien. Niet in meer alarmen. Wel in sneller kunnen aantonen wat relevant is, en wat niet.