Ti minutter fra delt patch til automatiserte angrepsforsøk

«I de første ti årene av rclone-prosjektet fikk vi rundt 20 sikkerhetsmeldinger gjennom GitHub. Vi har måttet håndtere over 40 den siste måneden», skriver rclone-vedlikeholder Nick Craig-Wood i Hacker News-tråden Simon Willison samler i lenkebloggen sin. Rundt 75 prosent av meldingene inneholder noe som faktisk må undersøkes, oppgir han.

Utgangspunktet er en rapport fra Anil Madhavapeddy, professor i informatikk ved Cambridge og kjernevedlikeholder av OCaml-kompilatoren. Han beskriver at sikkerhetsfeil i OCaml-prosjekter møter forsøk på utnyttelse i løpet av minutter etter at patcher deles til diskusjon. I hans eget tilfelle tok det rundt ti minutter før nettstedet fanget opp prober etter prosent-kodede traversal-sekvenser, altså nøyaktig den feilklassen patchen skulle tette. Automatiserte overvåkere følger med på offentlige repoer.

Madhavapeddy demonstrerte det samme med sine egne agenter. Claude Fable nektet oppgaven, så han byttet til DeepSeek V4 Pro og fikk den gjort. Konklusjonen hans er at oppdagelsestempoet ikke lenger er forenlig med embargo-praksisen open source har levd med, der noen dager til diskusjon og en utgivelse innen en uke eller to har vært normalen.

For vedlikeholdere flytter flaskehalsen seg fra å finne feilen til å rekke gjennom triage og utgivelse.

«Før KI-apokalypsen tok en CVE-tildeling to til tre dager. Nå ligger de på tre til fire uker, så jeg må sende ut punktutgivelser med CVE-PENDING i endringsloggen.» — Nick Craig-Wood, vedlikeholder av rclone

Hva bør du gjøre?

1. Behandle en delt patch som offentlig informasjon. Planlegg utrullingen som om lekkasjen skjer i samme øyeblikk som diagnosen deles.
2. Følg med på punktutgivelser merket CVE-PENDING i endringsloggen. Ventetiden på tildeling gjør at nummeret nå kommer lenge etter fiksen.
3. Automatiser førstelinjen i triagen hvis du vedlikeholder open source. Craig-Wood bruker KI-verktøy til nettopp triage og til å foreslå fikser for gjennomlesing.