Implementarea SBOM Г®n Pipelines CI/CD pentru ApДѓrare: De la CycloneDX la PorИ›i Aliniate NDAA

Lista de Materiale Software (SBOM) a trecut de la artefact opțional la obligație contractuală mai rapid decât se așteptau majoritatea contractorilor de apărare. În 2021 era o recomandare îngropată în Ordinul Executiv 14028. Până în 2026 este o condiție de poartă — fiecare binar livrat unui client din SUA sau NATO trebuie să aibă un SBOM curent, semnat, lizibil de mașină atașat, iar pipeline-ul care a produs binarul trebuie să poată dovedi, la momentul auditului, că SBOM-ul a fost generat din aceleași surse, în același build, care a produs artefactul. Acest articol parcurge deciziile tehnice care determină dacă pipeline-ul dvs. CI/CD supraviețuiește acelui audit.

1. De Ce SBOM a Devenit Obligatoriu Г®n ApДѓrare

Patru fire de reglementare au convergeat. Ordinul Executiv 14028 (mai 2021) a impus furnizorilor de software federal să furnizeze SBOM-uri și a pus bazele „elementelor minime" NTIA. NDAA Secțiunea 1655 (AF2023, rafinată prin amendamentele AF2026) a extins cerințele SBOM la achizițiile de apărare, mandatând că antreprenorii principali DoD și subcontractorii să furnizeze SBOM-uri pentru orice software livrat Departamentului, cu prevederi specifice privind componentele de origine chineză și furnizorii din națiuni adversare. NIS2 a aplicat presiune paralelă pe baza de apărare a UE, cerând gestionarea documentată a riscurilor lanțului de aprovizionare pentru entitățile esențiale și importante. NIST SP 800-218 — Cadrul pentru Dezvoltarea Sigură a Software-ului (SSDF) — a codificat generarea SBOM ca practică așteptată pentru orice furnizor care se auto-atestă conform OMB M-22-18 și M-23-16.

Efectul practic este că un furnizor de software pentru apărare fără tooling SBOM în 2026 nu este un furnizor competitiv. RFP-urile includ clauze SBOM. Auditurile includ verificări SBOM. Și un SBOM lipsă este tratat la fel cum este tratat un raport de testare lipsă — ca dovadă că procesul de inginerie al furnizorului este incomplet. Vestea bună pentru echipele de inginerie este că generarea SBOM, odată instrumentată corect, este ieftină de menținut. Vestea proastă este că „instrumentată corect" ascunde o lungă listă de decizii arhitecturale, dintre care majoritatea sunt luate greșit prima dată.

2. CycloneDX vs SPDX

Două formate SBOM contează: CycloneDX (originar din OWASP, acum standard Ecma) și SPDX (originar din Linux Foundation, ISO/IEC 5962:2021). Acoperă același teren conceptual — componente, versiuni, licențe, hash-uri, relații — dar dialectele diverge în moduri care contează pentru tooling.

CycloneDX este optimizat pentru cazuri de utilizare de securitate: suport VEX nativ, cГўmpuri de vulnerabilitate de prim rang, JSON uИ™or, integrare strГўnsДѓ cu ecosistemul OWASP (Dependency-Track, dependency-check). Este formatul pe care Г®l produc implicit majoritatea echipelor de securitate. SPDX este optimizat pentru cazuri de utilizare de licenИ›e И™i provenienИ›Дѓ: limbaj mai bogat pentru expresii de licenИ›Дѓ, tradiИ›ie mai lungДѓ Г®n auditurile de conformitate open-source, И™tampila ISO pe care echipele juridice И™i de achiziИ›ii o solicitДѓ Г®n industriile reglementate.

ClienИ›ii din apДѓrare cer ambele formate. Contractele aliniate NDAA specificДѓ din ce Г®n ce mai mult „SPDX 2.3 sau ulterior, sau CycloneDX 1.5 sau ulterior", lДѓsГўnd alegerea formatului la latitudinea furnizorului — pГўnДѓ cГўnd tooling-ul downstream al clientului forИ›eazДѓ unul sau altul. Tiparul pragmatic este emiterea dualДѓ: generaИ›i un SBOM CycloneDX Г®n build pentru tooling-ul intern de vulnerabilitДѓИ›i, apoi transformaИ›i Г®n SPDX la momentul livrДѓrii folosind un convertor (cyclonedx-py, cdx2spdx sau lanИ›ul de instrumente SPDX din surse deschise). TrataИ›i unul ca sursДѓ de adevДѓr И™i celДѓlalt ca artefact derivat; pДѓstraИ›i ambele versionizate alДѓturi de binar.

3. Generarea SBOM la Build vs Post-Build

Cel mai mare factor determinant al credibilitДѓИ›ii SBOM este momentul din pipeline Г®n care este produs SBOM-ul. ExistДѓ douДѓ tabere. Scanerele post-build (Trivy, Snyk, graful nativ de dependenИ›e GitHub Г®n modul scan) ingereazДѓ o imagine de container sau un binar finalizat И™i inginerie inversДѓ componentele acestuia. Generatoarele la build-time (Syft cГўnd este conectat la build, cdxgen, tooling specific limbajului precum cargo cyclonedx, mvn cyclonedx, npm sbom) observДѓ procesul de build propriu-zis И™i emit SBOM-ul din graful de dependenИ›e rezolvat pe care l-a folosit build-ul.

Doar generarea la build-time este credibilă la audit. Motivul este simplu: un scaner post-build identifică ceea ce poate vedea — nu poate distinge între o bibliotecă care este legată static în binar și o bibliotecă care a fost adusă pentru un instrument de build-time dar nu a fost niciodată livrată. Nu poate vedea registrele private pentru care scanerele nu au credențiale. Nu poate vedea generarea de cod la momentul compilării. Un reviewer care întreabă „cum știți că acest SBOM este complet?" primește un răspuns acționabil doar când SBOM-ul a fost produs de build însuși, cu proveniență înapoi la fișierele lockfile. Scanarea post-build este o a doua opinie utilă. Nu este artefactul principal.

ГЋn practicДѓ, echipele converg pe un stack format din Syft pentru straturi OS И™i container, generatoare native de limbaj (cargo, npm, pip, mvn, go-licenses cu output CycloneDX) pentru componente sursДѓ, cdxgen cГўnd repo-urile poliglote au nevoie de o singurДѓ trecere, И™i Trivy sau exportul nativ SBOM al GitHub ca verificare Г®ncruciИ™atДѓ post-build. Pipeline-ul de build Г®mbinДѓ outputurile native de limbaj Г®ntr-un singur document CycloneDX, Г®l semneazДѓ И™i Г®l ataИ™eazДѓ la artefactul lansat.

4. Semnarea SBOM И™i Atestarea

Un SBOM nesemnat nu este o dovadă. Un reviewer nu poate verifica că a fost produs de build-ul care a produs binarul; nu poate verifica că nu a fost editat; nu poate dovedi că mediul de build a fost de încredere. Soluția este atestarea — o declarație semnată, produsă de sistemul de build, care leagă SBOM-ul de un hash specific al artefactului.

Primitivele dominante sunt sigstore/cosign pentru semnarea fДѓrДѓ cheie (certificate legate de OIDC, jurnal de transparenИ›Дѓ Г®n Rekor) И™i atestДѓrile in-toto pentru formatul declaraИ›iei. O atestare in-toto are trei pДѓrИ›i: subiectul (hash-ul artefactului atestat), tipul predicatului (ex. https://cyclonedx.org/bom sau tipul de provenienИ›Дѓ SLSA) И™i corpul predicatului (SBOM-ul Г®n sine sau provenienИ›a build-ului). Cosign semneazДѓ atestarea, o ataИ™eazДѓ ca artefact OCI alДѓturi de imaginea containerului И™i Г®mpinge semnДѓtura Г®n jurnalul de transparenИ›Дѓ Rekor.

Cadrul SLSA (Supply-chain Levels for Software Artifacts) este modelul de maturitate la care se referДѓ clienИ›ii din apДѓrare cГўnd doresc un singur numДѓr pentru a ancora cerinИ›ele lor. SLSA 1 Г®nseamnДѓ cДѓ existДѓ provenienИ›Дѓ. SLSA 2 Г®nseamnДѓ cДѓ este semnatДѓ И™i serviciul de build este gДѓzduit. SLSA 3 Г®nseamnДѓ cДѓ build-ul este izolat И™i provenienИ›a nu poate fi falsificatДѓ de proiect Г®nsuИ™i. SLSA 4 Г®nseamnДѓ revizuire de douДѓ pДѓrИ›i И™i build-uri hermetice, reproductibile. Majoritatea contractelor de apДѓrare din 2026 cer SLSA 3 ca nivel minim pentru software livrat Г®n medii operaИ›ionale; SLSA 2 este acceptabil pentru tooling-ul nedeployat. SLSA 4 rДѓmГўne rar Г®n afara celor mai clasificate sarcini de lucru.

5. Stratul de Corelare a VulnerabilitДѓИ›ilor

Un SBOM este o listă de componente; nu este, prin sine, un raport de vulnerabilități. Stratul de corelare unește SBOM-ul cu bazele de date de vulnerabilități (NVD, OSV, Baza de Date de Avize GitHub) pentru a produce o listă de vulnerabilități per artefact. Acesta este locul unde majoritatea echipelor descoperă că 80% din vulnerabilitățile raportate în SBOM-ul lor nu sunt exploatabile în contextul lor — funcția vulnerabilă nu este niciodată apelată, configurația afectată nu este niciodată activată sau calea este inaccesibilă de pe orice suprafață externă.

Modul standardizat de a comunica acest lucru este VEX (Vulnerability Exploitability eXchange). O declaraИ›ie VEX declarДѓ, pentru un CVE specific faИ›Дѓ de o versiune de produs specificДѓ, una din patru valori de stare: not_affected, affected, fixed sau under_investigation, cu o justificare (ex. vulnerable_code_not_in_execute_path). CycloneDX suportДѓ VEX nativ; SPDX Г®l suportДѓ prin formatul companion CSAF (Common Security Advisory Framework). Un client din apДѓrare care revizuieИ™te SBOM-ul dvs. se aИ™teaptДѓ sДѓ vadДѓ declaraИ›ii VEX care explicДѓ CVE-urile deschise — nu tДѓcere.

Fluxul de lucru operaИ›ional aratДѓ astfel: SBOM generat Г®n build в†’ scanare de vulnerabilitДѓИ›i faИ›Дѓ de OSV/NVD в†’ triere Г®ntr-un instrument precum Dependency-Track в†’ inginerul depune declaraИ›ie VEX cu justificare в†’ VEX ataИ™at ca atestare in-toto semnatДѓ alДѓturi de SBOM. Auditorul clientului vede o poveste coerentДѓ pentru fiecare CVE.

6. Logica PorИ›ilor CI

SBOM-urile și declarațiile VEX aplică igienă în lanțul de aprovizionare doar când pipeline-ul blochează pe ele. Poarta se află între „build reușit" și „artefact de lansare promovat". Echipele moderne scriu poarta ca o politică în Rego (Open Policy Agent) sau Kyverno, evaluată față de inputurile SBOM și VEX.

O politică funcțională aplică patru reguli. Una: niciun CVE critic fără o justificare VEX. Două: nicio componentă dintr-o listă de familii de licențe interzise (AGPL în livrabile proprietare, orice cu o clauză de origine controlată la export din SUA). Trei: nicio componentă din registrele națiunilor sancționate (aici trăiește NDAA 1655 — pachetele de origine chineză sunt marcate automat). Patru: SBOM-ul trebuie semnat, proveniența build-ului trebuie să revendice SLSA 3 sau mai mare, și intrarea în jurnalul de transparență Rekor trebuie să existe.

Derogările sunt locul unde majoritatea politicilor eșuează în practică. O înlocuire generală „ignorați acest CVE pentru totdeauna" este tiparul de eșec la audit. Tiparul care supraviețuiește auditului este derogare cu justificare și expirare: fișierul de derogare trăiește în repo, este revizuit într-un pull request, numește CVE-ul și artefactul, conține o justificare scrisă (aceleași câmpuri de justificare VEX) și are o dată de expirare. Pipeline-ul acceptă derogarea doar cât timp nu a expirat. Auditorii adoră acest tipar pentru că produce un traseu scris al deciziilor de risc; inginerii îl tolerează pentru că reprezintă muncă finită.

7. Livrarea cДѓtre Client

SBOM-ul nu este doar un artefact de build — este un livrabil contractual. Contractele de apărare din 2026 includ în mod obișnuit clauze privind formatul SBOM, semnarea, mecanismul de livrare și cadența de actualizare. Negocierea formatului are loc de obicei la redactarea contractului: furnizorul propune CycloneDX 1.5 JSON, clientul contracarează cu SPDX 2.3 deoarece instrumentul său downstream o impune, iar furnizorul se angajează la emitere duală. Livrarea se face de obicei printr-un registru sau portal controlat de client — niciodată prin atașamente de e-mail, pe care politica de securitate a informațiilor a clientului le interzice.

Obligația de actualizare recurentă este clauza pe care majoritatea furnizorilor o subestimează. Contractele aliniate NDAA cer de obicei un SBOM actualizat cu fiecare lansare de patch, fiecare drop de întreținere trimestrial și în termen de 72 de ore de la orice divulgare de CVE în domeniu. Dacă procesul de lansare durează o săptămână, nu puteți respecta un termen de 72 de ore. Soluția este automatizarea emiterii SBOM la fiecare lansare, inclusiv la lansările de patch, astfel încât SBOM-ul să fie întotdeauna curent cu binarul pe care îl rulează clientul. Furnizorii care încearcă să regenereze SBOM-urile manual după lansare ajung să explice lacunele reviewerilor de acreditare — vezi și cum constrângerile de autorizare și personal afectează ce poate livra echipa dvs.

8. SupravieИ›uirea Auditului

Reviewerul de acreditare sosește. Pune trei întrebări. Arătați-mi SBOM-ul pentru versiunea 2.4.1, pe care o rulăm în producție. Registrul dvs. returnează documentul CycloneDX semnat cu o atestare in-toto care indică hash-ul binarului instalat de client. Arătați-mi declarațiile VEX pentru fiecare CVE „ridicat" din acel SBOM. Registrul dvs. returnează pachetul VEX, cu justificări și date. Arătați-mi cum ați ști, astăzi, dacă un nou CVE ar fi divulgat față de orice componentă din acest SBOM. Îi arătați scanarea continuă care rulează față de corpusul SBOM și SLA-ul privind notificarea clientului.

Pipeline-ul care răspunde clar la acele trei întrebări este pipeline-ul care supraviețuiește. Pipeline-ul care nu poate — pentru că SBOM-ul a fost generat post-hoc, sau declarațiile VEX trăiesc într-o foaie de calcul, sau nimeni nu urmărește divulgările CVE față de SBOM-urile lansate — este pipeline-ul care pierde contractul la reînnoire. Investiția este finită; consecința de a nu o face nu este. Pentru cadrul mai larg al lanțului de aprovizionare, vedeți prezentarea noastră generală SBOM în software pentru apărare, ghidul complet pentru securitatea cibernetică în apărare și analiza aprofundată DevSecOps + zero trust care se află un nivel deasupra acestei lucrări de pipeline.