GitHub ograničava rok za npm trusted publishing konfiguracije

GitHub je uveo isticanje nepotvrđenih npm konfiguracija za trusted publishing 48 sati nakon kreiranja, pošto je Bloom Security identifikovao više od 1.500 paketa izloženih mogućem preuzimanju. Ti paketi su zajedno preuzeti više od 10 miliona puta. Konfiguracija postaje potvrđena posle prvog uspešnog objavljivanja paketa, kada se veza uspostavlja sa nepromenljivim identitetom repozitorijuma.

Problem je bio vezivanje poverenja za naziv repozitorijuma

Trusted publishing je npm uveo u julu 2025. kao način objavljivanja paketa bez dugotrajnih tajni. CI/CD platforma, poput GitHub Actionsa, za konkretno izvršavanje radnog toka izdaje kratkotrajni OIDC token, a npm ga proverava u odnosu na unapred odobrenu konfiguraciju. Takav pristup smanjuje potrebu za čuvanjem, rotacijom i ručnim upravljanjem trajnim akreditivima.

Bloom Security je, međutim, utvrdio da je npm do prvog uspešnog objavljivanja poverenje zasnivao na GitHub slug-u, odnosno kombinaciji vlasnika i naziva repozitorijuma u obliku owner/repository. Numerički ID repozitorijuma, koji ostaje isti pri preimenovanju i prenosu, nalazi se u GitHub OIDC tokenima, ali ga npm u toj početnoj fazi nije koristio.

Ako se repozitorijum preimenuje, prenese ili obriše, njegov raniji slug može postati dostupan drugom nalogu. Napadač tada može napraviti repozitorijum pod oslobođenim nazivom, pokrenuti tok objavljivanja i dobiti vremenski ograničen token za objavu paketa koji ne poseduje. Ova tehnika, koju su istraživači nazvali SlugFest, omogućava objavljivanje zlonamerne verzije pod legitimnim imenom paketa, sa postojećom reputacijom, brojem preuzimanja i zavisnostima.

Promena ograničava početni period rizika

GitHub navodi da nova konfiguracija mora imati prvo uspešno objavljivanje u roku od dva dana. Time se konfiguracija potvrđuje i vezuje za nepromenljivi identitet repozitorijuma. Promena repozitorijuma ili identiteta projekta pokreće novu vezu poverenja i novi rok od 48 sati, dok obične izmene ne resetuju rok.

Uz to, npm ubuduće odbacuje tokene za trusted publishing koji potiču iz GitHub Actions događaja issue_comment. Ograničenje se pridružuje postojećoj zabrani za pull_request_target događaj.

Šta treba proveriti u razvojnim timovima

Održavaoci npm paketa treba da pregledaju veze sa trusted publisherom i provere da li navedeni slug i dalje vodi do repozitorijuma pod njihovom kontrolom. Posle preimenovanja ili prenosa repozitorijuma potrebno je obrisati staru vezu poverenja i napraviti novu sa aktuelnim slug-om.

Praktičan poslovni zaključak je da se promene vlasništva, naziva i životnog ciklusa repozitorijuma moraju tretirati kao bezbednosni događaji: veze poverenja treba ukloniti pri brisanju, prenosu ili preimenovanju, a neočekivana npm objavljivanja redovno nadzirati.