Noul firewall npm de la GitHub blochează pachetele riscante înainte de instalare

Fiecare npm install este un mic act de încredere. Un build descarcă sute de pachete dintr-un registru public, rulează orice scripturi de ciclu de viață vin la pachet și nimeni nu citește codul înainte. GitHub oferă acum o modalitate de a pune un punct de control de politică în fața acestui moment: un firewall pentru pachete, lansat în previzualizare publică, care inspectează cererile de metadate și descărcările npm și refuză tot ce încalcă regulile stabilite de organizație.

Ce s-a întâmplat

Firewall-ul este disponibil în previzualizare publică pentru clienții GitHub Enterprise Cloud, inclusiv pentru implementările cu date rezidente. Deocamdată funcționează doar cu npm; alte ecosisteme sunt așteptate să urmeze.

Arhitectural, este o poartă plasată între endpoint-urile sau registrele interne ale organizației și registrul public din amonte. Laptopurile dezvoltatorilor, serverele CI/CD și agenții autonomi de programare își îndreaptă managerul de pachete către firewall, nu direct către registru. Fiecare cerere este verificată față de politică, iar descărcările care nu trec sunt blocate în momentul instalării, nu descoperite mai târziu.

Administratorii trebuie să configureze singuri controalele de politică. Setul actual acoperă cinci verificări:

• Malware cunoscut. Pachetele care au un aviz activ de malware în baza de avize GitHub sunt respinse direct.
• Prag de severitate. Versiunile afectate de o vulnerabilitate publicată la sau peste un nivel ales sunt blocate. Implicit este „doar Critical”, cu opțiunile „High sau mai sus”, „Medium sau mai sus” și „orice severitate”.
• Retrogradări de atestare. Atestarea de proveniență SLSA a versiunii cerute este comparată cu versiunile anterioare. Dacă un pachet care livra proveniență semnată încetează brusc să o facă, descărcarea este oprită. Tiparul este un semnal puternic de pipeline de publicare compromis.
• Scripturi de instalare nou introduse. Versiunile care adaugă hook-uri preinstall, install sau postinstall acolo unde versiunile anterioare nu aveau sunt blocate. Scripturile de instalare execută cod arbitrar și rămân mecanismul preferat de livrare pentru pachetele care fură credențiale.
• Vârsta minimă a pachetului. O perioadă de așteptare care refuză versiunile mai noi decât un număr configurat de zile. Intervalul este 1–365 de zile, implicit o zi, iar valoarea zero dezactivează verificarea.

Dezvoltatorii care dau peste un fals pozitiv, sau care chiar au nevoie de o versiune aflată încă în perioada de așteptare, pot depune o cerere de excepție cu o justificare, pe care administratorii și managerii de securitate ai organizației o aprobă sau o resping.

De ce contează

Momentul instalării este locul în care atacurile moderne asupra lanțului de aprovizionare reușesc cu adevărat. Tiparul tipic este preluarea contului unui mentenant, urmată de o versiune otrăvită cu un script postinstall care colectează tokenuri, chei cloud și fișiere .npmrc în câteva minute de la publicare. Până când registrul elimină versiunea, mii de build-uri au rulat-o deja.

Două tendințe agravează fereastra. Runnerele CI instalează dependențe la fiecare rulare a pipeline-ului fără niciun om în buclă, iar agenții AI de programare adaugă și actualizează acum pachete pe cont propriu pentru a-și termina sarcina. Niciunul nu citește diferența din lockfile înainte să descarce o versiune veche de câteva ore.

De aceea perioadele de așteptare se răspândesc în toate ecosistemele. În ultimul an npm, PyPI, extensiile Visual Studio Code, RubyGems, Bun, pnpm și Yarn au introdus, într-o formă sau alta, o vârstă minimă a versiunilor. Rust li se alătură: versiunea 1.100, programată pentru 12 noiembrie 2026, adaugă o vârstă minimă de publicare configurabilă în fișierul de configurare Cargo, iar dacă nu se setează nimic, se aplică implicit o așteptare de șapte zile pentru versiunile de crate-uri.

Merită să fim sinceri în privința limitelor. O perioadă de așteptare întârzie remedierile legitime de securitate la fel de mult ca pe cele malițioase, dacă nu acordă cineva o excepție, iar codul malițios nu devine inofensiv odată cu vârsta. O versiune care scapă scanerelor pur și simplu supraviețuiește perioadei de așteptare. Ce cumpără întârzierea este timp: timp pentru cercetători, mentenanți și registre să depisteze și să retragă o versiune rea înainte ca următoarea actualizare de dependențe să o ducă mai departe.

Ce este de făcut

1. Dacă folosiți GitHub Enterprise Cloud, activați previzualizarea mai întâi într-o organizație necritică, îndreptați runnerele CI și agenții de programare către ea și ajustați pragul de severitate și perioada de așteptare înainte să extindeți implementarea.
2. Toți ceilalți, setați oricum o perioadă de așteptare. Majoritatea managerilor de pachete importanți expun acum o setare de vârstă minimă a versiunii. Una până la trei zile sunt suficiente pentru a prinde majoritatea versiunilor deturnate fără a paraliza viteza de lucru.
3. Țineți sub control scripturile de ciclu de viață. Rulați instalările cu scripturile dezactivate oriunde permite stiva voastră și păstrați o listă explicită de permisiuni pentru puținele pachete care au nevoie legitimă de ele.
4. Comiteți și revizuiți lockfile-urile. Tratați o modificare de lockfile ca pe o modificare de cod, mai ales când a generat-o un agent automat. O dependență tranzitivă nouă sau un salt la o versiune veche de câteva ore merită o a doua privire.
5. Reduceți ce poate fura un script malițios. Folosiți tokenuri de registru de scurtă durată, doar cu citire, și credențiale cloud cu domeniu restrâns pe serverele de build, și nu lăsați niciodată secrete de lungă durată în variabile de mediu pe care un hook de instalare le poate citi.
6. Urmăriți semnalele de proveniență. O versiune care își pierde atestarea sau capătă un script de instalare este un motiv de pauză, nu o curiozitate.

Manifestele de dependențe, diferențele din lockfile, scripturile de ciclu de viață și proveniența a ceea ce descarcă un build sunt exact stratul pe care îl examinează revizuirea de cod asistată de AI din echipa noastră, astfel încât un pachet suspect este semnalat cât timp este încă un pull request, nu după ce a rulat pe un runner de producție.