Af en toe kiest een leverancier ervoor om een kwetsbaarheid stilletjes te verhelpen, zonder een officiële advisory, CVE of duidelijke uitleg, en slechts een vage vermelding in een changelog. Het idee hierachter is dat het niet openbaar maken van details aanvallers geen routekaart geeft naar de oorzaak van het probleem. Toch zijn patches geen geheimen zodra ze beschikbaar zijn. Zelfs zonder CVE of advisories kunnen mensen met een debugger en disassembler verschillen tussen oude en nieuwe versies analyseren en zo achterhalen wat er is veranderd. Dankzij geavanceerde taalmodellen is deze vaardigheid bovendien voor meer mensen toegankelijk geworden.

Stille patches houden kwetsbaarheden dus niet geheim, ze verbergen de details alleen voor iedereen behalve degenen die al in staat zijn om ze te misbruiken. Dit sluit onder andere penetratietesters uit, die risico’s moeten aantonen, en engineers die kwetsbaarheden detecteren en signatures ontwikkelen voor beveiligingsproducten. Ook journalisten, academici en beleidsmakers die risico’s uitleggen aan besluitvormers worden hierdoor beperkt. Vooral IT-beheerders die dagelijks een grote hoeveelheid patches beoordelen, missen de benodigde informatie om te bepalen welke updates dringend zijn en welke kunnen wachten. Deze groep heeft doorgaans niet de tijd of middelen om binaries te reverse-engineeren.

Het oorspronkelijke argument voor stille patches werkt dus averechts: het beperkt de kennis over kwetsbaarheden niet tot een kleine groep, maar tot een selecte groep die gemotiveerd is om reverse-engineering toe te passen. In de praktijk zijn dat vaak aanvallers met de juiste vaardigheden en motivatie. Verdedigers blijven achter met onvolledige informatie, wat ook het risico vergroot dat toekomstige productontwikkelaars dezelfde fouten opnieuw introduceren omdat eerdere kwetsbaarheden geheim werden gehouden.

Er zijn situaties waarin het uitstellen van volledige openbaarmaking verdedigbaar is, bijvoorbeeld bij SaaS-producten waarbij gebruikers geen patchbeslissingen hoeven te nemen en updates automatisch verlopen zonder downtime. Ook bij kleine, gecontroleerde gebruikersgroepen die snel automatisch worden bijgewerkt, is een korte embargo-periode operationeel van aard en brengt het weinig risico met zich mee. In deze gevallen is het triageproces van IT-beheerders minder relevant omdat patches automatisch worden toegepast.

Een recente ontwikkeling is dat Broadcom, eigenaar van VMware en daarmee ook van het Spring Framework via VMware’s Tanzu-divisie, een programma heeft uitgebreid waarbij betalende klanten eerder toegang krijgen tot gevalideerde patches met CVE’s via een privé-repository. Dit kondigde Broadcom aan in juni 2026. Hoewel Broadcom zegt CVE’s te blijven uitgeven voor alle ondersteunde versies van Spring-projecten, betekent deze vroege toegang tot exploitinformatie dat klanten met budget een voorsprong krijgen. Dit vergroot het risico dat kwaadwillenden met voldoende middelen ook vroegtijdig kennis krijgen van kwetsbaarheden die voor de rest van de open source-gemeenschap nog niet openbaar zijn.