Door Anoniem: Quote van Linus hier
I think we should simply make it a rule that "a 'security' bug that is
found by AI is public".
Now, I may be influenced by that "my inbox is a disaster during the
merge window" thing, but I do think this is pretty fundamental: if
somebody finds a bug with more or less standard AI tools (ie we're not
talking magical special hardware and nation-state level efforts), then
that bug pretty much by definition IS NOT SECRET.
So why should be consider it special and have it be on the security list?
Yes, yes, I know - some people think that "security bugs are special".
And I've been on the record before calling that opinion special - in
the short bus sense.
Bugs are bugs. And not having them in public only makes them harder to
deal with.
Ik ben het er roerend mee eens dat bugs bugs zijn. Security bugs zijn doodgewone bugs waarvan op een gegeven moment duidelijk wordt dat ze misbruikt kunnen worden, vaak in combinatie met andere bugs, om beveiligingen te doorbreken. Je bent een hoop ellende voor door ze niet pas een hoge prioriteit te geven als duidelijk wordt hoe ze misbruikt kunnen worden, als het eigenlijk al te laat is dus.
Door AI gevonden bugs als publiek beschouwen, daar ben ik niet direct zo zeker van. In de jaren '90, voordat responsible disclosure was bedacht, waren er softwareleveranciers die echt geen donder deden tot ze de gevolgen van een beveiligingslek publiek voor hun kiezen kregen, zodat lekken in de openbaarheid gooien een middel was om iets veranderd te krijgen. Degenen die lekken zo openbaarden verdedigden dat typisch met het argument dat als zij het konden vinden een ander dat ook kon, en je kon beter weten wat er lek was dan dat het lek ongemerkt werd geëxploiteerd. Alleen werkte het toch beter om een lek even onder de pet te houden zodat kwaadwillenden pas op het bestaan ervan werden gewezen als er al een patch voor was.
Dat AI het zoeken vereenvoudigt, en openstelt voor mensen die zelf de benodigde vaardigheden niet hebben, dat op zich lijkt me een open deur. Er verschuift dus zeker iets. Of het zo extreem ligt dat het meteen zinloos is om het nog onder de pet te houden vind ik minder evident. Als je tegen zo'n AI-systeem simpelweg "heb je een lek voor me?" kan zeggen en werkelijk alles rolt er dan uit, dan staan alle sluizen volledig open. Als je als mens nog enige vaardigheid nodig hebt om gericht naar iets te zoeken is er nog steeds een drempel en wil je de meute nog steeds niet wijzen op waar de zwakke plek dan gevonden is tot er een patch beschikbaar is, lijkt me.
Nu is dit nog in de discussie fase, maar de richting is heel duidelijk - als het "te makkelijk" was om te vinden wordt het niet als 'geheim' behandeld - en is de hoop dat geheim houden totdat er patches zijn ook niet meer reeel .
Er zit wat nuance in de voorstellen - crash is publiek, een volledig PoC exploit liever niet .
Mooi, dan wordt de balans inderdaad gezocht.
Dit kwam ik net tegen en is vermoedelijk onderdeel van diezelfde discussie:
https://www.theregister.com/oses/2026/05/11/linux-kernel-maintainers-pitch-emergency-killswitch-after-copyfail-and-dirty-frag-chaos/5237801Dit is een voorstel, met een patch ervoor, om een killswitch in de kernel in te bouwen. Als een functie buggy blijkt te zijn kan je hem simpelweg uitschakelen (tot de volgende reboot). Niet door het laden van een module te blokkeren, het aanroepen van een specifieke kernel-functie wordt geblokkeerd, en wel direct. Dat werkt natuurlijk alleen voor functies die niet zo essentieel zijn dat je meteen het hele systeem ermee onderuit haalt.
Ik vermoed dat dit cluster van verwante bugs allemaal in dezelfde set van modules mede vanwege deze filosofie relatief snel naar buiten komen.
Dat zou inderdaad heel goed kunnen. Als dit risico's voor je oplevert had je al maatregelen moeten nemen. Wat dat betreft komt dit dus neer op nog eens wijzen op maatregelen die al genomen hadden moeten zijn.
