Mantra din Silicon Valley „move fast and break things” prioritizează creșterea înainte de orice altceva. Din păcate, această viteză se traduce și prin introducerea rapidă a vulnerabilităților în lanțurile de aprovizionare software. De la biblioteci open source la asistenți de programare cu AI, aceste instrumente accelerează inovația, dar creează și noi vectori de atac pe care hackerii caută să îi exploateze.
Riscurile legate de terți au existat mereu, dar nu au fost întotdeauna o prioritate. În ultimul deceniu, ransomware-ul a dominat titlurile și atenția liderilor din securitatea cibernetică. În ultimii ani, amenințările statale și riscul tot mai mare de război cibernetic au trecut în prim-plan.
Indiferent de motivație sau de modul de operare, vulnerabilitățile din lanțul de aprovizionare software rămân o țintă atractivă pentru atacuri.
Breșa SolarWinds a fost un semnal de alarmă privind riscul provenit de la terți. Nu contează cât de solide sunt apărările tale dacă un furnizor din amonte are un tunel securizat către infrastructura ta.
Vulnerabilitatea Log4J (Log4Shell) a arătat cum riscul provenit de la terți se poate manifesta în biblioteci open source, adoptate pe scară largă în serviciile companiilor. Odată dezvăluite, actorii malițioși au profitat imediat de aceste vulnerabilități.
În ultima perioadă, atenția s-a mutat către asistenții de programare bazați pe AI și tendința lor de a „halucina” răspunsuri incorecte factual. Când identifică o astfel de bibliotecă „halucinată”, atacatorii înregistrează un pachet malițios cu același nume.
Dezvoltatorii ajung să integreze, fără să știe, aceste pachete malițioase în codul lor. Cercetătorii în securitate au numit acest tip de atac „slopsquatting”.
În consecință, atât DevOps, cât și securitatea cibernetică trebuie să fie mai proactive în identificarea și remedierea acestor riscuri. DevOps numește această abordare „shift left”, iar securitatea cibernetică o numește „left of boom”. Fundamentul ambelor este vizibilitatea.
Moștenirea riscului provenit de la terți
Riscurile legate de terți nu sunt deloc un fenomen nou. Exemple de atacuri asupra lanțului de aprovizionare există de cel puțin două decenii. În 2003, cineva a încercat, în mod notoriu, să introducă un backdoor în kernelul Linux.
Totuși, abia după breșa SolarWinds din 2020 organizațiile au început să trateze cu seriozitate acest tip de risc.
Atacul SolarWinds a fost o operațiune sofisticată de tip supply chain, atribuită unui grup APT rus. O actualizare software compromisă a distribuit un backdoor malițios către 18.000 de clienți, permițând accesul la ținte de mare valoare, inclusiv zeci de agenții federale din SUA.
Un an mai târziu, Log4Shell a declanșat o criză majoră de securitate a lanțului de aprovizionare. Log4J este o bibliotecă open source populară pentru logare în ecosistemul Java, integrată în sute de milioane de aplicații și dispozitive.
Astfel de vulnerabilități sunt și mai problematice în mediile de tehnologie operațională (OT), care includ active critice și tehnologii vechi, greu sau imposibil de actualizat.
Multe organizații folosesc biblioteci open source pentru că accelerează inovația și reduc costurile, însă în cazul Log4J, această comoditate a lăsat software-ul expus.
Săptămâni la rând după dezvăluirea Log4Shell, companiile au încercat să identifice ce furnizori integrau Log4J în soluțiile lor, iar furnizorii au fost nevoiți să-și reasigure clienții în timp ce implementau planuri de remediere.
„Please don’t kill my vibe”
„Vibe coding” a devenit una dintre cele mai populare aplicații ale AI-ului generativ. Potrivit GitHub, 97% dintre dezvoltatori au folosit instrumente AI în ultimul an. Totuși, dependența excesivă de cod generat de AI introduce vulnerabilități în baza de cod.
Cercetători academici au descoperit că, dintre cele 16 instrumente principale de generare de cod, 19% dintre pachetele software recomandate nu există, iar 43% dintre pachetele „halucinate” sunt recomandate în mod repetat.
Actorii malițioși identifică proactiv aceste pachete inexistente și înregistrează din timp cod malițios cu același nume. Un dezvoltator din cadrul Python Software Foundation a numit acest atac „slopsquatting”, prin analogie cu cybersquatting sau typosquatting.
De exemplu, un pachet malițios numit „ccxt-mexc-futures” a fost înregistrat și descărcat de peste 1.000 de ori din PyPI, un depozit public de software. În acest caz, malware-ul modifica operațiuni-cheie folosite în tranzacționarea criptomonedelor.
Dincolo de companie, înainte de atac
Există diferențe semnificative între aceste exemple de risc provenit de la terți. Atacul SolarWinds a fost unul extrem de țintit, care a scos în evidență integritatea lanțului de aprovizionare.
Vulnerabilitatea Log4J a fost considerată, la momentul respectiv, cea mai răspândită vulnerabilitate dezvăluită vreodată, evidențiind nevoia de vizibilitate asupra lanțului de aprovizionare.
Apariția slopsquatting-ului impune un control mai strict asupra asistenței de programare bazate pe AI.
Tema comună este nevoia de mai multă vizibilitate. Complexitatea dependențelor software din întregul lanț de aprovizionare face dificilă monitorizarea vulnerabilităților și riscurilor.
Organizațiile pot audita proveniența software-ului prin Software Bill of Materials (SBOM), pentru a urmări originea și versiunea fiecărei dependențe. Testarea de securitate statică (SAST) și dinamică (DAST) poate identifica vulnerabilități exploatabile.
Din nou, vizibilitatea este esențială. Totul începe cu un inventar complet al activelor, pentru a evalua impactul de business al aplicațiilor.
Echipele de securitate pot monitoriza și indicatori de acțiune sau atac (IOA), precum comportamente neobișnuite ale sistemelor sau conexiuni noi. Identificarea acestor anomalii comportamentale este un caz ideal de utilizare pentru AI, deoarece machine learning excelează în recunoașterea tiparelor și a deviațiilor de la normal.
În ceea ce privește asistenții de programare bazați pe AI, dezvoltatorii trebuie să fie conștienți de riscuri, precum autentificarea deficitară a conturilor sau slăbiciunile de validare a inputului. Securitatea ar trebui integrată chiar în prompturi, de exemplu, blocarea conturilor prin MFA și sanitizarea inputului.
De asemenea, este mai important ca oricând să existe o revizuire umană obligatorie și testare de securitate a aplicațiilor.
