Situatie
Aplicațiile moderne nu sunt construite doar din cod scris de echipa care le dezvoltă. O aplicație poate utiliza zeci sau sute de componente externe: biblioteci, framework-uri, pachete, module, imagini Docker și alte servicii. Acest lucru accelerează dezvoltarea, dar introduce un risc important: dacă una dintre componente este compromisă, problema poate ajunge automat în aplicația care o folosește.
Un atac de tip Software Supply Chain apare atunci când un atacator introduce cod malițios sau exploatează o vulnerabilitate într-o componentă utilizată de alte aplicații.
Schema poate fi simplificată astfel:
Atacator → componentă compromisă → aplicație → sistemul companiei
Problema principală este că aplicația finală poate părea perfect legitimă. Componenta compromisă poate proveni dintr-o sursă utilizată în mod normal de dezvoltatori.
Există mai multe puncte în care lanțul software poate fi compromis.
Bibliotecă externă compromisă
O bibliotecă utilizată de aplicație poate fi modificată pentru a executa cod nedorit. De exemplu, o aplicație folosește:
Library-X 2.4.1
Dezvoltatorul descarcă versiunea respectivă și o introduce în proiect. Dacă acea versiune a fost compromisă, codul malițios ajunge în aplicație fără ca dezvoltatorul să-l fi scris.
Pachet fals
Un atacator poate crea un pachet cu un nume foarte asemănător cu unul legitim.
De exemplu:
package-original
package-orignal
O simplă greșeală de scriere poate duce la instalarea pachetului greșit.
Cont de dezvoltator compromis
Dacă atacatorul obține acces la contul unui dezvoltator, poate modifica repository-ul și introduce cod malițios. Problema poate trece neobservată dacă modificarea arată ca un update normal.
Pipeline CI/CD compromis
CI/CD este sistemul care automatizează compilarea, testarea și distribuirea aplicației. Dacă pipeline-ul este compromis, atacatorul poate modifica rezultatul final chiar dacă repository-ul pare curat.
Solutie
O soluție eficientă este construirea unui sistem automat care verifică software-ul înainte să fie permis în producție.
Principiul este:
COD
↓
VERIFICARE DEPENDENȚE
↓
SCANARE VULNERABILITĂȚI
↓
GENERARE SBOM
↓
VERIFICARE INTEGRITATE
↓
SEMNARE
↓
BUILD
↓
DEPLOY
Dacă una dintre verificări eșuează, procesul se oprește.
Astfel, o componentă suspectă nu mai poate ajunge automat în sistemul final.
Primul mecanism este scanarea automată a tuturor bibliotecilor utilizate.
Sistemul trebuie să identifice:
- numele componentei;
- versiunea;
- sursa;
- dependențele indirecte;
- vulnerabilitățile cunoscute;
- componentele învechite.
De exemplu:
Application
├── Library A 2.1
├── Library B 4.5
│ └── Library C 1.3
└── Library D 7.2
Este importantă și verificarea dependențelor indirecte.
Un dezvoltator poate instala doar Library B, dar aceasta poate instala automat Library C.
Prin urmare, trebuie verificat întregul arbore de dependența.
Reguli automate de blocare
- Scanarea singură nu este suficientă
- Sistemul trebuie să poată lua o decizie
De exemplu:
LOW → permite build-ul
MEDIUM → permite build-ul + avertizare
HIGH → necesită verificare
CRITICAL → blochează build-ul
Astfel, dacă este detectată o vulnerabilitate critică:
BUILD
↓
SCAN
↓
CRITICAL VULNERABILITY
↓
BUILD BLOCKED
Aplicația nu mai poate fi distribuită până când problema nu este rezolvată.
SBOM
Un alt element important este SBOM – Software Bill of Materials. Acesta reprezintă o listă completă a componentelor dintr-o aplicație.
De exemplu:
Application: CompanyApp
Library A
Version: 2.1.4
Library B
Version: 4.5.0
Library C
Version: 1.3.2
Library D
Version: 7.2.1
Avantajul este că organizația știe exact ce conține fiecare versiune a aplicației. Dacă apare ulterior o problemă cu Library C, sistemul poate identifica rapid toate aplicațiile care folosesc:
Library C < 1.4.0
și poate începe actualizarea acestora. Fără o evidență a componentelor, identificarea poate dura mult mai mult.
Verificarea integrității
O componentă software trebuie verificată nu doar după nume și versiune.
Se poate utiliza un hash criptografic.
De exemplu:
Library.exe
↓
SHA-256
↓
A83F…92BD
La instalare sau deployment se calculează din nou hash-ul.
Dacă rezultatul este diferit:
Hash original:
A83F…92BD
Hash actual:
91CE…44AF
componenta a fost modificată și trebuie respinsă.
Semnarea digitală
Pentru un nivel suplimentar de protecție, componentele și build-urile pot fi semnate digital.
Procesul poate fi:
SOURCE CODE
↓
BUILD
↓
HASH
↓
DIGITAL SIGNATURE
↓
REPOSITORY
La deployment:
SOFTWARE
↓
SIGNATURE CHECK
↓
VALID → CONTINUE
INVALID → BLOCK
Dacă un atacator modifică fișierul după ce acesta a fost semnat, verificarea semnăturii va eșua.
Protejarea pipeline-ului CI/CD
- Pipeline-ul trebuie protejat la fel de bine ca aplicația.
- Accesul trebuie acordat numai persoanelor și sistemelor care au nevoie de el.
De exemplu:
Developer
↓
Git Repository
↓
Automated Tests
↓
Security Scan
↓
Build
↓
Approval
↓
Production
Un dezvoltator nu ar trebui să poată modifica direct toate etapele pipeline-ului.
Pentru operațiunile importante se poate solicita:
- autentificare multifactor;
- aprobare suplimentară;
- drepturi separate;
- verificarea modificărilor;
- jurnalizarea activității.
Izolarea componentelor
O componentă externă nu trebuie să primească automat acces la întregul sistem. Aplicațiile și serviciile pot fi izolate folosind containere, permisiuni și segmentarea rețelei.
De exemplu:
Application
|
+—- Database
|
+—- API
|
+—- External Library
Dacă biblioteca externă este compromisă, accesul ei trebuie limitat doar la ceea ce este necesar.
Astfel, chiar dacă atacul reușește, impactul este redus.
Actualizarea automată
Componentele vulnerabile trebuie înlocuite cu versiuni sigure. Un sistem automat poate verifica periodic dependențele:
MONDAY
Library A → OK
Library B → OK
Library C → VULNERABLE
Sistemul poate genera automat o alertă:
Library C 1.2.0
CRITICAL
Update available: 1.2.4
După testarea noii versiuni:
1.2.0
↓
1.2.4
↓
Security Scan
↓
Tests
↓
Deploy
Soluția completă
O implementare practică poate arăta astfel:
DEVELOPER
|
↓
GIT REPOSITORY
|
↓
DEPENDENCY SCAN
|
↓
VULNERABILITY SCAN
|
┌───────┴───────┐
↓ ↓
SAFE VULNERABLE
| |
↓ ↓
SBOM BLOCK
|
↓
SECURITY CHECK
|
↓
BUILD
|
↓
DIGITAL SIGNATURE
|
↓
APPROVED PACKAGE
|
↓
DEPLOYMENT
|
↓
PRODUCTION
În acest model, fiecare etapă reprezintă un punct de control.
Dacă o componentă este compromisă, există mai multe șanse ca aceasta să fie detectată înainte de a ajunge în producție.
Ce se întâmplă dacă atacul a trecut de verificări
Niciun sistem nu poate garanta detectarea tuturor atacurilor. De aceea trebuie să existe și un mecanism de răspuns.
Dacă se descoperă că:
Library X 3.2.1
a fost compromisă, sistemul trebuie să poată identifica automat:
Aplicația A → folosește X 3.2.1
Aplicația B → folosește X 3.2.1
Aplicația C → folosește X 3.2.1
Apoi:
- componenta este blocată;
- deployment-urile sunt oprite;
- aplicațiile afectate sunt identificate;
- se instalează versiunea sigură;
- se generează un nou build;
- se rulează verificările;
- versiunea nouă este semnată;
- aplicația este redeployată.
Acest proces reduce foarte mult timpul dintre descoperirea problemei și remedierea ei.
Rezultatul
Un sistem bine configurat nu încearcă să garanteze că niciodată nu va exista o componentă compromisă.
Obiectivul este să facă următoarele:
- Să știe ce componente sunt utilizate
- Să verifice automat componentele
- Să blocheze componentele periculoase
- Să verifice integritatea software-ului
- Să limiteze accesul componentelor
- Să identifice rapid aplicațiile afectate
- Să permită înlocuirea rapidă a componentelor compromise.
Practic, securitatea este mutată din etapa finală a procesului în fiecare etapă a dezvoltării.
Software Supply Chain Attacks sunt dificil de eliminat complet deoarece aplicațiile moderne depind de numeroase componente externe. Totuși, riscul poate fi redus considerabil printr-un sistem automatizat format din scanarea dependențelor, verificarea vulnerabilităților, SBOM, hash-uri, semnături digitale, controlul accesului, izolarea componentelor și verificarea pipeline-ului CI/CD.
Cea mai importantă idee este ca software-ul să nu fie considerat sigur doar pentru că provine dintr-o sursă cunoscută. Fiecare componentă trebuie verificată înainte de a fi introdusă în aplicație și înainte de a ajunge în producție. În cazul în care o componentă compromisă trece de primele verificări, existența unui SBOM și a unui sistem centralizat de monitorizare permite identificarea rapidă a tuturor aplicațiilor afectate și înlocuirea componentei.
Astfel, un atac care inițial ar putea afecta un număr mare de sisteme poate fi detectat, izolat și remediat automat sau semi-automat, reducând semnificativ impactul asupra infrastructurii IT.
Leave A Comment?