Acesta este al treilea episod dintr-o serie de articole despre cel mai răspândit tip de atacuri asupra lanțului de aprovizionare software: cele care abuzează de un registru public de open-source componente software. După analiza din episodul anterior „Anatomia pachetelor rău intenționate: Care sunt tendințele?„Având în vedere modul în care actorii rău intenționați injectează comportamente rău intenționate în componente publicate noi sau existente, suntem gata să ne îmbrăcăm în hainele de pompieri și să examinăm cum putem bloca cu succes software-ul rău intenționat distribuit în acest fel sau, alternativ, să gestionăm un incident cibernetic potențial grav, deoarece am adoptat o abordare greșită.”
Majoritatea profesioniștilor conștienți de securitate au idei despre cum să gestioneze această amenințare. I-am auzit pe managerii de securitate spunând fără ezitare că SCA Instrumentele vă spun deja când o versiune a unui pachet este malware. Sau că depind de componente software bine-cunoscute și evaluate cu atenție, unde orice malware ar fi detectat și eliminat prompt. Folosesc versiuni minore/patch-uri deschise pentru a obține automat remedieri de vulnerabilități, iar aceasta este modalitatea corectă și recomandată de a reduce riscul legat de dependențele open source, urmând „plasture devreme, plasture des”Principiul.
În acest episod, vom analiza de ce aceste idei sunt greșite și cum astfel de concepții greșite contribuie la popularitatea acestui mecanism de atac și la un risc copleșitor cu care se confruntă organizațiile. Vom încheia cu ce funcționează și care este efortul și resursele implicate.
Concepții greșite comune
În parcursul nostru în domeniul securității software, am observat evoluția tehnicilor de atac și o gamă largă de idei din partea unor persoane preocupate de securitate. Organizațiile înțeleg adesea greșit ce funcționează împotriva acestei amenințări, așa că mai întâi vom examina ce nu funcționează, condensat în următoarea listă, neexhaustivă, de concepții greșite.
Concepție greșită #1: SCA instrumentele raportează deja componente rău intenționate
Intr-adevar! Dar după fapt... Când probabil este prea târziu dacă elementul a fost folosit într-o versiune de software, iar răufăcătorii au deja obținut un punct de sprijin într-un dezvoltator sau CI/CD gazdă. Este posibil ca secretele să fi fost exfiltrate, ca malware suplimentar să fi fost descărcat și instalat și, probabil, ca adversarul să se fi deplasat lateral și să fi obținut deja acces în altă parte.
Analiza compoziției software (SCA) instrumentele au fost concepute pentru a identifica potențialele vulnerabilități cunoscute. Instrumentele moderne fac o treabă excelentă prin creșterea raportului semnal-zgomot, determinând dacă vulnerabilitatea este într-adevăr accesibilă sau exploatabilă. Dar sunt inutile împotriva noilor programe malware. Gândiți-vă la o componentă rău intenționată ca la o vulnerabilitate zero-day: numai atunci când este detectat comportamentul său rău intenționat, componenta este raportată registrului de stocare, care, după o revizuire de către o echipă de securitate, este confirmat ca fiind rău intenționat și eliminat din registru. [1].
În acel moment, lumea (inclusiv SCAs) știe că instalarea sau utilizarea componentei (sau a unor versiuni ale unei componente existente) nu este un lucru bun. Dar asta se întâmplă atunci când componenta nu este disponibilă în registruȘtiind că am vulnerabilități în componente terțe sau chiar în componente care au fost clasificate drept rău intenționate de către registru este bine, dar din păcate SCA sau instrumentele comune de audit nu ajută în acest context. Cu excepția cazului în care SCAInstrumentul /audit poate ști dinainte că o componentă este rău intenționată înainte de a fi utilizată în cadrul organizației dumneavoastră.
Rețineți că orice soluție împotriva componentelor open source rău intenționate trebuie să le detecteze. pe fuga, între momentul în care componenta este publicată în registru și momentul în care componenta (versiunea) este utilizată pentru prima dată în cadrul organizației dumneavoastră. Și asta include și componentele tranzitive.
Concepția greșită nr. 2: Controlul scripturilor de instalare în timpul construirii previne comportamentul rău intenționat al componentelor open-source
Diverse manageri de pachete oferă posibilitatea de a rula scripturi (incluse în fișierul tarball al componentei [2]), din motive legitime, cum ar fi compilarea elementelor necesare pe diferite platforme, generarea de cod sau rularea de teste, și ar trebui să știm cu toții că acestea pot fi abuzate de către răufăcători dacă în fișierul tar sunt incluse scripturi rău intenționate sau dacă atacatorul poate face ca un script rău intenționat să ruleze în locul celui bun.
Știind acest lucru, putem configura managerul de pachete să ignore scripturile. De exemplu, cu NPM –Ignore-scripturi steag (sau o proprietate de configurare din .npmrc fișier) omite scripturile în timpul instalării. Acest lucru poate cauza unele probleme deoarece rularea scripturilor este comună în multe ecosisteme: Unele manageri de pachete nici măcar nu permit dezactivarea executării scripturilor (indiciu: promptul „Ce manageri de pachete nu permit dezactivarea executării scripturilor de instalare?„în inteligența artificială preferată). Dar acest lucru nu protejează în general (trebuie să impunem ca configurația de dezactivare a saltului să fie peste tot).
Și când comportamentul rău intenționat nu este localizat în scripturile de instalare, ci în software-ul care se execută la momentul execuției, această opțiune singură nu ne protejează.
Concepție greșită nr. 3: Fixarea versiunilor împiedică instalarea componentelor rău intenționate
Există un compromis între aplicarea patch-urilor devreme și aplicarea acestora frecvent cu versiuni deschise (permițând managerului de pachete să instaleze automat actualizări noi atunci când sunt disponibile remedieri de securitate) și fixarea versiunii (având toate dependențele directe și tranzitorii pentru un software la o versiune fixă). Principiile de securitate sunt încăpățânate și uneori contradictorii, așa cum se întâmplă cu „aplică corecturi devreme, aplică corecturi des” și „Modernizarea nu ar trebui luată cu ușurință”Unii manageri de pachete fac actualizări automate cu intervale de servere în modul recomandat. Excelent dacă doriți să primiți și actualizări rău intenționate! Da, componentele trebuie actualizate pentru a primi remedieri de securitate care închid vulnerabilitățile cât mai curând posibil, dar... nu lăsați niciodată managerul de pachete să facă acest lucru automat.
Concepția greșită nr. 4: Utilizarea componentelor de încredere este sigură. Orice versiune rău intenționată va fi descoperită, dezvăluită și eliminată prompt.
De ce este o componentă de încredere? Posibil pentru că este foarte populară, cu mulți ochi care caută vulnerabilități, un număr mare de contribuitori la mentenanță, cu mai mulți mentenatori principali care revizuiesc cu sârguință toate. pull requestsRealitatea este cu totul alta. Unele componente esențiale sunt întreținute de un singur dezvoltator neremunerat. Framework-urile utilizate pe scară largă au câțiva contribuitori obișnuiți, cu un număr în scădere rapidă de commits per întreținător (proiectele populare au o coadă lungă de contribuitori care efectuează unele intervenții indirecte) commit (și nu se mai întorc niciodată). Și proiectele populare cu un singur administrator sunt numeroase.
Imaginează-te spunând „Oh, folosim Spring Boot / Angular / React / PyTorch / imagini oficiale de bază Docker, deci riscul despre care vorbești este destul de mic.” Poate că este adevărat, noi, furnizorii de securitate, alarmăm tot timpul și intervenția în echipele de dezvoltare pentru a atenua un risc discutabil este o prostie. S-ar putea să fiți tentați să treceți la paragraful despre acceptarea riscurilor (în secțiunea următoare) și gata. Din păcate, cele mai populare componente sunt ținte pentru actorii rău intenționați și, de exemplu, popularele... Biblioteca PyTorch a fost atacată în trecut.
„Găsit, dezvăluit și îndepărtat prompt”. Durează zile întregi până când o nouă componentă rău intenționată este eliminată din registrul public. Registrele sunt precaute în ceea ce privește eliminarea definitivă a unei versiuni de componentă. Experiența noastră este că, odată raportată de noi, timpul mediu necesar pentru ca registrul să elimine versiunea afectată este de 39 de ore, mai mult de o zi și jumătate. Există componente rău intenționate care sunt eliminate la o săptămână după raportarea inițială în registru. Și, în unele cazuri, componenta este eliminată numai după ce o victimă sau o companie de răspuns la incidente raportează un incident care implică componenta respectivă.
Ce NU funcționează împotriva componentelor rău intenționate
Orice abordare nespecifică va eșua lamentabil. Acest lucru este o certitudine, nu oferiți contramăsuri eficiente pentru riscul asociat cu această amenințare.
Mobilă tradițională SCA Instrumentele vă informează despre programele malware cunoscute, dar au o fereastră mare de expunere. Cu excepția cazului în care efectuează în mod proactiv detectarea programelor malware cu blocarea forțată a componentelor rău intenționate, acestea nu funcționează împotriva acestei amenințări.
Dezactivarea scripturilor de instalare ar putea fi de ajutor, dar trebuie impusă peste tot unde trebuie instalată o componentă. La fel și în cazul fixării versiunilor, deoarece versiunile nu pot fi fixate pentru totdeauna dintr-o stare inițială sigură.
A presupune că componentele populare primesc suficientă atenție încât să nu poată fi injectate cu comportamente neintenționate într-un atac asupra lanțului de aprovizionare fără o detectare aproape instantanee pentru a preveni orice daune este naiv și riscant. Nu vrei să trăiești la limită, nu-i așa?
Dacă te oprești în acest punct, atunci acceptarea riscurilor este singurul lucru pe care îl poți face: Acesta este un decisțiune care trebuie documentată în modelul dumneavoastră de amenințare/evaluarea riscurilor, inclusiv justificarea acceptării riscului și implicațiile sale potențiale. Creșteți gradul de conștientizare prin comunicarea acesteia către conducere și alte părți relevante. Unele contingență ar putea fi planificat atunci când o componentă rău intenționată este instalată sau inclusă în software-ul dvs., dar acest lucru este dificil deoarece atacatorii au multe căi de urmat. Detaliile unui atac asupra lanțului de aprovizionare bazat pe utilizarea unei componente rău intenționate vor schimba drastic dezvăluirea publică a incidentului, care probabil este obligatorie în conformitate cu cadrul de reglementare al organizației dvs. De asemenea, puteți aborda controale compensatorii or riscul de transfer de exemplu, cu asigurare.
Totuși, există controale care abordează amenințarea și ar trebui luate în considerare dacă nu sunteți mulțumit de acceptarea riscului. Vă rugăm să citiți mai departe.
Ce funcționează împotriva atacurilor care utilizează componente rău intenționate
Gestionarea versiunilor solide
Fixarea versiunilor cu modificări controlate și informate ale versiunilor este calea de urmat, pentru a echilibra necesitatea eliminării vulnerabilităților fără a primi programe malware. Dar țineți concepția greșită numărul 3: Fixarea versiunilor nu este suficientă pentru a bloca codul malițios provenit din versiunile noi, deoarece va trebui în viitor să actualizați versiunile în orice dependență directă sau indirectă. În acel moment, aveți nevoie de dovezi suficient de puternice pentru ca toate versiunile modificate să nu conțină programe malware.
Avertizare timpurie
O abordare a problemei componentelor malițioase este un sistem de avertizare timpurie (denumit aici Avertizare timpurie privind programele malware sau MEW), unde noile versiuni publicate (pentru componente noi sau existente) sunt analizate de un motor de detecție, care, atunci când se găsesc suficiente dovezi, poate clasifica noua versiune ca fiind potențial rău intenționată.
Automatizarea este esențială aici, deoarece este imposibil să se revizuiască manual toate componentele noi în ritmul actual de publicare. Așadar, motorul de detectare trebuie să combine o varietate de tehnici, inclusiv, eventual, analiza statică, dinamică și a capabilităților, reputația utilizatorilor și dovezi provenite din discrepanțe dintre metadatele componentei și conținutul arhivei tarball sau dintre arhiva tarball și depozitul sursă de unde se presupune că provine componenta.
Există o zonă întunecată între momentul publicării și momentul în care motorul analizează conținutul componentelor, dar nu ar trebui să depășească câteva minute. Schema poate fi modificată, de exemplu, așteptând analizarea noilor componente înainte de a permite instalarea și utilizarea lor în compilarea software-ului. pipelines sau să le analizeze la cerere atunci când este nevoie. O componentă la o anumită versiune este imuabilă [3], deci trebuie analizat o singură dată.
Automatizarea completă nu este posibilă și este necesară o analiză de securitate pentru componentele potențial malițioase. Atenție la susținătorii panaceului digitalInteligența artificială și învățarea automată nu sunt suficient de dezvoltate pentru a avea ultimul cuvânt atunci când vine vorba de confirmarea dacă o componentă suspectă are malware. Sigur, învățarea automată joacă un rol cheie în motorul de detectare în clasificarea componentei de intrare din dovezile brute capturate, dar odată ce componenta este „pusă în carantină”, ultimul cuvânt îl are revizuirea manuală de către o echipă de securitate cu experiență în componente rău intenționate. Aceasta confirmă orice potențial malware sau îl reclasifică ca fiind sigur. Iar perioada de timp este de ordinul orelor.
Registrul raportează versiunea/componenta rău intenționată; apoi, registrul efectuează analiza pentru a confirma și procedează la dezvăluirea publică și eliminarea din registru. Unele registre păstrează un pachet de stocare a securității. Intervalul de timp aici este reprezentat de zilele sau săptămânile de la publicare, care reprezintă „timp de locuit"sau"fereastră de expunere„pentru majoritatea componentelor rău intenționate.”
Este posibil să știm dacă o versiune a unei componente este rău intenționată?
Așadar, pentru o avertizare timpurie, trebuie să oferim un răspuns satisfăcător la această întrebare: Cum pot ști că o bibliotecă sau un pachet (nu) este rău intenționat? Cum să adun suficiente dovezi ale unui comportament rău intenționat? Posibil, dar dificil, deoarece adversarii folosesc multă ingeniozitate pentru a evita detectarea. Există diferite abordări, fiecare cu avantaje și dezavantaje.
Analiza statică poate examina toate căile de execuție, poate verifica tehnicile utilizate de atacatori fără a rula componenta și poate efectua sarcini de preprocesare, cum ar fi de-obfuscarea sau descifrarea. Întrucât atacatorii încearcă să-și ascundă răutățile, încercările de obfuscare sunt într-adevăr dovezi ale malware-ului (dar rețineți că componentele legitime obfuscă codul pentru a păstra proprietatea intelectuală, contrazicând „open-source„). Doar o minoritate de atacuri extrem de sofisticate cu ofuscare puternică necesită sandboxing, dar o astfel de ofuscare puternică este un semn revelator de răutate. Vă rugăm să rețineți că atacurile convenționale SAST Instrumentele au fost concepute pentru vulnerabilități neintenționate, nu pentru intenții rău intenționate, cum ar fi backdoor-urile.
Analiza dinamica execută componenta și examinează răspunsul prin instrumentarea runtime-ului, de obicei prin furnizarea unui mediu sandbox. Comportamentul rău intenționat declanșat în anumite condiții poate trece nedetectat: rețineți că programele malware pot utiliza tehnici de evitare a erorilor, cum ar fi Virtualizare/Sandbox Evasion să se activeze doar atunci când nu sunt sub supraveghere și, de asemenea, un semn revelator al unei activități rău intenționate pentru orice motor de analiză statică.
Analiza capacităților ia în considerare ce face componenta: unde se conectează, ce fișiere accesează, ce comenzi sau programe sunt rulate, terminalul sau dispozitivul I/O efectuat sau ce apeluri de sistem sunt invocate. Această amprentare a comportamentului ar putea fi comparată (pentru o componentă existentă) între versiuni, astfel încât, atunci când se detectează un comportament neașteptat, acea dovadă ar putea ridica suspiciunea unei potențiale activități rău intenționate injectate în noua versiune. Această abordare urmează pașii de triaj pe care analiștii de securitate îi urmează atunci când se confruntă cu potențiale programe malware: o inspecție folosind siruri sau instrumente similare. Această abordare detectează comportamentul rău intenționat indiferent de condițiile de declanșare și funcționează atunci când nu este disponibil niciun cod sursă.
Analiza contextului colectează informații despre modul în care a fost publicată componenta și de către cine. Campaniile rău intenționate folosesc adesea un cont (conturi) de utilizator nou (nou-nouțe) care nu sunt supuse niciunui proces strict de verificare. Urmărirea activității anterioare poate oferi informații despre utilizatorul principal, în special pentru anomalii care pot sugera o potențială compromitere. Reputația este atât de greu de câștigat și atât de ușor de pierdut! Un utilizator fără activitate anterioară este neutru, dar karma îi urmărește pe rău intenționat. Hacktiviștii sau utilizatorii obișnuiți cărora li se fură acreditările de publicare ar trebui urmăriți cu atenție.
O altă informație contextuală este orice discrepanță între depozitul sursă despre care se presupune că a fost folosit pentru a crea fișierul tarball al componentei și conținutul acestuia. De asemenea, se respectă bunele practici, cum ar fi crearea de etichete sau versiuni în depozitul sursă care să corespundă versiunilor componentei publicate în registrul public. Când depozitul sursă la un anumit punct... commit este etichetat cu lansare, iar apoi, dintr-o dată, o versiune nu o respectă, acest lucru în sine este o dovadă puternică că respectiva componentă ar putea fi afectată: răufăcătorul ar fi putut compromite contul utilizat pentru publicarea componentei, dar nu are permisiuni de scriere în depozitul de cod sursă). Multe atacuri sunt detectate în mod curent folosind aceste reguli: de exemplu, Atac la Ledger ar putea fi ușor detectate în acest sens. Prin urmare, analiza contextului identifică astfel de anomalii în procesul de publicare.
Firewall de dependență
O abordare diferită este să aveți o listă albă cuprinzătoare de componente pentru toate graficele de dependențe utilizate în software, astfel încât în orice versiune pipeline În cadrul organizației dvs., pot fi instalate și utilizate doar versiunile de componente aprobate. „firewall„” este aplicată folosind un registru intern unde sunt servite fișierele tar pentru versiunile de componente permise (în cache sau prin proxy). Rețineți că orice listă albă nu va funcționa decât dacă aveți tehnologia necesară pentru a clasifica orice versiune nouă ca fiind rezonabil de sigură, astfel încât să poată fi adăugată la lista albă.
Rețineți că avertizarea timpurie (detectare rapidă cât mai curând posibil după publicarea noii versiuni) trebuie combinată cu o modalitate de a utiliza proactiv aceste informații pentru a bloca componenta care afectează compilarea. pipelinesau mașinile dezvoltatorilor [4]Noi numim asta „firewall de dependențe„: un mecanism de carantină pentru protejarea versiunilor automate de pachete rău intenționate. Pachetele interne și registrele de imagini sunt bune pentru a izola organizațiile de răul extern, dar sunt necesare dovezi suficient de puternice pentru a face carantina eficientă.”
Sandboxing în timpul rulării
O abordare alternativă pentru detectarea în momentul publicării este analizarea comportamentului în timpul execuției. Ideea este de a surprinde comportamentul așteptat de la software și de a detecta (sau bloca) orice anomalii găsite. Această linie de acțiune prezintă problema necesității de a instrumenta timpul de execuție pentru monitorizare sau blocare și este o idee promițătoare care va fi adăugată arsenalului de mecanisme de protecție împotriva componentelor dăunătoare.
Stabilirea unei strategii cuprinzătoare
Strategia recomandată trebuie să combine diferite tehnici în procesul de dezvoltare software, preluând controlul asupra actualizărilor de versiuni pentru a bloca componentele rău intenționate primite. Trebuie să adoptăm fixarea versiunilor pentru a evita infectarea automată odată cu actualizarea versiunilor pentru a obține remedieri pentru vulnerabilitățile importante; o evaluare rapidă și eficientă a dependențelor directe și indirecte în timpul actualizărilor de versiuni pentru a avea suficiente dovezi că acestea nu sunt infestate cu programe malware. Compilările de software care depind de componente rău intenționate cunoscute trebuie blocate. Și toate acestea trebuie aplicate.
Folosește fixarea versiunilor, atunci când este posibil, deoarece face ca versiunile să fie mai reproductibile. Fixarea versiunilor cu modificări ale versiunilor controlate și aprobate manual și asistat de tehnologie auxiliară, ar trebui să evalueze dacă actualizarea aduce programe malware sau strică software-ul și să reconcilieze actualizarea pentru remedierea vulnerabilităților cu evitarea infecțiilor cu programe malware. Instrumentele pot ajuta aici prin (1) prioritizarea vulnerabilităților care contează cu adevărat (accesibile și exploatabile, cu un risc ridicat de a fi vizate de atacatori), (2) selectarea versiunilor țintă care sunt compatibile cu utilizările actuale ale componentelor și nu strică software-ul, (3) alegerea versiunilor țintă care nu conțin comportamente rău intenționate și (4) simplificarea actualizării versiunii pentru dependențele directe și indirecte, sugerând modificări în fișierele manifest care ar putea fi aprobate rapid. Pasul (3) necesită informații specifice despre componentele rău intenționate cât mai aproape de momentul publicării lor.
Acest proces de actualizare a dependențelor trebuie să fie executată și verificat în toate locurile. Procesul trebuie documentat, iar toate părțile implicate ar trebui instruite, deoarece adesea dezvoltarea și construirea/implementarea software-ului sunt externalizate. CI/CD pipelines ar trebui modificat în consecință, astfel încât automatizarea să nu permită o dependență indirectă rău intenționată să se strecoare în compilare: guardrails Blocarea build-ului dacă există suficiente dovezi ale unui potențial malware într-o dependență este metoda recomandată.
Dacă organizația dumneavoastră are un registru intern care acționează ca proxy de securitate pentru păstrarea versiunilor de componente permise, trebuie să obțineți informații despre componentele rău intenționate (pe lângă alte criterii) pentru a verifica o componentă solicitată înainte de a o adăuga pe lista de componente permise.
Utilizarea în siguranță a software-ului open-source nu este ușoară, iar factorul malware trebuie luat pe deplin în considerare, cu un efort similar depus și în gestionarea vulnerabilităților.
O ultimă notă: Proveniența sursei, sub forma atestărilor software, generate în momentul construirii componentei, este o altă piesă cheie în efortul de a urmări artefactul (arhiva tarball a componentei) cu sursele și procesul de construire care l-au produs. Rețineți că această legătură între instantaneul sursă + mediul de construire și artefactul software asociat (semnat de sistemul de construire de încredere) nu împiedică în sine faptul că respectiva componentă nu conține comportamente rău intenționate, dar îngreunează injectarea de programe malware de către rău intenționat. Iar transformarea validării provenienței într-o cerință comună pentru consumul de componente open source va dura mult timp și numai adăugat recent la NPMAsigurarea inviolabilității acelor sisteme de compilare și implementare de încredere sau activarea detectării oricărei modificări în procesul de compilare este o altă poveste, care nu intră în sfera acestei postări.
Lecturi suplimentare
Următorul episod Pachete rău intenționate cu sursă deschisă: Abordarea Xygeni va prezenta strategia pe care o urmăm la Xygeni pentru Avertizare timpurie privind programele malware Sistem (MEW). Noile versiuni de pachete din registrele publice de pachete și imagini sunt scanate, iar dovezile sunt obținute folosind o combinație de analize statice, dinamice, de capabilități și contextuale. Dovezile, combinate cu reputația utilizatorului și istoricul modificărilor din depozitele de cod sursă, permit o clasificare complet automată a unei componente în categorii cu risc ridicat și probabil rău intenționate. Sistemul învață din dovezile anterioare colectate din pachete pentru a reduce la minimum rezultatele fals pozitive.
Organizațiile abonate primesc o notificare de avertizare pentru componentele pe care le utilizează, direct sau indirect, atunci când o versiune rău intenționată este clasificată. Apoi, analiștii noștri efectuează o analiză manuală, care confirmă sau respinge clasificarea. Pentru programele malware confirmate, registrul public este notificat, astfel încât să poată efectua propria analiză și, de obicei, să elimine versiunea rău intenționată sau să ia măsuri suplimentare, cum ar fi blocarea sau eliminarea contului de utilizator în cauză.
Vom explica cum ajutăm NPM, PyPI, GitHub și alte infrastructuri cheie din ecosistemul open source să reducă timpul de așteptare în care o nouă componentă malițioasă publicată rămâne activă până când este confirmată ca fiind malware și eliminată din registru. Și cum pot beneficia organizațiile de sistemul MEW pentru a avea o protecție mult mai bună împotriva atacurilor din lanțul de aprovizionare software care implică componente open source.
- [1] În orice caz, utilizatorii componentei trebuie să verifice dacă fișierul tarball al componentei este memorat în cache sau înregistrat undeva, de exemplu într-un registru intern, astfel încât problema să fie eradicată.
- [2] Componenta inclusă în pachet include un manifest care declară conținutul și metadatele sale, codul sursă sau compilat, scripturile de instalare și elemente suplimentare, cum ar fi suite de teste, conform unui format de pachet și, de obicei, în formă comprimată. Aceasta se numește „arhiva tar a componentei”.
- [3] Chiar dacă actorul rău intenționat poate modifica o componentă publicată din cauza unei breșe în registru, un digest criptografic simplu poate detecta orice modificare a fișierului tar după finalizarea analizei.
- [4] Rețineți că unele componente rău intenționate rulează în timpul instalării, deci pot afecta nodurile dezvoltatorului care rulează fără să știe „npm install X” cu X ca o componentă rău intenționată.
