Pachete npm rău intenționate în ecosistemul React Native

Acasă » Piton » Pachete npm rău intenționate în ecosistemul React Native

React Native a devenit un framework de referință pentru construirea de aplicații mobile, ceea ce face ca ecosistemul său npm să fie o țintă extrem de atractivă pentru atacatorii care doresc să compromită mașinile dezvoltatorilor și conductele de CI. În ultimii ani, mai multe campanii extrem de sofisticate au abuzat de pachete React Native de încredere, de instrumente populare în jurul framework-ului și chiar de utilitare typosquattate pentru a instala programe malware, a fura acreditări, a exfiltra portofele și a sabota proiecte JavaScript la scară largă.

Dacă construiești sau întreții aplicații React Native astăzi, nu mai este suficient să „instalezi npm și să speri la ce e mai bun”. Mai mulți actori amenințători abuzează sistematic de npm, vizând totul, de la componentele UI la instrumentele CLI și chiar și graful de dependențe tranzitive care se ascunde adânc în fișierele de blocare. Acest articol trece în revistă principalele incidente cunoscute, analizează modul în care funcționează malware-ul și prezintă pași pragmatici pe care îi puteți lua pentru a reduce raza de explozie în propriul mediu de dezvoltare.

Preluarea controlului asupra contului și programe malware în componentele de intrare React Native

Unul dintre cele mai alarmante incidente ale lanțului de aprovizionare din lumea React Native a afectat două componente foarte comune ale interfeței utilizator pentru selectarea telefonului și a țării: react-native-international-phone-number și react-native-country-select. Ambele pachete, întreținute de același autor (@AstrOOnauta, utilizator npm astroonauta), au acumulat zeci de mii de descărcări săptămânale și sunt încorporate în multe aplicații mobile de producție.

Pe 16 martie 2026, analistul de pachete bazat pe inteligență artificială de la StepSecurity a fost primul care a observat că noile versiuni ale acestor biblioteci au fost infectate brusc cu programe malware în timpul instalării. Versiunile compromise imediat au fost react-native-international-phone-number@0.11.8 și react-native-country-select@0.3.91Ultimele versiuni curate confirmate până la acel moment au fost 0.11.7 și 0.3.9 respectiv.

Ușa din spate inițială (Valul 1) a fost brutal de simplă: o nouă preinstall scenariu și un puternic ofuscat install.js fișier inclus în arhiva tar. Cel rău intenționat package.json fragmentul arăta așa:

"scripts": { "preinstall": "node install.js" }

Deoarece scripturile ciclului de viață npm rulează automat pe npm installoricine a descărcat aceste versiuni – local sau în CI – a rulat malware-ul fără a importa niciun cod. Nu existau etichete Git, versiuni sau rulări de fluxuri de lucru CI corespunzătoare pentru versiunile compromise, iar gitHead se potrivea cu versiunea anterioară bună, un indicator puternic că atacatorul a obținut acces direct de publicare la contul npm al administratorului în loc să modifice depozitul GitHub.

Datele despre descărcări din acea perioadă subliniază cât de gravă ar fi putut fi situația: aproximativ 9,000 de descărcări săptămânale pentru react-native-country-select și peste 20,000 pentru react-native-international-phone-number, însumând peste 130,000 de descărcări pe lună între cele două. Acesta este exact genul de dependență de volum mare și vizibilitate redusă care se instalează în tăcere pe mii de dezvoltatori și mașini de integrare continuă.

Atac în trei valuri: de la preinstalare evidentă la lanțuri de dependențe ascunse

Campania împotriva acestor pachete React Native s-a desfășurat în trei valuri distincte, fiecare iterație mai evazivă decât precedenta, reutilizând același malware de bază. StepSecurity a urmărit evoluția aproape în timp real și s-a coordonat cu administratorul, dar atacatorul a recâștigat sau a păstrat în mod repetat accesul la contul npm compromis.

Valul 1 (16 martie 2026) s-a concentrat pe direcția preinstall agățați ambele pachete. În aproximativ cinci minute de la publicare, inteligența artificială a StepSecurity a marcat noile versiuni ca fiind critice, iar problemele au fost deschise pe GitHub: #165 pentru react-native-international-phone-number și #11 pentru react-native-country-selectResponsabilul a răspuns rapid, dezaprobând versiunile rău intenționate și lansând o versiune curată. react-native-country-select@0.4.0Timpul total de la publicare până la depreciere a fost de aproximativ 2 ore și 21 de minute – rapid conform standardelor ecosistemului.

În ciuda acestui fapt, atacatorul nu a pierdut niciodată controlul asupra acreditărilor npm, ceea ce a dus la Wave 2 pe 17 martie. În loc să includă din nou un script evident în pachetele principale, actorul amenințător a implementat două noi pachete cu scop specific pentru a acționa ca infrastructură ascunsă:

• @usebioerhold8733/s-format@2.0.1 – o clonă goală a string-format cu postinstall: "node init.js" scenariu, dar lipsește init.js fișier, astfel încât hook-ul eșuează în tăcere.
• @agnoliaarisian7180/string-argv@0.3.0 – un pachet aproape gol (README, LICENSE, package.json) al cărui singur scop real era să depindă de @usebioerhold8733/s-format, cu o adresă de mentenanță bazată pe ProtonMail.

Mai târziu în acea seară, react-native-international-phone-number@0.12.1 a fost publicat cu @agnoliaarisian7180/string-argv@0.3.0 adăugat ca o nouă dependență, din nou fără nicio activitate GitHub Actions. În acel moment, lanțul era deja pus în scenă, dar inert, așteptând ca sarcina utilă să fie pornită. Când StepSecurity a raportat anomalia, administratorul a confirmat ceea ce era deja evident din artefacte: „contul meu npm a fost atacat, iar biblioteca a fost preluată”.

Valul 3 (18 martie) a transformat infrastructura etapizată într-un lanț activ de distribuție a programelor malware pe mai multe niveluri, pe care apoi l-a rafinat în succesiune rapidă. Noile versiuni atât ale pachetelor de relay, cât și ale bibliotecii principale au fost lansate în mai puțin de o oră, atacatorul iterând modul în care a fost lansată sarcina utilă.

Lanțul final arăta astfel:

react-native-international-phone-number@0.12.2/0.12.3 → @agnoliaarisian7180/string-argv@latest → @usebioerhold8733/s-format@latest → postinstall → node child.js → init.js (malware)

Atacatorul a activat mai întâi sarcina utilă în @usebioerhold8733/s-format@2.0.2 prin adăugarea unui mesaj mare, ofuscat init.js fișier care era identic octet cu octet cu precedentul install.js din Valul 1. Apoi au schimbat postinstall a apela child.js în loc de init.js, publicat 2.0.3 cu scriptul lipsă (încă o încercare preliminară) și în final expediat 2.0.4 cu un mic child.js încărcător care verifică pur și simplu init.js și îl execută prin intermediul child_process.exec în timp ce elimină erorile și ieșirea stderr.

In acelasi timp, @agnoliaarisian7180/string-argv@0.3.1 și-a schimbat dependența de s-format de la o versiune fixată la "latest" și react-native-international-phone-number@0.12.2 a facut acelasi lucru cu string-argv. Aceasta a creat un lanț de programe malițioase cu auto-actualizare, în care fiecare instalare a pachetului principal extragea automat cea mai nouă versiune a payload-ului.

În cele din urmă, react-native-international-phone-number@0.12.3 a eliminat hook-ul de preinstalare, acum inutil (pentru a arăta mai curat), a păstrat lanțul de dependențe malițioase și a schimbat adresa de e-mail a administratorului npm cu încă un cont ProtonMail care nu este deținut de autorul original. Acesta a fost un semn clar că atacatorul își consolida controlul persistent asupra identității npm, nu doar reutiliza în mod oportunist un token scurs.

În interiorul malware-ului susținut de Solana care vizează dezvoltatorii React Native

Sub capotă, sarcina utilă care rula în toate cele trei valuri era același malware sofisticat în mai multe etape care abuzează de blockchain-ul Solana ca un canal dinamic de comandă și control. Mecanismul de livrare s-a schimbat încontinuu, dar „arma” a rămas identică în toate iterațiile, până la a fi același fișier, octet cu octet, atunci când a fost transplantat din Wave 1 în infrastructura Wave 3.

Scenariul începe cu o întârziere deliberată de 10 secunde folosind setTimeout, un truc clasic de evitare a situațiilor cu nisip. Multe sandbox-uri automate și instrumente de securitate oferă scripturilor doar o scurtă fereastră de execuție înainte de a decide că nu s-a întâmplat nimic suspect, așa că malware-ul pur și simplu le așteaptă înainte de a face ceva interesant.

Apoi, efectuează un geofiltru pentru a evita infectarea sistemelor din Rusia și din anumite părți ale CSI. Inspectează variabilele de mediu, cum ar fi LANG, LANGUAGE, LC_ALL, informații despre utilizatorul gazdă, fusul orar al sistemului și chiar decalaje UTC brute, căutând valori care indică o locație rusească (cum ar fi ru_RU or Russian) sau unul dintr-o listă de fusuri orare din Rusia/CSI. Dacă oricare dintre acestea se potrivește, scriptul se închide imediat și silențios.

Numai dacă mediul trece de această verificare, malware-ul începe să comunice cu blockchain-ul Solana. Acesta deține o adresă de portofel codificată fix și o interoghează prin intermediul getSignaturesForAddress Metoda JSON-RPC pe nouă endpoint-uri Solana RPC diferite, găzduite de diverși furnizori. Acest design oferă atacatorului disponibilitate ridicată și face ca blocarea simplă a domeniului sau a adresei IP să fie ineficientă.

Trucul este că atacatorul ascunde adresa URL a sarcinii utile din etapa următoare în câmpul memo al tranzacțiilor Solana către portofelul respectiv. Memo-ul stochează o cantitate de fișiere JSON codificate în base64, a căror link Câmpul conține adresa URL a etapei următoare. Prin postarea unei noi tranzacții, operatorul poate roti adresa URL a sarcinii utile în orice moment, fără a modifica pachetele npm publicate.

Odată ce URL-ul este extras, malware-ul efectuează o cerere HTTP către serverul atacatorului la http://45.32.150.251/, trimițând tipul sistemului de operare într-un fișier personalizat os antet, astfel încât C2 să poată returna fișiere binare specifice platformei. Corpul răspunsului conține sarcina utilă criptată, dar cheia AES-256 și IV-ul necesare pentru decriptarea acesteia sunt trimise doar în anteturile HTTP (secretkey și ivbase64), deci orice date corporale stocate în cache sau interceptate sunt inutile în sine.

A doua etapă decriptată nu atinge niciodată discul; este executată în memorie cu eval(atob(...)) pe sisteme de tip Unix sau prin intermediul vm.Script pe Windows cu acces complet la componentele interne ale Node. Ulterior, malware-ul lansează un ~/init.json fișier marker care stochează o marcă temporală și un identificator unic, astfel încât aceeași mașină să nu fie reinfectată de mai mult de o dată la 48 de ore. Această limitare a ratei reduce dramatic zgomotul și oferă apărătorilor mai puțini indicatori comportamentali de care să se agațe.

Sarcina utilă decriptată prin AES în a treia etapă, recuperată de cercetători prin repetarea acelorași pași Solana și HTTP, este un instrument de furt de credențiale și portofele, plus un încărcător, centrat pe Windows. Stabilește persistența cu schtasks si Run cheie de registry, descarcă module criptate suplimentare din 45.32.150.251și exfiltrează prada rezultată către o adresă IP din intervalul 217.69.3.x.

Această sarcină utilă caută date din portofelele desktop și extensiile de browser, cum ar fi MetaMask, Phantom, Exodus, Atomic, Guarda, Coinomi, Daedalus, OKX Wallet, Trust Wallet, Braavos și multe altele, parcurgând folderele profilului browserului și directoarele portofelelor locale după închiderea forțată a Chrome și Firefox. În plus, extrage token-uri npm și acreditări GitHub direct din configurația locală și din instrumentele de asistență pentru acreditări, transformând modulele de dezvoltare compromise în rampe de lansare perfecte pentru atacuri ulterioare asupra lanțului de aprovizionare.

În special, malware-ul chiar își descarcă propriile runtime-uri Node.js (v22.9.0) atât pentru x86, cât și pentru x64 în %APPDATA%\_node_x86 și %APPDATA%\_node_x64, asigurându-se că are un mediu de execuție consistent chiar și atunci când Node nu este instalat pe sistemul țintă.

Linkuri către ForceMemo și actorul amenințător GlassWorm

Amprenta tehnică a acestui incident React Native npm se aliniază aproape perfect cu o campanie anterioară numită „ForceMemo”, care a compromis sute de depozite Python pe GitHub. Ambele operațiuni au folosit Solana ca punct de dead-drop C2, același grup de nouă puncte finale RPC, același format de memo JSON cu un link câmp, logică identică de geofiltrare Rusia/CSI, aceeași ~/init.json blocarea persistenței și chiar intervale de infrastructură similare găzduite pe Vultr.

Deși adresele portofelului Solana diferă între cele două campanii, totul indică un singur actor extrem de capabil, despre care se crede că este grupul cunoscut sub numele de GlassWorm. ForceMemo a vizat dezvoltatorii prin intermediul repozitoriilor GitHub otrăvite, în timp ce incidentul React Native a făcut acest lucru prin intermediul pachetelor npm și al lanțurilor lor de dependențe. Strategia este clară: reutilizarea unui framework de malware sofisticat și modular, dar conectarea acestuia la diferite canale de distribuție pentru a ajunge la cât mai multe medii de dezvoltare posibil.

Alte campanii npm rău intenționate legate de React Native și JavaScript

Compromisul AstrOOnauta este doar o parte dintr-un val mai amplu de atacuri bazate pe npm care afectează direct sau indirect aplicațiile React Native. Mai mulți furnizori de servicii de securitate au documentat campanii paralele axate pe bibliotecile React Native UI, instrumentele CLI de bază și chiar plugin-urile generice de compilare de care depind multe baze de cod React Native.

Aikido Security a descoperit o operațiune majoră în lanțul de aprovizionare în iunie 2025 care a furat prin backdoor cel puțin 16 pachete legate de React Native în cadrul... @react-native-aria/* domeniul de aplicare plus @gluestack-ui/utils, deservind împreună aproximativ un milion de descărcări săptămânale. Prima încălcare a avut loc pe 6 iunie 2025, începând cu @react-native-aria/focus@0.2.10, apoi s-a extins rapid la pachete suplimentare de tip focus, overlay, interaction, toggle, switch, checkbox, radio, button, menu, listbox, tabs, combobox, disclosure, slider, separator și utilitarele GlueStack pe 7 iunie.

Malware-ul din acea campanie era un troian de acces la distanță (RAT) adaptat mediilor Windows, persistând sub %LOCALAPPDATA%\Programs\Python\Python3127 și conectarea la serverele C2 la 136.0.9[.]8 și 85.239.62[.]36. Capacitățile sale includeau executarea arbitrară a comenzilor, încărcarea/descărcarea fișierelor și accesul de la distanță pe termen lung. Persistența însemna că simpla actualizare la o versiune curată a bibliotecii React Native nu curăța mașinile deja infectate.

O altă campanie de lungă durată, expusă de echipa de cercetare a amenințărilor Socket, a folosit typosquatting și mimetism pentru a instala pachete distructive care vizează în mod explicit framework-uri JavaScript populare, cum ar fi React, Vue, Vite și Quill. Actorul amenințător, folosind aliasul npm xuxingfeng, a publicat o combinație de pachete legitime și rău intenționate pe parcursul a mai bine de doi ani, creând impresia superficială că este un responsabil de încredere.

Pachete precum vite-plugin-bomb, vite-plugin-bomb-extend, vite-plugin-react-extend, vite-plugin-vue-extend și vue-plugin-bomb au fost concepute nu pentru a fura date, ci pentru a corupe sau distruge în mod activ proiecte. Au implementat atacuri multifazice declanșate de date specifice, ștergând fișiere critice ale cadrului de lucru din... node_modules (Vue, React, Vite, TypeScript, Ant Design Vue, Pinia, ECharts și altele), uneori asociate cu închideri forțate ale sistemului în fiecare secundă folosind shutdown -s -t 5.

Un pachet deosebit de urât, js-hood, a modificat prototipuri JavaScript de bază, cum ar fi Array.prototype.filter, map, push, pop și multiple String Metode, înlocuindu-le cu funcții care par valide din punct de vedere sintactic, dar returnează date aleatorii. Acest lucru duce la aplicații care continuă să ruleze, dar produc rezultate corupte, nedeterministe, extrem de greu de depanat.

quill-image-downloader Seria a mers într-o altă direcție, concentrându-se pe sabotajul stocării pe partea clientului. A livrat o arhitectură cu trei fișiere care, după o dată de activare specificată, iterează peste toate cheile din localStorage, sessionStorage și cookie-uri, apoi le amestecă parțial valorile cu caractere aleatorii, păstrând în același timp structura. Token-urile de autentificare, coșurile de cumpărături, preferințele utilizatorilor și orice stare din browser devin subtil corupte, provocând erori intermitente pe care multe echipe le-ar atribui inițial erorilor aplicației.

O cercetare separată a OP Innovate a descoperit un grup de zece pachete npm rău intenționate care au impersonat biblioteci cunoscute precum TypeScript, discord.js, ethers.js, nodemon, react-router-dom și zustand. Odată instalate, aceste pachete prezintă o fereastră CAPTCHA falsă, amprentează gazda și descarcă un infostealer multiplatformă de mare amploare de la un C2 la 195.133.79.43, din nou cu suport explicit pentru Windows, macOS și Linux.

În cele din urmă, campania CanisterWorm, detaliată de Aikido, a demonstrat cât de departe sunt dispuși să meargă atacatorii în exploatarea npm ca vehicul de livrare a informațiilor. Peste 135 de pachete dintr-un cont de editor compromis au fost folosite ca armă cu scripturi la instalare care se execută înainte de oricare dintre codul aplicației sau pașii de compilare. Etapele ulterioare se comportă diferit în funcție de situația în care ajung pe o casetă de dezvoltare locală, un job CI sau un nod de compilare containerizat și comunică cu un canister descentralizat Internet Computer (ICP) care funcționează ca un C2 stealth - permițând operatorilor să își schimbe comportamentul din mers fără a mai atinge vreodată registrul npm.

Vulnerabilități critice în instrumentele React Native: RCE-ul CLI al comunității

Nu toate riscurile de securitate React Native provin din pachete rău intenționate; unele provin din vulnerabilități grave ale instrumentelor utilizate pe scară largă. Un caz notabil este CVE-2025-11953 în interfața CLI a comunității React Native, un pachet extras de milioane de ori în fiecare săptămână de către dezvoltatori pe Windows, macOS și Linux.

Această problemă permitea execuția de cod la distanță (RCE) neautentificată prin intermediul unor cereri POST create special către serverul local de dezvoltare, pornite de CLI. Deoarece mulți dezvoltatori își expun serverele metro/dev în rețea pentru depanare sau testarea dispozitivelor mobile, un atacator din apropiere (sau cineva care poate direcționa traficul către acele porturi) ar putea rula comenzi arbitrare pe mașina dezvoltatorului.

Impactul depășește cu mult o singură stație de lucru pentru dezvoltatori: Odată ce un atacator execută cod pe o mașină de dezvoltare, acesta poate să se infiltreze în rețelele corporative, să extragă credențiale, să otrăvească versiunile sau să manipuleze conductele CI/CD care se sincronizează de pe acea mașină. Este un exemplu de manual despre cum „doar un instrument de dezvoltare local” face parte din suprafața de atac de producție atunci când lucrezi pe sisteme conectate la cloud.

Atenuarea recomandată este simplă, dar nenegociabilă: actualizarea la React Native Community CLI 12.5.1 sau o versiune ulterioară, jurnale de audit pentru cereri POST suspecte sau procese neașteptate declanșate de serverul de dezvoltare, restricționarea accesului la serverele locale și integrarea instrumentelor de dezvoltare în strategia de detectare a amenințărilor. Tratați orice endpoint DevOps sau de dezvoltare ca o țintă valoroasă, deoarece exact așa îl văd atacatorii moderni.

Cum au reacționat apărătorii: analiza inteligenței artificiale, perioadele de așteptare și CI consolidat

Partea bună a acestor povești este că comunitatea de securitate devine din ce în ce mai rapidă și mai sofisticată în detectarea amenințărilor la adresa lanțului de aprovizionare împotriva React Native și a spațiului JavaScript mai larg. Instrumente precum StepSecurity, Socket și Aikido Security investesc masiv în analiza comportamentală, compararea automată și modele de învățare automată care scanează noile versiuni npm în câteva minute de la publicare.

În atacul AstrOOnauta, analistul de pachete AI de la StepSecurity a detectat versiuni rău intenționate în mai puțin de cinci minute, a deschis problemele GitHub cu defalcări tehnice complete și ulterior a raportat pachetele de infrastructură vizate de atacator către npm pentru eliminare. Echipa a documentat fiecare undă, a urmărit datele introduse în git, a analizat codul ofuscat, a arătat dovezi ale utilizării Solana C2 și a oferit îndrumări pas cu pas pentru remediere celui care se ocupă de mentenanță.

Dincolo de detectare, controalele preventive încep să câștige teren în conductele de consolidare continuă. De exemplu, funcția npm Package Cooldown Check de la StepSecurity permite organizațiilor să blocheze dependențele publicate cu doar câteva ore în urmă, câștigând timp pentru ca scanerele și oamenii să le inspecteze. Verificarea actualizărilor compromise face trimitere la un flux actualizat constant de pachete cunoscute ca fiind defecte și eșuează PR-urile care încearcă să le adauge sau să le actualizeze.

Instrumentele adaptate la rețea, cum ar fi Harden-Runner, restricționează conexiunile de ieșire din GitHub Actions și alte joburi CI la o listă permisă de puncte finale așteptate. Într-o lume în care programele malware preiau sarcini utile din nodurile RPC Solana, URL-urile Google Calendar, intervalele IP Vultr sau canistrele ICP, blocarea ieșirilor din sistemele de compilare poate face diferența dintre o diferență de pachet defect și o intruziune în toată regula.

În ceea ce privește răspunsul, funcții precum căutarea de colete la nivelul întregii organizații și centrele de amenințări ajută echipele să cartografieze rapid raza exploziei. De îndată ce este identificat un pachet sau plugin React Native compromis, echipele de securitate pot vedea ce depozite, ramuri și fișiere de blocare îl includ, ce joburi l-au executat și ce mașini au comunicat cu IP-uri suspecte – și apoi pot prioritiza remedierea în consecință, pe zeci sau sute de baze de cod.

Acțiuni practice pentru echipele React Native care se confruntă cu malware-ul npm

Atât pentru dezvoltatorii React Native, cât și pentru inginerii de securitate, apărarea împotriva atacurilor la nivel npm înseamnă combinarea igienei pe mașini individuale cu măsuri de siguranță în CI/CD și gestionarea dependențelor. Niciun control singular nu te va salva, dar apărările stratificate reduc dramatic șansele ca un pachet rău intenționat să se transforme într-o compromitere completă.

Dacă utilizați pachetele compromise menționate anterior, există câteva verificări imediate de efectuat. Pentru incidentul AstrOOnauta, fixați cu un pin react-native-international-phone-number la versiune 0.11.7 și react-native-country-select la 0.4.0, evitând toate versiunile marcate ca fiind rău intenționate sau care rezolvă probleme @latest care în prezent corespunde unei versiuni compromise.

Verificați directorul principal pentru un fișier numit init.json sub profilul utilizatorului (de exemplu ~/init.json pe Unix și ~\init.json pe Windows). Prezența sa sugerează că malware-ul bazat pe Solana a fost executat cel puțin o dată. De asemenea, verificați jurnalele de rețea de ieșire de la stațiile de lucru ale dezvoltatorilor și de la rulourile CI pentru conexiuni la 45.32.150.251, punctele finale Solana RPC utilizate în campanii sau celelalte adrese C2 citate anterior (de exemplu, 136.0.9[.]8, 85.239.62[.]36, 195.133.79.43, 217.69.3.152).

Verificați-vă node_modules și fișiere de blocare pentru dependențe revelatoare, cum ar fi @agnoliaarisian7180/string-argv, @usebioerhold8733/s-format și răuvoitorul @react-native-aria/* or @gluestack-ui/utils versiunile enumerate în avize. Dacă găsiți oricare dintre acestea, tratați mașina ca fiind potențial compromisă și schimbați toate acreditările sensibile: token-uri npm, token-uri de acces GitHub, chei SSH, chei de furnizor cloud și orice secrete prezente în .env sau fișiere de configurare în timpul instalării.

Privind în perspectivă, consolidați-vă postura în lanțul de aprovizionare pentru munca React Native: comite și impune întotdeauna fișierele de blocare (package-lock.json, yarn.lock, pnpm-lock.yaml), activați 2FA pe toate conturile npm cu drepturi de publicare și configurați CI-ul să eșueze construcțiile atunci când apar dependențe noi fără revizuire. Luați în considerare rularea cu --ignore-scripts atunci când instalați pachete terțe în contexte nesigure și conectați instrumente de scanare a dependențelor atât în ​​fluxurile de lucru locale, cât și în CI.

În cele din urmă, tratați mediile de dezvoltare – în special cele utilizate pentru aplicațiile React Native care fac legătura între API-urile mobile, web și backend – ca parte a suprafeței de atac pentru producție. Indiferent dacă amenințarea este o preluare de cont care introduce un malware susținut de Solana într-o componentă de introducere a datelor de pe telefon, un plugin Vite typosquatted care șterge React din... node_modules, o integrare Quill malițioasă care blochează stocarea pe partea de client sau un RCE în interfața CLI a comunității React Native, firul comun este că atacatorii văd acum instrumentele pentru dezvoltatori ca fiind una dintre cele mai eficiente căi către bijuteriile coroanei organizației dumneavoastră.