Linux Foundation wil opensource beschermen tegen stortvloed aan AI-bugmeldingen

De Linux Foundation wil ontwikkelaars van opensourcesoftware beschermen tegen een stroom aan bugmeldingen die steeds vaker AI‑gegenereerd zijn. De financiering hiervoor bedraagt 12,5 miljoen dollar en komt van Anthropic, AWS, GitHub, Google, Microsoft en OpenAI.

Het nieuwe project moet de beveiliging van opensourcesoftware verbeteren, stelt de Linux Foundation. Cybersecurity wordt steeds complexer, geeft de stichting aan. Dat komt ook door vooruitgang in AI. Dat verhoogt de snelheid en de schaal waarop kwetsbaarheden in opensourcesoftware worden ontdekt.

Ontwikkelaars die opensourcecode maken en onderhouden, worden bedolven onder een 'ongeëvenaarde toestroom' van meldingen van beveiligingsontdekkingen. Veel van die binnenkomende bugs zijn gevonden door geautomatiseerde systemen. Daarbij ontbreekt het aan de menskracht en technische middelen om al die meldingen te beoordelen en aan te pakken.

Onduidelijk

Twee beveiligingsinitiatieven binnen de Linux Foundation, Alpha-Omega en de Open Source Security Foundation (OpenSSF), willen dit nijpende probleem aanpakken. Zij krijgen daarvoor 12,5 miljoen dollar van bigtechbedrijven Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft en OpenAI.

Het is niet duidelijk wat Alpha-Omega en OpenSSF concreet gaan doen met die financiering. De Linux Foundation spreekt van 'het ontwikkelen van duurzame securityoplossingen' voor de lange termijn. Deze nog niet gespecificeerde tools moeten opensourcegemeenschappen wereldwijd ondersteunen bij het omgaan met binnenkomende bugreports.

Door Gemini gegenereerde afbeelding over AI-slop

Reacties (43)

[jeroen3]

Kan github geen chapta toevoegen aan de PR knop?

[wiseger]

Als de bug gevonden is door een AI tool en een menselijke gebruiker doet een pull request om deze bug op te lossen, dan zal het toevoegen van een chapta niet veel uitmaken.

Het probleem zit hem in de aantallen gevonden bugs en aantallen pull requests waar men mee te maken krijgt.

[pizzafried]

Zolang een captcha niet is op te lossen door AI, heb je in ieder geval een mens geforceerd om er naar te kijken.

De aantallen zijn inderdaad meer het probleem. Lijkt me dan dat mensen die een pull request doen eerst zich moeten verifiëren, waarna er een logisch limiet zit op het aantal meldingen per bijvoorbeeld uur, of op basis van je gemiddelde met een limiet. Een beheerder kan dan alsnog een gebruiker blokkeren als die daar misbruik van lijkt te maken.

[wiseger]

Vroeger moest je toch een aardig wat kennis hebben en een goede programmeur zijn, wilde je bugs in open source vinden en oplossen.

Tegenwoordig is dat niet meer zo, bijna iedereen kan open source code door een AI tool halen die dan met een lijst gevonden bugs en zelfs oplossingsvoorstellen komt. Het aantal gebruikers dat nu bugs rapporteert en pull requests doet, is zeer sterk toegenomen. De beheerders van open source projecten worden daardoor bedolven onder het aantal verzoeken. Ze kunnen het gewoon niet meer aan om alle verzoeken te beoordelen.

[Ablaze]

Ik mis alleen wat daar erg aan is.

Bugs zijn bugs. Je kunt ze klassificeren en op volgorde afhandelen. Er mag best een backlog zijn

[ElCondor]

Het zit hem juist in het feit dat AI het meestal verkeerd heeft en dat er onterecht bugs gemeld worden.

Dit is omdat er dan een bounty voor te verdienen valt. Als developer moet je dan toch aan de slag om een 'potentiële' bug door te kijken om na te gaan of het echt om een bug gaat, of dat het om een false 'positive' gaat. DIT proces kost veel tijd en dat is een groot probleem.

[Ablaze]

Aan de andere kant zou je kunnen stellen dat het beter is om 100 bugmeldingen te krijgen waarvan driekwart een false positive is, dan dat je ze niet kreeg.

Dat het werk kost om bug reports te klassificeren is duidelijk, maar uiteindelijk is er ook baat bij.

Ik denk dat je niet zou moeten "beschermen" maar juist de processen rondom het invoeren, klassificeren en verwerken van bugs beter en efficiënter moet maken.

[youridv1]

Aan de andere kant zou je kunnen stellen dat het beter is om 100 bugmeldingen te krijgen waarvan driekwart een false positive is, dan dat je ze niet kreeg.

Oneens. Zo veel ruis wil je niet en heeft vaak het gevolg dat de maintainers door de bomen het bos niet meer zien en de ontwikkeling daardoor vertraagt.

Als je dit zijn vrije loop laat, gaan er vanzelf een hoop maintainers gewoon stoppen met PR's accepteren.

[Reactie gewijzigd door youridv1 op 19 maart 2026 14:22]

[jaxxil]

Als maintainers betaalde medewerkers waren, dan was dat misschien zo. Maar dat zijn ze niet, het zijn vrijwilligers. Vrijwilligers die voor elk rapport moeten gaan zitten om uit te pluizen of het ergens uberhaupt wel ergens over gaat.

[jaapsh]

Ik denk dat AI meestal gelijk heeft. Ik lees ook niets in het artikel dat het gaat om een grote instroom van foutive bug meldingen.

Dus eens met @Ablaze
Ik denk dat het positief is. En denk dat meer (valide) bugmeldingen alleen maar bijdragen tot betere software. Alleen de backlog voor een mens die ze moet controleren is inderdaad een issue.

[NoTechSupport]

Bugs zijn geen bugs. Sommige dingen die als bug gemarkeerd worden zijn geen bug. Waar vroeger een mens met kennis van zaken nadacht over de "bug" en hoe die te rapporteren doet AI dat niet (goed genoeg). Bovendien zijn de rapporten zelf vaak door AI geschreven met veel ruis op de boodschap. Waar je vroeger aan iemand zijn schrijfstijl al een indicatie had van wie de bug rapporteerde en of die ziet waar hij/zij het over had moet nu eerst al die ruis weggefilterd worden. Dit vraagt veel energie (van echte mensen) die de de code onderhouden.

[pizzafried]

Het zijn er zoveel, en je moet dus prioriseren. Als de helft hetzelfde is maar anders omschreven, moet je veel werk doen om al die PR's of bug reports door te lezen, te begrijpen en bepalen wat er mee moet gebeuren. Dat is niet echt effectief te noemen...

[martijnvanegdom]

Als je ook de gebeurtenissen rondom curl en andere projecten volgt dan zie dat er wel een groot probleem aan het ontstaan is:

• De influx dreigt zo groot te raken dat het 'klassificeren en op volgorde afhandelen" eigenlijk niet meer te doen is. Er komt gewoon te veel binnen. Dat klassificeren en afhandelen kost namelijk gewoon veel tijd. Tijd die vroeger bij degene lag die de PR maakte.
• De kwaliteit van wat er binnenkomt er relatief laag. En bij curl werd bijvoorbeeld opgemerkt dan veel van de bugs helemaal geen bugs waren. En ja, N=1, maar als ik aan AI vraag om een security scan te doen van mij code dan is echt een heel deel van meldingen zijn of 1) geen bugs. 2) zijn zo minor dat het absoluut niet waard is om daar tijd in te steken. Ik heb letterlijk het comment van AI gehad: "je gebruikt ?id= is je query string, dit maakt het makkelijk om voor hackers te raken waarvoor dat veld gebruikt word.."
• Veel van de AI heeft vaak maar een klein inzicht in de code base. Dus er vaak te weinig contextueel begrip van wat er in de verschillende lagen gebeurd. Zo vertelde AI mij dat de er een groot gevaar was op SQL injection, omdat de input in mijn repository classes niet gecontroleerd werden. Echter, AI had niet de laag er boven bekeken of niet opgewerkt dat regel 1 in het dit project: Je valideert input daar waar het binnen komt en dat de input dus al gevalideerd naar de SQL class gaat. En het is niet efficiënt om dingen op 10 plekken te controleren.

Ik zeer zeker niet perse tegen AI. Maar je moet het controleren en verifiëren en dus weten wat het doet. En ik denk dat we aan het begin van een revolutie staan. Maar wat AI uit spuit is nog niet (voldoende) betrouwbaar).

Maar mensen die met weinig kennis software met AI maken en het vervolgens het de wereld in slingeren, dat is hetzelfde als met een LLM een brief sturen in een taal die je niet beheerst er blind verwachten dat het volledig correct is en dat je vervolgens krijgt wat je verwacht.

[Olaf van der Spek]

Het probleem zit hem in de aantallen gevonden bugs

Probleem is vooral de aantallen gevonden non-bugs / false-positives..

[Meg]

Die werken vaak ook maar tijdelijk, tot een AI ze kan oplossen.

[IJsbreker]

Dit gaat via api's of de gh-tool via de cli. Dus het vermoeden is dat het AI is, maar het kan ook een mens zijn. Dat probleem kan je niet zo maar tackelen.

[Dala]

Als een van de pushers van genAI zou me dat verbazen.

[jprommen]

Een ai is niet gelijk aan een bot, mijn openclaw setup heeft gewoon captcha skill en als dat niet lukt, opent het een browser en lost die het daar op.

[Exhonor]

Ben ik de enige die het redelijk toondoof vind dat er in artikelen over onderwerpen als overmatig AI gebruik en de overlast die het veroorzaakt alsnog dingen als AI-gegenereerde slop afbeeldingen worden gebruikt?

Het argument dat AI slop niet iets is wat we willen hebben wordt behoorlijk onderuit gehaald als je een AI slop afbeelding erbij zet die geen toegevoegde waarde heeft.

[Dwarrelegel]

Eens.

Maar het is een artikel van Tweakers over dat Linux foundation geen AI wil. Iets oudere discussie: Tweakers beleid omtrent gebruik AI voor illustraties Maar volgens mij vind de redactie het prima om AI illustraties te gebruiken. Hier word zelfs nog gezegd dat ze transparantie willen aanhouden door zowel de LLM en prompt er bij te noemen. Iets wat bij het huidige plaatje dus alleen nog maar het merk is. Bij het oorspronkelijke artikel van dit plaatje hebben ze in elk geval nog de versie en exacte LLM staan.

De normalisering van AI.

[locke960]

Niet echt, dat is ironie en waarschijnlijk bewust gedaan.

[Exhonor]

Ik snap dat er bewust is gekozen om zo'n afbeelding toe te voegen.

Ik trek dit besluit alleen in twijfel. Als je een artikel schrijft over hoe slecht voedselverspilling wel niet is en vervolgens een hele maaltijd in de ton flikkert om er een foto van te maken 'ter illustratie' dan is dat toch ook niet de verenigen met de inhoud van de tekst?

Het is niet alsof dat plaatje essentieel is om het artikel te begrijpen.

[bzuidgeest]

Het is alleen slop als het niets toevoegt, de afbeelding lijkt mij toepasselijk voor het artikel en is in mijn definitie geen slop. Alleen maar met AI gegenereerd en het is misbruik van de slop term om alles dat AI maakt zo te noemen.

Als een AI een arts helpt jou MRI te beoordelen en zo je leven red is het toch ook geen slop? Slop hangt af van de vraag, het resultaat en het doel.

[Exhonor]

AI een MRI laten beoordelen is echt totaal niet te vergelijken met het genereren van een plaatje als een plaatje niet eens noodzakelijk is om toe te voegen.

Wat mis je als dat plaatje er niet was geweest?

[bzuidgeest]

Wat verlies je als het plaatje er wel is. Opmaak en versiering is normaal in artikelen en website. Maakt de ervaring prettiger. De hele site hangt van "nutteloze" css aan elkaar. Zonder dat verlies je geen inhoud, maar het maakt de gebruikservaring minder prettig. Een beetje humor toevoegen met een plaatje kan de toon lichter maker, een beetje leuker. Als ze het een menselijke tekenaar hadden gevraagd had je niets gezegd. Dus wat is het probleem dat een AI dezelfde toevoeging heeft gemaakt voor tweakers?

[Exhonor]

Als ze het een menselijke tekenaar hadden gevraagd had je niets gezegd

Nee, klopt. Dan had ik er niks van gezegd, want mijn hele punt is dat het redelijk hypocriet is dat je een artikel schrijft waarin het gebruik van AI wordt bekritiseerd maar vervolgens wel doodleuk gebruikmaakt ervan om een plaatje te genereren.

Als ik naar een restaurant ga en een goedkope magnetronmaaltijd krijg voorgeschoteld en als ik erover klaag dat de ober zegt "Ja, maar als een kok dit had bereid dan had je niks gezegd"... Ja, dat is juist het hele punt.

[bzuidgeest]

Waarom is het hypocriet? Het gaat om twee heel verschillende gebruiksvormen van AI. Het ene is het automatisch genereren van PR's met nutteloze changes die developers overweldigen. Het andere is een plaatje genereren waar niemand last van heeft onder een artikel dat het artikel illustreert.

Je voorbeeld zou eerder moeten lezen als je krijgt een goedkope maaltijd in het restaurant van de robot en gaat dan klagen over de kleur van de muur omdat die ook door een robot geschilderd is.....

Gewoon omdat het ene gebruikt problematisch is, moet je niet alle gebruik ineens problematisch noemen.

En dat is precies mijn punt. Je noemt alles slop omdat 1 ding slop is.

[kdekker]

Ik heb zelf een keer gehad dat CoPilot zelf voorstelde een issue aan te maken (voor een Microsoft project). Kortom: het wordt ook wel heel makkelijk gemaakt om zoiets te doen. Als het de spuigaten uitloopt, zullen er vanzelf tegenmaatregelen genomen worden.

Mijn ervaring tot nu toe is dat agentic coding varieert van geweldig-wat-een-oplossing (die je zelf niet snel had verzonnen of zo snel opgelost) tot wat-stupide (een triviale fout niet eens meenemen in de denkrichting, maar veel complexere hallucinaties uitvoert).

[jeroen3]

Het genereert ook best wel vaak heel veel code die compleet overbodig is voor zijn eigen geboden oplossing.

[kdekker]

Klopt. Kun je wel een beetje tunen met instructies. Alleen: als je CoPilot inzet op een terrein waar je zelf geen specialist in bent, dan is dat al redelijk lastig te controleren.

Net nog even een simpele opdracht: controleer de indenting van files en of dit consistent tabs zijn ipv een mix van tabs en spaties. Wat gebeurde er: alle spaties werden vervangen door `t (backtick t, niet \t). Dat zit dan weer meer in de categorie stupide. Aan de andere kant: een veel complexere opdracht als: zorg dat de unittests gaan werken (ik had oude in/expected unittest resultaten en de backend vervangen). En dat lukte CoPilot ook. Iets wat ik zelf met veel meer tijd en moeite voor elkaar had gekregen.

[Louw Post]

Kan me nog herinneren van jaren terug dat mensen met standaard tooltjes je website gingen scannen en dan 'serieuze' problemen gingen melden en er soms ook nog geld voor wilden (zal vast nog steeds gebeuren).

Kan me goed voorstellen dat het met AI nog erger geworden is.

[braboman]

Dat gebeurt helaas nog steeds via serieus klinkende sites als openbugbounty.org

[jip_86]

Langzaamaan gaat het hele internet ten onder aan AI slop. Je ziet het overal dichtslibben.

Youtube is ook complete troep met AI videos. Plaatjesgenerators overal met dezelfde AI stijl. Games, DLSS5 word tot de grond afgebrand. Teksten allemaal met emojis en ga zo maar door.

Hopelijk komt er snel een grote ommekeer. Je ziet het al een klein beetje met bijvoorbeeld Microsoft die al aan het dimmen is, dat mag wel bij veel meer bedrijven.

[SinergyX]

Oplossing is toch simpel? Zet AI in die bugs en PR's gaat beoordelen

[- peter -]

Dat is wat ze gaan doen denk ik eerlijk gezegd.

[smiba]

Ik mag toch echt hopen van niet, want dan krijg je de zelfde frustratie als bij de klantenservice van praktisch ieder bedrijf op het moment

Je komt met een duidelijk issue, duidelijke beschrijving en misschien zelfs een solution en dan krijg je zo'n koud dom AI antwoord die compleet de plank misslaat

Denk dat als AI PRs moet gaan beoordelen het echt de laatste spijker in de kist van open source is

[kdekker]

Dat gebeurt al of gaat gebeuren. Je ziet nu al in de release notes van visual studio 2026 dat er speciale agents komen. Bijv. review agents.

Ik denk zelfs dat de AI (gekte?) zover gaat dat functioneringsgesprekken en sollicitaties door AI beoordeeld zullen gaan worden. Nu nog hopen dat iemand gaat beseffen dat de meeste mensen het niet leuk vinden dat AI henzelf (indirect) beoordeelt. Ik vermoed dat weinig mensen echt beseffen wat de impact is van AI. En zeker onoordeelkunding gebruik nog lelijke missers zal gaan veroorzaken.

De filosofische vraag: hoe ver zal AI gaan, als mensen steeds luier/dommer/efficienter/slimmer/gemakzuchtiger (doorstrepen wat niet van toepassing is) worden en AI geen menselijke feedback meer krijgt, maar doen moet met de informatie die (andere) AI agents bakken. Wat krijg je als je lucht met lucht bakt? Je zou zeggen dat het op een zeker moment AI aan z'n max zit, tenzij - en die mensen zijn er - denken dat AI zelfstanding denkvermogen heeft (a la een mens).

[willemoldemans]

Hoeveel procent van de PR zijn ook daadwerkelijk kritische bugs? Als dit voldoende hoog is dan heeft het beperken van de PR’s niet persé het gewenste effect. Helemaal als de AI tools of developers straks de bugs niet meer doorgeven aan de foundation maar aan kwaadwillende partijen

[starfight]

Als maintainer van een paar opensource projecten, ENORM veel, op 1 van de projecten zijn 80% PR's AI slop PR's die bugs fixen die geen bugs zijn.
AI heeft gewoon inherent het probleem dat ze niet de volledige codebase kennen, en tools als GitNexus helpen daar wel wat bij, maar het is geen geen geval een vervanging van iemand die even de moeite neemt om te kijken wat de AI wil aanpassen, of of dit niet intended is.

[xoniq]

Je ziet het al een klein beetje met bijvoorbeeld Microsoft die al aan het dimmen is

Is dat zo? Ze hebben niks afgeremd. Ze hebben alleen aangegeven de doorvoer van AI in Windows minder opzichtig te maken omdat ze merken dat er steeds meer weerstand komt van de Windows gebruikers en men steeds meer bereid is alternatieven te zoeken.

Er is niks gerept over verwijderen / minderen van daadwerkelijke AI.

[Skit3000]

Wat is het probleem bij een bugmelding als die feitelijk correct is, of die nu door AI of een mens is gevonden? Hoe meer hoe beter lijkt mij zelfs, al moet je dan inderdaad wel meer tijd stoppen in uitvogelen welke bugs het belangrijkste zijn om snel te verhelpen.

Krijg je consistent AI-gegenereerde bugmeldingen die niet kloppen, zou je natuurlijk een soort van "three strikes and you are out"-principe toe kunnen passen en niet meer naar bugs van die melder kunnen kijken (of pas op een later moment), maar dat hoeft geen samenwerkingsverband tussen alle genoemde grote softwarepartijen van 12 miljoen te zijn.

[Reactie gewijzigd door Skit3000 op 19 maart 2026 13:36]

[_FlasH_]

De meest simpele oplossing lijkt me een financiële drempel inbouwen voor het doen van een melding. In de orde van grootte van 1 euro bijvoorbeeld. Houdt de spammers buiten en is minimaal voor de goedwillende.