CYBERSECURITY
Atacurile asupra lanțului de aprovizionare software transformă relația de încredere dintre o companie și furnizorii săi într-o cale de acces. În loc să atace separat sute sau mii de organizații, un actor poate compromite un produs, o actualizare, o bibliotecă sau un furnizor de servicii folosit de toate.
Pe scurt
- Emsisoft atrage atenția asupra atacurilor care exploatează software și servicii de încredere pentru a ajunge la clienții furnizorului.
- Cazul SolarWinds a demonstrat că o actualizare semnată și aparent legitimă poate deveni vector de compromitere.
- Vulnerabilități precum Log4Shell arată un risc înrudit: o singură componentă foarte răspândită poate expune un număr uriaș de sisteme.
- CISA recomandă ca securitatea furnizorilor să intre în procesul de achiziție, contractare și monitorizare, nu să fie verificată doar după un incident.
- SBOM, inventarierea dependențelor, accesul cu privilegii minime și segmentarea reduc timpul necesar pentru a afla ce este expus și pentru a limita efectele.
Ce este un atac asupra lanțului software
Un lanț de aprovizionare software include dezvoltatorii, furnizorii, bibliotecile open-source, platformele de distribuție, serviciile cloud, instrumentele de administrare și alte componente care ajung, direct sau indirect, într-un produs folosit de o organizație. Fiecare relație adaugă funcționalitate, dar și o nouă dependență de securitatea altcuiva.
Emsisoft descrie scenariul de bază astfel: atacatorul compromite un furnizor sau un produs în care clienții au deja încredere, apoi folosește acea relație pentru a ajunge în rețelele clienților. Avantajul pentru atacator este de scară. O singură compromitere reușită poate deschide accesul către multe organizații.
SolarWinds: când actualizarea legitimă devine vector de atac
Unul dintre cele mai cunoscute exemple este compromiterea SolarWinds Orion. CISA a anunțat în decembrie 2020 că versiunile afectate ale platformei Orion, distribuite între martie și iunie 2020, erau exploatate activ. Cod malițios fusese introdus în lanțul de dezvoltare și distribuție, ajungând la clienți printr-un mecanism care, în mod normal, inspira încredere: actualizarea software.
Incidentul a schimbat modul în care multe organizații privesc actualizările și semnăturile digitale. O semnătură validă confirmă că pachetul provine din lanțul autorizat al furnizorului; nu garantează însă că mediul de dezvoltare al furnizorului nu a fost compromis înainte ca pachetul să fie semnat.
Kaseya: un instrument administrativ poate amplifica impactul
Un alt model apare atunci când produsul compromis are privilegii administrative asupra multor sisteme. În 2021, vulnerabilitatea CVE-2021-30116 din Kaseya VSA a fost exploatată în campanii ransomware. CISA o păstrează în catalogul Known Exploited Vulnerabilities și o marchează ca fiind cunoscută pentru utilizare în campanii ransomware.
Riscul este evident: instrumentele de management la distanță sunt construite tocmai pentru a executa acțiuni pe multe dispozitive. Dacă un astfel de instrument sau contul său privilegiat este compromis, aceeași eficiență operațională poate lucra în favoarea atacatorului.
Log4Shell: nu a fost o compromitere a furnizorului, dar arată problema dependențelor
Emsisoft include și Log4j în discuția despre riscul de lanț software. Tehnic, vulnerabilitatea Log4Shell, CVE-2021-44228, nu este același tip de incident ca SolarWinds: nu presupune că dezvoltatorul a introdus fără voie cod malițios într-o actualizare compromisă. Este o vulnerabilitate critică într-o bibliotecă software extrem de răspândită.
Totuși, lecția de supply chain este similară. O organizație poate folosi o componentă fără să știe direct că o folosește, deoarece biblioteca se află într-un produs cumpărat, într-un serviciu intern sau într-o altă dependență. NVD arată că vulnerabilitatea putea permite executarea de cod de la distanță în configurațiile afectate ale Log4j2. Când problema a devenit publică, una dintre dificultățile majore pentru organizații a fost simpla identificare a tuturor sistemelor care conțineau componenta vulnerabilă.
De ce un inventar software și un SBOM devin importante
Aici intră în scenă SBOM, Software Bill of Materials, adică o listă structurată a componentelor software dintr-un produs. CISA menține o bibliotecă de resurse dedicate SBOM și îl tratează ca pe un instrument de transparență pentru lanțul software.
Un SBOM nu oprește singur un atac și nici nu dovedește că un produs este sigur. Valoarea sa apare atunci când o vulnerabilitate este descoperită: organizația poate verifica mai rapid dacă produsul folosit include componenta afectată, ce versiune este prezentă și unde trebuie prioritizată remedierea.
Pentru companiile care dezvoltă software, aceeași logică se aplică la dependențe, pachete, imagini de container, pipeline-uri de build și chei de semnare. Fără o evidență coerentă, răspunsul la o vulnerabilitate critică începe cu o întrebare surprinzător de dificilă: „Unde folosim asta?”.
Securitatea furnizorilor începe înainte de semnarea contractului
Ghidul CISA „Secure by Demand” recomandă cumpărătorilor să ceară explicit securitate în procesul de achiziție. Organizațiile pot verifica modul în care furnizorul gestionează vulnerabilitățile, autentificarea, actualizările, logarea și raportarea incidentelor și pot introduce cerințe de securitate în contracte.
Ghidul CISA, NSA și ODNI pentru clienții de software merge în aceeași direcție: riscul trebuie evaluat pe tot ciclul de viață, de la definirea cerințelor și selecția furnizorului până la instalare, operare, mentenanță și scoatere din uz.
Ce merită verificat la un furnizor
- dacă există un proces public și clar de raportare și remediere a vulnerabilităților;
- dacă accesul administrativ poate fi limitat, auditat și protejat cu autentificare multifactor;
- dacă produsul oferă loguri suficiente pentru investigații;
- dacă actualizările sunt semnate și există controale de integritate în procesul de build;
- dacă furnizorul poate furniza informații despre componentele și dependențele produsului;
- ce obligații de notificare are furnizorul dacă propriile sisteme sunt compromise.
Ce poate face o companie după achiziție
Evaluarea furnizorului nu înlocuiește măsurile interne. Conturile furnizorilor și ale prestatorilor trebuie să primească doar accesul necesar, pe durata necesară. Rețelele și sistemele critice pot fi segmentate, iar accesul de la distanță trebuie monitorizat. Actualizările importante trebuie instalate prompt, dar organizația are nevoie și de capacitatea de a detecta comportamente neobișnuite chiar dacă software-ul folosit pare legitim.
Inventarul activelor, logurile centralizate și planul de răspuns la incidente sunt la fel de importante. Într-o compromitere de supply chain, primul semnal poate să nu fie un fișier evident malițios, ci o conexiune neobișnuită sau o acțiune administrativă executată de un instrument care, în mod normal, este permis.
De ce subiectul este relevant și pentru firmele mici
Riscul de supply chain nu aparține doar corporațiilor. O firmă mică poate depinde de un furnizor de contabilitate cloud, un MSP, un serviciu de backup, un plugin WordPress, o soluție de acces la distanță sau o bibliotecă open-source. Cu cât furnizorul are acces mai privilegiat sau este folosit de mai mulți clienți, cu atât compromiterea lui poate produce un efect de multiplicare mai mare.
Partea neplăcută este că o companie nu poate audita perfect fiecare linie de cod din fiecare produs cumpărat. Partea utilă este că poate decide câtă încredere acordă furnizorului, ce acces îi oferă, ce dovezi cere și cât de repede poate izola relația dacă ceva merge prost. Securitatea lanțului software este, în fond, managementul încrederii cu dovezi, nu încredere din reflex.
Surse verificate
Emsisoft — „Inside Supply Chain Attacks”, 16 iunie 2026 — https://www.emsisoft.com/en/blog/47733/inside-supply-chain-attacks/
CISA — „Active Exploitation of SolarWinds Software”, 13-14 decembrie 2020 — https://www.cisa.gov/news-events/alerts/2020/12/13/active-exploitation-solarwinds-software
CISA — „Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem”, august 2024 — https://www.cisa.gov/sites/default/files/2024-08/SecureByDemandGuide_080624_508c.pdf
CISA / NSA / ODNI — „Securing the Software Supply Chain: Recommended Practices for Customers” — https://www.cisa.gov/sites/default/files/2024-08/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_CUSTOMER_508.pdf
NIST NVD — CVE-2021-44228, Apache Log4j2 — https://nvd.nist.gov/vuln/detail/cve-2021-44228
CISA — Known Exploited Vulnerabilities Catalog, CVE-2021-30116 Kaseya VSA — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
