Stenberg tog bort pengarna, inte maskinerna

Daniel Stenberg stängde curls buggbelöning på grund av vad pengarna drog till sig, inte på grund av vad som skrev rapporterna. Den 31 januari 2026 avslutade han ett program som hade pågått sedan april 2019, hade bekräftat 87 äkta sårbarheter och hade betalat ut över 100 000 dollar. Skälet var ett sammanbrott i träffprocenten. Före 2024 visade sig mer än 15 procent av inskickade rapporter vara verkliga säkerhetsproblem. Under 2025 föll det under 5 procent, vilket med hans egna ord innebar att inte ens en av tjugo var äkta. Ett frivilligt lag på sju personer lade timmar på att motbevisa var och en av dem, ett arbete han beskrev som en allvarlig mental påfrestning.

Hans egen förklaring förtjänar en noggrann läsning. Huvudsyftet med nedläggningen, skrev han, var att ta bort drivkraften att skicka in dåligt undersökt skräp. Lägg märke till vad den meningen inte säger. Den nämner ingen teknik och föreslår inte att någon ska upptäckas. Den pekar ut en utbetalning som det som belönade dåligt arbete, och avskaffar utbetalningen. Hans måttstock för rapportörer är lika oberoende av verktyget: man bör aldrig rapportera en sårbarhet om man inte verkligen förstår den och kan återskapa den.

Volymen fördubblades och träffprocenten tredubblades

Utfallet gick tvärtemot den självklara förutsägelsen. Att sluta betala tömde inte kön. I april 2026, efter att curl återgått till obetald rapportering, kom rapporterna in i ungefär dubbelt så hög takt som 2025, och 15 till 16 procent av dem bekräftades som äkta sårbarheter. Antalet bekräftade fynd passerade nivån från 2024, alltså tiden före vågen.

Den viktigaste detaljen låter som en motsägelse. Nästan varje rapport verkade fortfarande vara AI-assisterad. Det som hade ändrats var att de flesta nu var bra. Skräpet var inte längre ett problem, rapporterade Stenberg i april. Verktyget lämnade inte kön. Det gjorde skräpet.

Läst som ett styrproblem var belöningen ett filter riktat mot fel mål. En kontant belöning för ett godkänt fynd betalas ut efter inskickad volym gånger tur, och belönar därför snabb och hoppfull inskickning framför föregående kontroll. Det trycket fanns redan före generativa modeller och var då bara uthärdligt; billig generering gjorde det dödligt. Omfattningen syns även på annat håll. Hos Bugcrowd mer än fyrdubblades rapportvolymen under tre veckor i mars. HackerOne noterade fram till mars en ökning av inskickade rapporter med 76 procent på ett år, även om andelen som pekade ut äkta sårbarheter på den plattformen låg stabilt kring 25 procent, vilket nyanserar bilden av att alla köer rasade samtidigt.

I själva verket har ingen förbjudit någonting

Den enda räkning som faktiskt räknade hittade noll regelrätta förbud. En fullständigt genomräknad studie av 53 rapporteringsprogram, som omfattade fyra samordningsplattformar, 20 tillverkare och 29 projekt med öppen källkod, hämtades den 28 juli 2026. Inte ett enda förbjuder rakt av AI-skrivna buggrapporter. Det ofta upprepade påståendet att branschen har förbjudit dem beskriver en regel som inget program i urvalet någonsin har skrivit ned.

Den verkliga fördelningen är mindre dramatisk och mer användbar. Trettiosex program, 67,9 procent, säger ingenting om AI i sina publicerade policyer. Sexton, 30,2 procent, reglerar det med villkor. Av dessa sexton kräver tretton mänsklig verifiering av fyndet, elva kräver en fungerande reproduktion, åtta avvisar helt autonoma inskickningar men tillåter fortfarande AI-stöd, och tre kräver att användningen av AI redovisas: Intigriti, Django och FFmpeg. Mänsklig verifiering, inte förbud, är den standard alla rör sig mot.

Räkningen hittade dessutom en brist värd att anteckna. Tre program publicerade sina AI-regler någon annanstans än på själva policysidan. Ett villkor som den rapporterande aldrig sett och aldrig godkänt kan inte göras gällande mot honom eller henne, vilket reducerar en skriven regel till dekoration. Inte heller de program som bytte status förbjöd något: curl stängde sin belöning i januari 2026, Nextcloud pausade betalda belöningar i april, och Internet Bug Bounty pausade inskickningarna.

Apple och GitHub gick på personen

Apples riktlinjer knyter numera sanktionen till rapportörens anseende, inte till rapporten. Apple slår utan omsvep fast att företaget tar emot många rapporter som utger sig för att gälla allvarliga säkerhets- eller integritetsproblem men som är framställda av språkmodeller och inlämnade utan det bevis som krävs eller validering av en människa. Motmedlet är en avstängning. Den som upprepade gånger skickar in rapporter som inte kan behandlas, däribland ogenomförbara om teoretiska frågor eller sådana som hittats av AI utan ordentlig validering, kan få sina rapporter liggande obehandlade i 180 dagar. Vid fler än två sådana perioder kan personen tas bort permanent från programmet.

Den andra halvan av den sanktionen skär djupare. Under en avstängning är den berörda utestängd inte bara från betalning utan också från omnämnande i säkerhetsmeddelanden, och för en yrkesverksam säkerhetsforskare är offentligt erkännande den varaktiga valutan. Apples användarvillkor når samma punkt från ett annat håll och förbjuder ett ihållande, upprepat eller volymmässigt stort mönster av oriktiga påståenden, såsom rapporter framställda med hjälp av AI och inte validerade genom mänsklig granskning. Det avgörande är den sista delen. Villkoret förbjuder inte hjälpen, det förbjuder att lämna ifrån sig resultatet okontrollerat.

GitHub valde den andra vägen via identiteten och delade programmet i två nivåer med verkan från den 27 juli 2026. De offentliga belöningarna sänktes till 250 dollar för ett fynd av låg allvarlighetsgrad, 2 000 för medel, 5 000 för hög och 10 000 för kritisk, mot tidigare 500 till 1 000, 5 000, 20 000 och 30 000. De gamla nivåerna lever nu vidare i ett skikt man blir inbjuden till och som betalar 1 000, 7 500, 20 000 och 30 000 dollar eller mer. Tillträde kräver en styrkt meritlista: ett godkänt kritiskt fynd, eller två höga, eller fyra medel, eller sju låga. Nya rapportörer i det offentliga programmet möter ett signalkrav med upp till fyra första inskickningar för att visa vad de går för. Det uttalade syftet, enligt produktsäkerhetsingenjören Catherine Cassell, är att dämpa bruset så att laget kan koncentrera sig på signalen.

Den ni bromsar kan vara just den som betyder något

Att filtrera på anseende har ett pris som ingen av dessa kungörelser räknar på. Var och en av dessa konstruktioner belönar en befintlig meritlista, vilket är ett förnuftigt sätt att rangordna dem som rapporterar ofta. Men den person som hittar ett enda kritiskt fel i er produkt och aldrig tidigare lämnat in en rapport någonstans är per definition profilen helt utan meritlista, och det är just den rapporten ni minst av allt vill bromsa. GitHubs svar är fyra inskickningar för att visa signal, Apples är en status som kan ligga stilla ett halvår. Båda går att försvara, ingen av dem är gratis, och kostnaden faller precis på den som hittar något en enda gång och vars enda rapport kan vara årets mest värdefulla.

För en europeisk tillverkare upphör frågan att vara filosofisk den 11 september 2026, när rapporteringsskyldigheterna i förordningen om cyberresiliens börjar gälla. En tillverkare som får kännedom om att en sårbarhet i produkten utnyttjas aktivt ska underrätta ENISA och den behöriga nationella CSIRT-funktionen inom 24 timmar, lämna en mer fullständig bedömning inom 72 timmar och ge in en slutrapport senast 14 dagar efter att en avhjälpande åtgärd finns tillgänglig. I Sverige är ingången CERT-SE hos MSB. Förordningen kräver dessutom en policy för samordnat röjande av sårbarheter, alltså en ordnad väg längs vilken någon kan varna er innan detaljerna blir offentliga. Läser man fristen noga blir inkorgsproblemet ett efterlevnadsproblem. Klockan startar vid kännedomen, och en kö begravd under ovaliderade rapporter är en maskin för att fördröja just den kännedomen.

Av detta följer tre saker för var och en som driver en sådan ingång. Kräv en fungerande reproduktion och skriv det på den sida den rapporterande godkänner, för en reproduktion går att bevisa medan ett påstående om vilket verktyg som skrev texten inte gör det. Åtgärda drivkraften innan ni skriver en regel, eftersom curls kö blev bättre när utbetalningen försvann, inte när en policy ändrades. Och mät andelen bekräftade fynd i stället för antalet rapporter, för volymen är just det tal som steg i det enda fall där allt blev bättre. Ingenting i förordningen om cyberresiliens tvingar er att betala en enda rapportör. Den tvingar er att gå att nå och att kunna skilja en äkta rapport från en trovärdig tillräckligt snabbt för att starta klockan i tid.