GitHub Package Firewall: verificări npm înainte de instalare

GitHub a prezentat un package firewall pentru npm: o verificare care compară fiecare pachet cu politica firmei înainte să fie instalat și blochează malware cunoscut, vulnerabilități critice și versiuni publicate de prea puțin timp. Au scris despre el heise Security pe 23 octombrie, Help Net Security pe 28 și The Hacker News pe 29 octombrie 2026. Detaliile tehnice de mai jos provin de la Help Net Security, care a obținut și răspunsurile a doi responsabili de produs de la GitHub.

Firewall-ul este una dintre cele patru noutăți de securitate pe care GitHub le leagă de creșterea software-ului scris cu ajutorul agenților IA. Obiectivul declarat este ca problemele să fie oprite înainte ca un pachet să ajungă pe laptopul unui dezvoltator, într-un build sau în mediul unui agent de programare.

Cum funcționează firewall-ul

Potrivit Help Net Security:

• verificarea are loc în momentul instalării, comparând pachetul cerut cu o politică definită la nivel de enterprise;
• criteriile de blocare sunt trei: malware cunoscut, vulnerabilități critice și versiuni abia publicate;
• orice dezvoltator îl poate activa îndreptând npm spre firewall: în practică, pachetele nu mai vin direct din registru, ci trec prin filtru.

Ca să decidă dacă o versiune este „prea nouă”, a explicat Adam Leftik de la GitHub, firewall-ul folosește data lansării din metadatele pachetului, care este responsabilitatea managerului de pachete. Firmele pot modifica regulile și pot crea politici personalizate cu o perioadă de așteptare (soak time sau cool-down) înainte ca o versiune nouă să poată fi instalată.

Sursele disponibile nu descriu configurarea exactă, disponibilitatea pe diferitele planuri GitHub și nici eventualele licențe necesare și vorbesc doar despre npm.

De ce contează perioada de așteptare

În lectura noastră, criteriul privind versiunile noi este cel mai interesant. O versiune malițioasă a unui pachet legitim, publicată cu credențiale furate sau profitând de o slăbiciune a procesului de publicare (ca în cazul SlugFest din npm Trusted Publishing, din această lună), este cea mai periculoasă în primele ore și zile, înainte să fie semnalată și retrasă. O perioadă de așteptare micșorează această fereastră; blocarea malware-ului cunoscut acoperă versiunile deja identificate. Tehnica MITRE ATT&CK de referință este T1195.001 (Compromise Software Dependencies and Development Tools).

Câteva limite de avut în vedere, tot în lectura noastră:

• filtrul protejează doar instalările care trec prin firewall: o stație de lucru, un job de CI sau un agent configurate altfel îl ocolesc;
• perioada de așteptare întârzie și corecțiile de securitate urgente, pentru care e nevoie de o procedură de excepție;
• criteriul privind versiunile noi depinde de corectitudinea datelor din metadate, după cum precizează chiar GitHub.

Celelalte noutăți anunțate

Help Net Security descrie și celelalte trei noutăți, care lucrează pe cod și pe alerte:

• AI Scan analizează fiecare pull request în căutarea vulnerabilităților în limbajele pe care scanarea bazată pe reguli nu le acoperă, printre care PHP, Shell și COBOL. Poate analiza la cerere și un întreg repository, ajungând la codul deja unit;
• extensia GitHub Security pentru aplicația Copilot verifică modificările dezvoltatorului înainte să existe un pull request; împreună cu GitHub Code Security aduce în aplicație alertele de code scanning, inclusiv cele din AI Scan;
• analiza de accesibilitate (reachability) pentru alertele Dependabot verifică dacă codul apelează efectiv funcția vulnerabilă a unei dependențe: calea de apel se poate consulta în GitHub, iar alertele se pot ordona în funcție de ea.

Pentru corecții, Pierre Tempel de la GitHub a amintit atât sugestiile de corecție din pull request-uri, cât și Agentic Autofix, care rezolvă alertele în bloc în toate instrumentele GitHub și în peste 70 de instrumente ale partenerilor.

Impactul pentru firmele europene și italiene

npm este registrul de referință pentru JavaScript și TypeScript și alimentează aplicații web, instrumente de dezvoltare și pipeline-uri de build în majoritatea firmelor care dezvoltă software. Un pachet compromis execută cod pe stațiile dezvoltatorilor și pe runner-ele de CI, unde se află token-uri, chei și acces la sistemele de producție. Agenții IA de programare cresc numărul instalărilor făcute fără o verificare umană.

Pentru entitățile supuse NIS2, securitatea lanțului de aprovizionare și a dezvoltării se numără printre măsurile cerute: un filtru cu reguli scrise, aplicat în momentul instalării, este o măsură concretă și documentabilă, cu condiția să acopere cu adevărat toate punctele din care se instalează pachete.

Ce ai de făcut acum

1. Dacă folosești GitHub Enterprise, verifică în documentația GitHub disponibilitatea și cerințele package firewall-ului pentru planul tău: sursele nu le menționează.
2. Definește politica: blocarea malware-ului cunoscut și a vulnerabilităților critice, o perioadă de așteptare pentru versiunile noi și o procedură de excepție, cu un responsabil, pentru patch-urile de securitate urgente.
3. Fă obligatorie trecerea prin firewall: setează configurația npm centralizat în repository-uri, în runner-ele de CI, în imaginile containerelor și în mediile agenților IA. Unde se poate, împiedică rețelele de build să acceseze direct registrul public, ca filtrul să nu poată fi ocolit.
4. Păstrează apărările de bază: versiuni fixate cu fișierul de lock, instalări cu npm ci în pipeline-uri și, unde se poate, scripturi de instalare dezactivate (--ignore-scripts).
5. Folosește analiza de accesibilitate pentru priorități, nu pentru a închide alerte: o dependență vulnerabilă care nu e apelată azi poate fi apelată mâine.

Cum ajută ARXDOME

ARX Sentry colectează inventarul de software și procese al computerelor și serverelor: te ajută să afli unde rulează Node.js, npm și agenții de programare și, deci, ce mașini trebuie să respecte politica. ARX Shield arată vulnerabilitățile deschise pe mașină și pe pachet și, dacă o mașină a instalat o versiune suspectă, îți permite să o izolezi de rețea până la încheierea verificărilor.

Ultima actualizare: 29 octombrie 2026