Acest blog prezintă principalele concluzii ale webinarului nostruSupply Chain cuSoftware : punctele slabe exploatate de atacatori”. Urmăriți webinarul complet aici.
Riscurile legate de lanțul Software au crescut dramatic, deoarece organizațiile se bazează pe mai multe componente open-source, pachete externe și procese de dezvoltare automatizate. Micile lacune care odată păreau inofensive au acum consecințe reale, mai ales că dependențele devin din ce în ce mai profunde și mai greu de verificat.
Un exemplu clar al acestei schimbări a fost recentul vierme npm Shai-Hulud și Shai-Hulud 2.0, care s-a răspândit prin pachete compromise și a afectat mii de proiecte în aval în doar câteva ore. Incidentele de acest gen clarifică un lucru: vulnerabilitățile lanțului de aprovizionare nu mai rămân izolate, ci se propagă în întregi ecosisteme.
Având în vedere că 70-90% din software-ul modern este alcătuit din componente open-source, pe care majoritatea dezvoltatorilor nu le văd niciodată direct, problemele minore pot deveni rapid expuneri majore. Cu toate acestea, doar 15% din organizații se simt încrezătoare în modul în care gestionează riscul open-source. Având în vedere că 70% din atacurile AI rău intenționate vor viza lanțurile de aprovizionare până în 2025, identificarea punctelor slabe din lanțul de aprovizionare cu software este acum esențială.
Pentru echipele de inginerie și securitate, avantajul este simplu: cunoașterea acestor puncte slabe înseamnă mai puține surprize, timpi de răspuns mai rapizi și o probabilitate mult mai mică de a ajunge în următorul titlu de știri despre lanțul de aprovizionare.
SBOM-urile nu mai sunt opționale
Pentru a gestiona riscurile legate de lanțul de aprovizionare cu software și pentru a răspunde vulnerabilităților, organizațiile au nevoie de o imagine clară asupra conținutului pachetului lor software. La baza acestei vizibilități se află SBOM (lista de componente software), care creează transparența necesară pentru a înțelege riscurile legate de componente și pentru a acționa rapid atunci când apar probleme.
Un SBOM este definit ca un inventar detaliat al tuturor componentelor închise și open-source, licențelor și dependențelor utilizate într-o aplicație. Acest inventar furnizează date esențiale pentru transparență, conformitate și gestionarea riscurilor.
Ceea ce astăzi nu este vulnerabil sau dăunător poate deveni cu ușurință așa mâine. Deoarece vulnerabilitățile sunt descoperite în mod continuu, inclusiv în versiunile mai vechi, este necesară monitorizarea și inventarierea permanentă.
George PrichiciVP, Produse, OPSWAT
SBOM vs. SCA
Un aspect important este distincția dintre SBOM și SCA (Software Analysis). SBOM este inventarul sau lista componentelor. SCA evaluează dacă vreuna dintre aceste componente este vulnerabilă, depășită sau riscantă. Împreună, acestea oferă organizațiilor informațiile necesare pentru a lua decizii în cunoștință de cauză, pentru a răspunde mai rapid la problemele de securitate și pentru a consolida gestionarea generală a riscurilor.
| Categoria | SBOM | SCA |
|---|---|---|
Scop | Inventarul componentelor |
Identificați vulnerabilitățile componentelor
|
Acoperirea riscurilor | Conformitate și vizibilitate | Riscuri de securitate, CVE, riscuri de rulare |
Sincronizare | Pre-implementare / achiziție | Continuu / compilare și rulare |
Mișcările globale, determinate în parte de atacuri precum SolarWinds, impun acum utilizarea SBOM-urilor, iar presiunile normative exercitate de entități precum CISA, NSA și NIST, precum și de UE și țările aliate NATO fac ca transparența SBOM să nu mai fie opțională, ci o cerință fundamentală pentru orice furnizor de software.
Cele 7 puncte slabe critice pe care atacatorii le exploatează
Viteza dezvoltării moderne, combinată cu dependența puternică de coduri open-source și de terți, a introdus vulnerabilități grave. Actorii amenințători exploatează șapte puncte slabe principale:
1. Riscul asociat surselor deschise și dependenței
Când dezvoltatorii acordă prioritate vitezei, ei folosesc adesea biblioteci open-source mari, fără a efectua o revizuire completă a codului. O singură componentă poate introduce dependențe tranzitive suplimentare. Dacă monitorizați doar nivelul superior, puteți rata codul rău intenționat injectat în acele dependențe tranzitive ascunse.
Acest model este ceva ce continuăm să observăm în ecosistemele open-source. Un singur pachet compromis poate avea un efect în cascadă asupra lanțurilor de dependențe și poate ajunge la milioane de descărcări înainte ca cineva să observe. Un atac recent asupra lanțului de aprovizionare npm, care a implicat malware criptografic, evidențiază exact cum se întâmplă acest lucru în practică.
Cele mai bune practici:
- Scanați toate pachetele open-source și lanțurile complete de dependențe ale acestora pentru a identifica vulnerabilitățile, componentele învechite sau malware-ul ascuns înainte ca acestea să ajungă în codul dvs. sursă.
- Monitorizați continuu dependențele în timp, deoarece componentele sigure pot deveni riscante odată cu apariția unor noi CVE-uri sau actualizări rău intenționate.
- Utilizați registre de încredere și verificați integritatea pachetelor pentru a vă asigura că pachetele pe care le descărcați nu au fost modificate.
- Aplicați politici care semnalează sau blochează licențele riscante, astfel încât termenii de licență incompatibili sau virali să nu se strecoare în versiunile dvs.
- Amânați utilizarea pachetelor nou publicate până când acestea sunt verificate, reducând astfel riscul de a introduce în mediul dvs. versiuni necontrolate sau dăunătoare.
2. Riscul legat de licențiere
Problemele legate de licențiere afectează acum atât ingineria, cât și aspectele juridice. Licențele virale, precum GPL, pot obliga aplicația rezultată să fie publicată sub aceeași licență, ceea ce poate determina pierderea proprietății intelectuale (IP) a companiei dumneavoastră. Este necesară o monitorizare continuă, deoarece termenii licenței se pot modifica, chiar și pentru versiunile mai vechi, care anterior erau conforme.
Cele mai bune practici:
- Utilizați un instrument automat de detectare a licențelor pentru a semnaliza licențele cu risc ridicat sau incompatibile încă din faza incipientă a dezvoltării. O explicație mai detaliată a importanței acestui aspect este prezentată aici: Rolul crucial al detectării licențelor în securitatea open source.
- Urmăriți continuu modificările licențelor pentru a detecta schimbările care pot afecta conformitatea sau expunerea IP.
- Blocați sau verificați componentele cu licențe restrictive sau virale înainte ca acestea să intre în baza de cod.
- Păstrați un inventar clar al tuturor licențelor utilizate pentru a simplifica auditurile și evaluările de risc.
3. Lacunele în datele SBOM sau SBOM-urile lipsă
Deși reglementările impun partajarea SBOM-urilor, o listă la nivel înalt este insuficientă. Pentru o atenuare și prevenire eficientă sunt necesare date detaliate, inclusiv autorul, colaboratorii, frecvența lansării și starea de întreținere.
Cele mai bune practici:
- Îmbunătățiți rapoartele SBOM prin rescanarea componentelor pentru a le îmbogăți cu date actualizate privind licențele, starea vulnerabilităților și alte metadate critice. Un exemplu detaliat despre cum se poate face acest lucru este prezentat aici, în secțiunea Validarea și îmbogățirea rapoartelor SBOM CycloneDX.
- Validați și îmbogățiți SBOM-urile folosind instrumente automate pentru a vă asigura că informațiile sunt complete, exacte și utile.
- Solicitați furnizorilor să furnizeze informații complete privind SBOM, inclusiv dependențele tranzitive și toate metadatele relevante.
- Actualizați și monitorizați continuu inventarele SBOM pe măsură ce componentele evoluează sau apar noi vulnerabilități.
4. Furnizori terți
Fiecare furnizor pe care vă bazați devine parte a lanțului dvs. de aprovizionare. Dacă aceștia livrează componente învechite sau compromise, dvs. preluați acest risc. SBOM-urile complete, inclusiv dependențele tranzitive, vă permit să înțelegeți rapid expunerea dvs., în loc să urmăriți furnizorii în timpul unui incident. O postare recentă pe tema Gestionarea vulnerabilităților dependențelor înSupply Chain dvs.Supply Chain Software explorează modul în care echipele pot consolida această parte a procesului.
5. Supply Chain AI
Datorită adoptării rapide a IA, echipele ocolesc adesea restricțiile normale, ceea ce face ca acest lucru să devină un vector de atac major. Atacatorii injectează coduri malitioase în modele de învățare automată, fișiere PICO sau biblioteci open-source. Typosquatting-ul este frecvent în medii precum Pytorch, unde utilizatorii pot descărca biblioteca greșită, care poate livra malware și duce la executarea completă a codului de la distanță pe computerul unui inginer.
6.Container
Scanarea containerelor trebuie să evolueze dincolo de concentrarea exclusivă asupra vulnerabilităților. Securitatea modernă trebuie să scaneze și în căutarea de malware, minerit criptografic și amenințări cu acțiune rapidă publicate în imagini de containere disponibile public. O analiză recentă a NVIDIA Container CVE-2024-0132 arată cât de ușor pot fi trecute cu vederea aceste probleme.
7. Scurgerea de secrete și acreditări
Când echipele acționează rapid, deseori codifică cheile de acces sau datele de autentificare în codul sursă pentru testare. Chiar dacă sunt suprascrise ulterior, aceste informații secrete rămân deseori în istoricul Git, unde pot fi ușor găsite de atacatori prin scanare. Demascarea amenințărilor ascunse: Cum să detectați informațiile secrete din cod arată cum se produc aceste expuneri și ce pot face echipele pentru a le preveni.
Calea către unSupply ChainSoftware Secure
Pentru a contracara aceste amenințări, securitatea trebuie să adopte o mentalitate de „deplasare spre stânga”, ceea ce înseamnă că aceleași politici aplicate înainte de lansare ar trebui aplicate mai devreme în ciclul de dezvoltare. Obiectivul este de a integra securitatea ca o suprapunere peste canalul CI/CD existent. Această abordare automatizată asigură aplicarea atunci când este necesar, fără a afecta productivitatea ingineriei.
O soluție completă trebuie să ofere:
- Scanarea automată a lanțului de aprovizionare pe întreaga durată a procesului
- Vizibilitate asupra codului sursă, containerelor și fișierelor furnizate de furnizori
- Analiză care depășește CVE-urile pentru a detecta malware, probleme legate de licențe și secrete expuse
Cum OPSWAT la eliminarea acestor lacune
- Multiscanning detectarea timpurie a malware-ului
- Porți de securitate CI/CD integrate pentru GitHub, GitLab, TeamCity, Jenkins și multe altele
- Generarea automată a SBOM și maparea vulnerabilităților
- Semnarea artefactelor și validarea integrității
- Scanarea secretelor și aplicarea măsurilor de igienă a credențialelor
Discutați cu unul dintre experții noștri pentru a găsi soluții personalizate pentru stiva dvs. chiar astăzi.
