Lista de Materiale Software (SBOM) pentru Apărare: Ce Solicită Acum Achizițiile

O Listă de Materiale Software (SBOM) este un inventar citibil de mașini al tuturor componentelor software, bibliotecilor și dependențelor care alcătuiesc un produs software. Este, în esență, echivalentul software al unei liste de materiale de fabricație fizică: o listă structurată a fiecărui ingredient care a intrat în produsul final, inclusiv versiunea fiecărei componente și vulnerabilitățile cunoscute asociate cu fiecare versiune la momentul livrării.

Cerințele SBOM în achizițiile de apărare nu mai sunt emergente — ele sunt prezente. Ordinul Executiv SUA 14028 (mai 2021) a solicitat livrarea SBOM pentru software vândut guvernului federal. Strategia de Modernizare a Software-ului DoD menționează SBOM ca o cerință de securitate a lanțului de aprovizionare. Actul UE privind Reziliența Cibernetică (CRA), care a intrat în vigoare în 2024, va solicita SBOM-uri pentru produsele cu elemente digitale vândute pe piața UE — acoperind o gamă largă de produse adiacente apărării. Furnizorii de software de apărare care nu pot produce SBOM-uri conforme vor fi descalificați din oportunitățile de achiziție.

Ce este un SBOM: inventar de componente citibil de mașini

Un SBOM enumeră fiecare componentă software inclusă într-un produs software, fie direct (o bibliotecă pe care echipa de dezvoltare a adăugat-o explicit ca dependență) fie tranzitiv (o bibliotecă de care una dintre acele dependențe directe depinde la rândul ei). Pentru o aplicație software modernă construită cu componente open-source standard, arborele de dependențe tranzitive conține de obicei sute până la mii de componente — mult prea multe pentru a fi urmărite manual.

Elementele minime NTIA (National Telecommunications and Information Administration) pentru un SBOM definesc ce trebuie să conțină fiecare intrare de componentă: numele furnizorului componentei, numele componentei, versiunea componentei, alți identificatori unici (URL de pachet sau hash), relația de dependență (cum se potrivește componenta în arborele mai larg de componente), autorul datelor SBOM și un marcaj de timp.

Valoarea operațională a unui SBOM este utilizarea sa pentru gestionarea vulnerabilităților. Când o nouă vulnerabilitate critică este dezvăluită — Log4Shell (CVE-2021-44228) este exemplul canonic — o organizație cu SBOM-uri pentru tot software-ul său implementat poate interoga imediat acele SBOM-uri pentru a identifica ce sisteme includ Log4j și la ce versiune, prioritizând remedierea. O organizație fără SBOM-uri trebuie să investigheze manual fiecare sistem, ceea ce într-un mediu mare de apărare poate dura săptămâni și lasă sistemele critice nepatcuite în interimar.

Factori de reglementare: EO 14028, NTIA și Actul UE privind Reziliența Cibernetică

Ordinul Executiv SUA 14028 (Îmbunătățirea Cybersecurității Națiunii) a fost semnat în mai 2021 în urma atacului asupra lanțului de aprovizionare SolarWinds, care a demonstrat cum un singur pipeline de actualizare software compromis putea compromite mii de organizații din aval, inclusiv multiple agenții federale. Secțiunea 4 a ordinului solicită în mod specific că furnizorii de software care vând guvernului federal să furnizeze SBOM-uri. Orientările OMB de implementare a EO 14028 au strâns progresiv cerințele SBOM pentru contractanții federali.

Elementele minime NTIA (publicate în iunie 2021) furnizează standardul de bază pentru ceea ce constituie un SBOM conform. Aceste elemente sunt minimul — contractele pot specifica cerințe suplimentare, cum ar fi formate SBOM specifice, includerea dependențelor tranzitive la o adâncime specificată sau integrarea cu sistemele de consiliere pentru vulnerabilități.

Actul UE privind Reziliența Cibernetică se aplică produselor cu elemente digitale plasate pe piața UE. Produsele din categoriile „importante" și „critice" (inclusiv multe produse hardware și software adiacente apărării) se confruntă cu evaluări de conformitate terță parte obligatorii. Deși CRA nu mandatează explicit SBOM-urile în toate cazurile, cerințele esențiale de cybersecuritate pe care le definește — gestionarea vulnerabilităților, actualizările de securitate, dezvăluirea informațiilor despre componente relevante pentru securitate — sunt cel mai practic îndeplinite prin generarea și întreținerea SBOM. Programele de apărare UE și produsele vândute pe piețele UE ar trebui să planifice cerințele SBOM ca parte a conformității CRA.

Formate SBOM: SPDX vs CycloneDX

Două formate domină ecosistemul SBOM: SPDX și CycloneDX. Ambele sunt standarde deschise, ambele sunt citibile de mașini și ambele pot reprezenta aceleași date de componente de bază. Alegerea dintre ele este în primul rând o funcție a suportului pentru instrumente și a accentului cazului de utilizare.

SPDX (Software Package Data Exchange) este un standard ISO (ISO/IEC 5962:2021). A fost dezvoltat inițial de Linux Foundation și are rădăcinile cele mai adânci în comunitatea de conformitate a licențelor open-source — SPDX a început ca un format de urmărire a licențelor și a fost extins pentru a acoperi cazurile de utilizare de securitate. SPDX este susținut de o gamă largă de instrumente și are o integrare puternică cu specificația elementelor minime NTIA. Documentele SPDX pot fi serializate ca tag-value, JSON, YAML sau RDF-XML.

CycloneDX este un standard OWASP proiectat special pentru cazurile de utilizare de securitate de la început. CycloneDX are un suport mai puternic pentru integrarea datelor de vulnerabilitate (documente VEX, descrise mai jos), suportă tipuri de artefacte suplimentare (servicii, hardware, modele de învățare automată) și are un ecosistem de instrumente mai activ orientat specific spre fluxuri de lucru DevSecOps. CycloneDX este serializat ca JSON sau XML.

Pentru programele de apărare, orientarea practică este: ambele formate sunt acceptabile conform orientărilor SBOM SUA actuale; verificați cerințele de format specifice din documentația contractului și programului; generați ambele dacă suportul instrumentelor permite (Syft, descris mai jos, generează ambele); și asigurați-vă că platforma dvs. de management SBOM poate consuma formatul pe care îl produceți.

Generarea SBOM în CI/CD: Syft și cdxgen

Syft (de la Anchore) este instrumentul de generare SBOM open-source principal pentru imagini de containere și sisteme de fișiere. Suportă formate de ieșire SPDX și CycloneDX și gestionează o gamă largă de ecosisteme de pachete: npm, PyPI, Maven/Gradle, NuGet, module Go, RubyGems, Cargo, Alpine APK, Debian/Ubuntu DPKG și RPM. Într-un pipeline CI/CD, Syft rulează ca pas de etapă de build după ce imaginea de container este construită, dar înainte de a fi trimisă în registru, generând un SBOM care este publicat ca artefact de build alături de imagine.

cdxgen este instrumentul de generare CycloneDX menținut de OWASP, cu suport deosebit de puternic pentru depozitele poliglote (depozite care conțin cod în mai multe limbi). cdxgen traversează manifestele de dependențe ale mai multor manageri de pachete simultan și produce un SBOM CycloneDX unificat care acoperă toate componentele din toate ecosistemele de limbi din depozit. Aceasta este deosebit de relevantă pentru proiectele software de apărare care combină, de exemplu, un backend Python cu un frontend TypeScript și middleware Java.

VEX: Schimbul de Exploatabilitate a Vulnerabilităților

Un SBOM vă spune ce componente sunt prezente. Un document VEX (Vulnerability Exploitability eXchange) vă spune dacă vulnerabilitățile din acele componente sunt de fapt exploatabile în contextul specific al produsului. Distincția contează deoarece analiza compoziției software produce de obicei liste lungi de CVE-uri în dependențe tranzitive care nu sunt de fapt exploatabile: calea de cod vulnerabilă nu este accesibilă în aplicație, componenta vulnerabilă este utilizată într-un context numai de testare, sau configurația care permite vulnerabilitatea nu este prezentă în produsul implementat.

Statusurile VEX pentru fiecare pereche CVE-componentă sunt: „afectat" (vulnerabilitatea este prezentă și exploatabilă), „neafectat" (vulnerabilitatea există în componentă, dar nu este exploatabilă în acest produs), „remediat" (o versiune remediată este disponibilă și implementată) sau „în investigare" (exploatabilitatea nu a fost încă determinată). Contractele de achiziții de apărare necesită din ce în ce mai mult atât un SBOM, cât și un document VEX ca o livrabilă completă de securitate a lanțului de aprovizionare. CISA a publicat orientări privind formatele VEX și conținutul minim necesar.