Un binar de apărare dislocat în teren este capătul unui lung lanț de încredere. A început ca un cod sursă scris de un dezvoltator, a trecut prin zeci de dependențe open source, a fost compilat pe un server de build, împachetat, semnat și promovat într-un registru de lansare înainte de a ajunge vreodată într-o rețea operațională. Fiecare verigă din acel lanț este o țintă. Adversarii statali au demonstrat în mod repetat că cea mai ieftină cale de intrare într-o rețea de apărare întărită nu este ușa din față – ci sistemul de build sau o dependență de încredere, compromisă în amonte astfel încât codul malițios să fie livrat, semnat și binecuvântat de însuși pipeline-ul victimei. Securitatea lanțului de aprovizionare software este disciplina de a face fiecare verigă din acel lanț verificabilă, astfel încât un artefact dislocat în teren să poată fi trasat criptografic înapoi la o sursă revizuită printr-un build rezistent la falsificare.
Modelul de amenințare al lanțului de aprovizionare de apărare
Securitatea lanțului de aprovizionare comercial și securitatea lanțului de aprovizionare de apărare împărtășesc același vocabular, dar un adversar diferit. O echipă comercială se îngrijorează de o dependență vulnerabilă sau de o scurgere accidentală de secret. O echipă de apărare trebuie să presupună un actor bine finanțat care va petrece luni de zile prepoziționând un implant: otrăvind un pachet open source popular, compromițând un runner de build sau substituind un compilator falsificat. Intruziunea SolarWinds – în care un implant în sistemul de build a inserat o ușă din spate într-o actualizare de produs semnată legitim – este exemplul canonic și a remodelat felul în care achizițiile de apărare tratează originea software-ului.
Suprafața de amenințare se descompune în patru zone. Zona sursă acoperă sistemul de control al versiunilor și persoanele cu acces de commit. Zona dependențe acoperă fiecare pachet de la terți tras în build, direct și tranzitiv. Zona build acoperă serviciul de build, runnerele sale și lanțul de instrumente (toolchain). Zona distribuție acoperă semnarea, registrul de lansare și desfășurarea. Un cadru de control al lanțului de aprovizionare de apărare trebuie să adreseze toate cele patru – întărirea uneia în timp ce alta rămâne deschisă pur și simplu mută punctul de intrare al adversarului.
Ceea ce face acest lucru mai dificil pentru apărare decât pentru software-ul comercial este modelul de consecințe. O actualizare SaaS comercială compromisă poate fi anulată; o încărcare de firmware compromisă pe o stație radio dislocată în teren sau o sarcină utilă de război electronic poate fi inaccesibilă, persistentă și catastrofală din punct de vedere operațional. Costul unui singur artefact falsificat este asimetric, motiv pentru care cadrul trebuie să fie preventiv mai degrabă decât reactiv – scopul este de a face un artefact malițios incapabil să treacă vreodată de pipeline, nu de a-l detecta după desfășurare. Controalele de mai jos sunt secvențiate de la sursă la dislocarea în teren tocmai pentru ca fiecare zonă să fie închisă înainte ca următoarea să-i moștenească ieșirile.
SLSA: un model de maturitate pentru integritatea build-ului
SLSA – Supply-chain Levels for Software Artifacts – este cel mai larg adoptat cadru pentru a raționa despre integritatea build-ului. Este în mod deliberat incremental, definind niveluri progresive astfel încât o organizație să poată măsura unde se află și care este următoarea îmbunătățire concretă.
Nivelul 1 cere doar ca procesul de build să producă proveniență: o descriere a felului în care a fost realizat artefactul. Acest lucru singur prinde greșeli și oferă o bază pentru analiză, dar proveniența nu este încă protejată împotriva falsificării.
Nivelul 2 cere un serviciu de build găzduit care generează și semnează proveniența. Deoarece un serviciu, mai degrabă decât o stație de lucru de dezvoltator, produce atestarea, falsificarea de către o mașină individuală compromisă devine detectabilă.
Nivelul 3 întărește platforma de build însăși: proveniența devine imposibil de falsificat, iar build-urile rulează în medii izolate, efemere, care nu poartă stare între rulări. Acesta este nivelul la care o dependență compromisă sau un script de build malițios nu mai poate rescrie în tăcere ceea ce raportează proveniența. Pentru software-ul de misiune, SLSA Nivelul 3 ar trebui tratat ca bază, nu ca aspirație.
Postura cu cel mai înalt grad de asigurare – descrisă istoric ca Nivelul 4 și exprimată acum prin cerințe suplimentare de track – adaugă revizuirea de către două persoane a fiecărei modificări și build-uri ermetice, reproductibile. Un build reproductibil permite unei părți independente să reconstruiască aceeași sursă și să confirme, bit cu bit, că obține același artefact. Pentru componentele adiacente armamentului sau pentru cele criptografice, reproductibilitatea este cea mai puternică apărare disponibilă împotriva unui lanț de instrumente falsificat.
Proveniența build-ului: cum a fost realizat artefactul
Proveniența este inima asigurării lanțului de aprovizionare și este frecvent confundată cu semnarea. O semnătură pe un binar dovedește cine l-a lansat și că nu s-a schimbat de când semnătura a fost aplicată. Nu spune nimic despre faptul dacă build-ul care a produs binarul a fost demn de încredere. Dacă un adversar compromite runnerul de build, poate produce un artefact malițios care este apoi semnat perfect legitim – semnătura este validă, artefactul este otrăvit.
Proveniența închide acel gol. O atestare de proveniență este o înregistrare semnată, lizibilă de mașină, care descrie commit-ul sursă, identitatea builderului, parametrii de build și sumele criptografice (digests) ale fiecărei intrări și ieșiri. Formatul larg utilizat este atestarea in-toto, care captează acest lucru ca o declarație structurată pe care platforma de build – nu dezvoltatorul – o semnează. Când un verificator verifică ulterior artefactul, confirmă nu doar semnătura, ci și că proveniența numește repozitoriul sursă așteptat, builderul așteptat și un commit care a trecut prin revizuire.
Ce verifică un verificator
O verificare a provenienței la momentul desfășurării răspunde la o întrebare precisă: a fost acest artefact exact construit din sursa și procesul pe care le așteptăm? Verificatorul compară suma (digest) artefactului față de suma înregistrată în proveniență, confirmă că proveniența a fost semnată cu cheia platformei de build de încredere și afirmă că identitatea builderului și URI-ul sursei se potrivesc cu o listă de permise (allowlist). O nepotrivire – un artefact a cărui proveniență numește un builder necunoscut sau a cărui sumă nu se potrivește – este respinsă înainte de a ajunge într-un mediu operațional. Acesta este controlul care ar fi semnalat o substituire în stil SolarWinds.
Proveniența permite, de asemenea, un răspuns la incidente care altfel ar fi imposibil. Când o nouă vulnerabilitate este divulgată într-un instrument de build sau o dependență, o organizație cu proveniență completă poate interoga exact care artefacte dislocate în teren au fost produse cu componenta afectată, de către care builder și din care commit – transformând o estimare frenetică într-un răspuns precis privind raza exploziei. Proveniența păstrată pe durata operațională a unui artefact nu este, prin urmare, doar o poartă de pre-desfășurare, ci un activ de audit care se amortizează ani de zile după build.
Semnarea artefactelor în pipeline-urile de apărare
Semnarea rămâne esențială; pur și simplu nu este suficientă pe cont propriu. Practica modernă este semnarea fără cheie (keyless) susținută de un jurnal de transparență: o cheie efemeră este emisă față de o identitate de sarcină de lucru verificată, folosită pentru a semna artefactul și atestările sale, iar evenimentul de semnare este înregistrat într-un jurnal de transparență public sau privat de tip append-only. Acest lucru elimină povara operațională și riscul cheilor de semnare cu viață lungă care stau pe serverele de build.
Pentru componentele cu cel mai înalt grad de asigurare – module criptografice, încărcătoare de boot (bootloaders), orice legat de o rădăcină hardware de încredere – programele de apărare folosesc chei susținute hardware păstrate într-un modul de securitate hardware (HSM). Cheia privată nu părăsește niciodată HSM-ul; operațiunile de semnare sunt efectuate în interiorul lui. Aceasta se asociază natural cu secure boot, în care firmware-ul dispozitivului verifică semnătura fiecărei etape înainte de a o executa, extinzând lanțul de încredere al lanțului de aprovizionare până la siliciu.
Verificarea dependențelor și SBOM-ul
Majoritatea codului din orice aplicație de apărare modernă nu este scris de program – este tras ca dependențe open source. Verificarea acelor dependențe este, prin urmare, controlul cu cel mai mare efect de levier din întregul lanț. Mai multe practici se cumulează aici.
Fixarea și hash-uirea. Fiecare dependență este fixată la o versiune specifică și la un hash criptografic, astfel încât arborele de dependențe rezolvat să fie determinist. Un build nu poate deriva în tăcere către o versiune nouă, malițioasă, a unui pachet, deoarece hash-ul nu s-ar mai potrivi.
Oglindirea internă. Pachetele aprobate sunt oglindite într-un registru intern, iar build-urile trag doar din acea oglindă – niciodată direct dintr-un registru public la momentul build-ului. Aceasta oferă programului un punct de control de validare controlat și rupe dependența build-ului de accesibilitatea internetului, ceea ce este obligatoriu pentru mediile izolate fizic (air-gapped) și clasificate.
Scanarea de vulnerabilități. Fiecare dependență este scanată față de date de vulnerabilități precum baza de avertizări OSV, iar rezultatele controlează promovarea. Ieșirea enumerării fiecărei componente tranzitive este o listă de materiale software (software bill of materials). Pentru cerințele determinate de achiziții acum atașate acelui artefact, vezi analiza noastră despre lista de materiale software (SBOM) pentru apărare. SBOM-ul este generat într-un format standard – CycloneDX sau SPDX – și atașat la artefact ca atestare semnată, astfel încât călătorește împreună cu binarul.
Idee-cheie: Semnarea și proveniența răspund la întrebări diferite, iar un pipeline de apărare are nevoie de ambele. Semnarea dovedește că un artefact nu s-a schimbat de când editorul l-a lansat. Proveniența dovedește că artefactul a fost construit din sursa și procesul pe care le aștepți. Un pipeline care semnează, dar nu verifică proveniența, va semna fără probleme – și va disloca în teren – un artefact malițios produs de un runner de build compromis. Semnătura va fi perfect validă. Verificarea provenienței la poarta de admitere este controlul care îl prinde.
Aplicarea politicilor: poarta de admitere
Niciunul dintre aceste controale nu contează dacă nu blochează un artefact neconform de la a fi dislocat în teren. Punctul de aplicare este poarta de admitere – momentul imediat anterior promovării unui artefact într-un registru de lansare sau desfășurării sale într-un mediu operațional. La această poartă un motor de politici efectuează un set de verificări obligatorii: verifică semnătura artefactului, validează proveniența față de identitățile așteptate de sursă și builder, verifică SBOM-ul față de datele de vulnerabilitate și o listă de componente interzise și confirmă că modificarea a trecut prin revizuirea necesară de către două persoane.
Regula critică de proiectare este că politica trebuie să blocheze, nu doar să semnaleze. Un eșec comun este de a rula scanere mai devreme în pipeline care emit avertismente, în timp ce etapa de promovare nu are nicio poartă fermă – astfel încât un artefact semnalat tot se livrează atunci când un inginer face override sub presiunea termenului-limită. Poarta de admitere trebuie să eșueze închis (fail closed): dacă proveniența nu poate fi verificată, artefactul nu se desfășoară. Înglobarea acestor porți ca cod, revizuit și controlat în versiune ca orice altă etapă de pipeline, este extensia naturală a unei practici DevSecOps pentru apărare, unde controalele de securitate sunt parte din fiecare sprint mai degrabă decât un audit de pre-lansare.
Operarea lanțului în medii clasificate
Într-o enclavă izolată fizic (air-gapped) sau clasificată, întregul lanț trebuie să ruleze fără acces la internet. Oglinzile interne dețin dependențele validate, serviciul de build și jurnalul de transparență rulează în interiorul enclavei, iar cheile de verificare sunt distribuite prin canale aprobate. Actualizările oglinzii de dependențe sosesc prin transferuri cross-domain controlate, fiecare purtând propria proveniență astfel încât enclava să poată re-verifica originea înainte de a admite un pachet. Proiectarea lanțului de aprovizionare pentru operare offline din primul sprint – mai degrabă decât retroadaptarea sa – este ceea ce face diferența între un cadru de control care supraviețuiește acreditării și unul care se prăbușește la contactul cu o desfășurare clasificată reală.
Construiește un pipeline de livrare de apărare verificabil
Corvus SENSE aduce proveniența, semnarea artefactelor și aplicarea politicilor bazate pe SBOM într-o singură imagine a lanțului tău de aprovizionare software – astfel încât fiecare artefact dislocat în teren să fie trasabil la o sursă revizuită printr-un build rezistent la falsificare, deopotrivă în rețele conectate și izolate fizic (air-gapped).
Această analiză a fost pregătită de inginerii Corvus Intelligence, care construiesc software critic pentru misiune pentru organizații de apărare și guvernamentale. Află despre echipa noastră →