La 29 iulie 2026, CISA a publicat „Elementele minime pentru 2026” Software Bill of Materials (SBOM), înlocuind standardul de referință al NTIA în vigoare din 2021, elaborat în colaborare cu NSA, FBI și 15 agenții internaționale de securitate cibernetică.
„Elementele minime pentru un manifest de componente software ( Software ) din 2026”Bill of Materials (SBOM) reprezintă specificația actualizată a CISA privind datele pe care trebuie să le conțină un SBOM, iar cea mai importantă modificare este de natură structurală, nu numerică: elementele din 2026 nu interzic generarea SBOM-urilor pe baza manifestelor sursă, dar impun autorilor să declare modul în care a fost generat SBOM-ul, să calculeze hash-ul artefactului executabil și să eticheteze fiecare câmp pe care nu l-au putut completa. Un SBOM bazat exclusiv pe manifest își dezvăluie acum propriile lacune într-un format lizibil de către mașini.
MetaDefender Software Supply Chain este platforma de securitate a lanțului de aprovizionare cu software a companiei OPSWAT, concepută pentru a analiza artefacte, fișiere binare și straturi de imagini de containere — exact categoria de date pe care o impun acum noile cerințe privind hash-urile, contextul de generare și acoperirea.
Pe scurt
- 17 câmpuri de date — 9 metadate SBOM, 8 date privind componentele
- 6 practici și procese
- 10 câmpuri noi, 8 actualizări majore, 1 eliminat (Controlul accesului, integrat în Distribuție și Livrare)
- Se aplică tuturor programelor software, „inclusiv programelor software open source, programelor software de inteligență artificială și serviciilor SaaS”
- Nu este vorba de cerințe noi — ci de o îmbunătățire a modului în care organizațiile generează și solicită SBOM-uri
Modificările din 2026 ale SBOM-ului care sunt cele mai greu de respectat pentru SBOM-urile bazate exclusiv pe sursă
1. Valoarea hash a componentei necesită artefactul executabil
„Valoarea hash a componentei” și „Algoritmul hash al componentei” precizează exact ce anume este supus procesului de hash: „rezultatul obținut prin aplicarea unui algoritm hash criptografic asupra unui artefact al unei componente executabile”. Nu este vorba despre intrarea din manifest și nici despre șirul de caractere al versiunii declarate.
- Un analizor care citește fișierele package-lock.json, pom.xml sau requirements.txt nu accesează niciun artefact executabil, astfel încât ambele câmpuri hash returnează valoarea „necunoscut”
- În cazul în care există un hash, algoritmul trebuie să utilizeze denumirile textuale ale funcțiilor hash ale IANA și să fie aprobat de o autoritate precum NIST
- Hash-urile sunt cele care permit destinatarului să confirme că componenta descrisă este aceeași cu cea livrată
2. Contextul generării SBOM face ca metoda să facă parte din dosar
Contextul generării SBOM-ului este cea mai discretă adăugire, dar și cea mai semnificativă din punct de vedere structural: „faza relativă a ciclului de viață al software-ului și datele disponibile în momentul în care autorul SBOM-ului a generat acesta”. CISA definește trei valori — înainte de compilare, în timpul compilării și după compilare — și le corelează pe fiecare cu modul în care a fost produs SBOM-ul: un SBOM generat pe baza codului sursă corespunde celei mai timpurii faze, în timp ce instrumentele de analiză binară îl plasează în cea mai târzie fază.
- Echipele de achiziții pot specifica ce fază a ciclului de viață vor accepta, acordând prioritate listelor SBOM generate din artefactul compilat în detrimentul celor la nivel de sursă
- Platformele de gestionare a vulnerabilităților pot pondera rezultatele în funcție de contextul declarat
- Un SBOM generat pe baza surselor rămâne admisibil, dar nu mai poate fi prezentat ca fiind echivalent cu unul generat pe baza fișierului binar final
3. Acoperirea înlocuiește profunzimea, fără un prag minim
Elementul „Adâncime” din 2021 impunea doar dependențe de nivel superior — o definiție despre care CISA afirmă acum că „reflecta capacitățile instrumentelor SBOM de la momentul respectiv, mai degrabă decât adâncimea informațiilor necesare pentru a lua decizii informate în materie de securitate”. Acoperirea este mai exigentă: „toate componentele care alcătuiesc software-ul țintă, inclusiv dependențele tranzitive. Nu există o adâncime minimă.”
Testul este funcțional. Un destinatar „ar trebui să poată concluziona că o vulnerabilitate raportată recent nu îl afectează dacă SBOM-ul nu menționează componenta asociată cu vulnerabilitatea respectivă”. Absența devine o dovadă, ceea ce este valabil numai atunci când acoperirea este suficient de completă. Este puțin probabil ca analiza manifestului, luată separat, să atingă acest standard în cazul:
- Codul legat static și cel furnizat de terți — nu lasă nicio intrare în manifest
- Proiecte C și C++ — niciun manager universal de pachete nu ține evidența fișierelor DLL și a obiectelor partajate incluse în timpul compilării
- Codul sursă copiat — pe care CISA îl descrie ca fiind „practic o dependență care se urmărește mai bine ca o ramificație și o relație de dependență”
- Container straturi de imagini — pachete instalate prin comenzi de tip „layer”, în loc să fie declarate într-un manifest
Informațiile necunoscute trebuie declarate acum
- Autorii ar trebui să facă distincția între informațiile care le sunt necunoscute și cele ascunse în mod deliberat
- Se recomandă autorilor să pună la dispoziție un mecanism prin care destinatarii să poată solicita informații cu privire la conținutul redactat legat de securitate
- „Organizațiile pot considera un SBOM incomplet dacă autorul acestuia nu furnizează date esențiale privind componentele”
- Conceptul de „acceptare a erorilor” a fost înlocuit pe baza principiului că destinatarii „se pot aștepta ca datele SBOM să fie corecte” — erorile rezultate din „alegerea unor instrumente inadecvate” constituie acum elemente legitime în cadrul evaluării de risc efectuate de destinatar
Modificări suplimentare aduse de CISA elementelor SBOM pentru 2026
Modificare | Ce este | De ce este important |
Semnătura autorului SBOM (nou) | O semnătură digitală asociată autorului SBOM-ului | Permite destinatarului să confirme că SBOM-ul este autentic și că nu a fost modificat după semnare |
Licență pentru componente (nouă) | Licența sub care este distribuită fiecare componentă | Riscuri legate de drepturile de autor și de conformitate privind suprafețele; CISA indică ID-urile licențelor SPDX |
Date prelucrabile automat (fostă secțiune „Suport pentru automatizare”) | Numai SPDX și CycloneDX | SWID a fost eliminat, deoarece nu era utilizat pe scară largă; numărul formatelor acceptate se reduce la două |
Producător de componente (anterior: Numele furnizorului) | O singură organizație cu nume specific pentru fiecare componentă | Adaugă o opțiune de rezervă explicită de tip „proveniență necunoscută” atunci când sursa nu este clară |
Frecvență (actualizată) | Un nou SBOM pentru fiecare versiune, actualizare și compilare care include componente modificate | Această cadență este greu de menținut manual, ceea ce determină echipele să opteze pentru generarea automată |
Reducerea decalajului de după finalizarea construcției
Actualizarea din 2026 reflectă evaluarea CISA conform căreia instrumentele SBOM au ajuns la un nivel de maturitate suficient pentru a impune cerințe mai mari, iar informațiile pe care le așteaptă acum se află dincolo de etapa de compilare.
MetaDefender™ Software Supply Chain generează date SBOM direct din artefactul compilat:
- Scanează artefacte, fișiere binare și straturi ale imaginilor container, nu doar fișierele de dependențe
- Identifică fișierele binare C, C++ și C# prin intermediul metadatelor Portable Executable și identificarea bazată pe semnături
- Generează liste SBOM în CycloneDX și SPDXși îmbogățește rapoartele existente pentru a evidenția componentele și vulnerabilitățile CVE omise de scanările anterioare
- Face trimitere la GHSA, CVE și EUVD și semnalează licențele neconforme
- Se integrează cu fluxurile CI/CD și cu registrele de artefacte, precum JFrog Artifactory, astfel încât generarea SBOM-ului să poată însoți fiecare compilare
Pentru a afla cum MetaDefender Software Supply Chain pot sprijini cerințele SBOM pe parcursul întregului ciclu de viață al dezvoltării:
ÎNTREBĂRI FRECVENTE
Ce s-a schimbat în ceea ce privește elementele minime ale SBOM prevăzute de CISA 2026?
Actualizarea adaugă zece câmpuri de date noi, aduce opt modificări majore și elimină un element. Cea mai importantă schimbare structurală constă în înlocuirea câmpului „Depth” cu „Coverage”, iar noile câmpuri, printre care „Component Hash Value”, „SBOM Generation Context” și „SBOM Author Signature”, ridică standardele privind modul în care sunt generate și verificate datele SBOM.
Elementele minime ale SBOM prevăzute de CISA 2026 sunt obligatorii?
Nu. CISA nu stabilește niciun termen limită de conformare și niciun mecanism de aplicare, precizând că documentul „nu constituie o recomandare în scopuri de conformitate, de reglementare sau juridice”. Efectul practic decurge din cerințele privind achizițiile publice și din reglementările care fac referire la standardele de bază privind SBOM, cum ar fi Legea UE privind reziliența cibernetică.
Elementele minime ale SBOM prevăzute de CISA 2026 necesită o analiză a fișierelor binare sau o analiză ulterioară compilării?
Nu în mod explicit. Cu toate acestea, câmpul „Valoarea hash a componentei” necesită acces la artefactul executabil, câmpul „Contextul de generare a SBOM-ului” impune autorilor să declare faza ciclului de viață, iar câmpurile necompletate trebuie marcate ca „necunoscute”. Prin urmare, un SBOM care conține doar surse respectă formatul, documentând în același timp propriile lacune.
Elementele minime prevăzute de CISA 2026 se aplică software-ului de IA și serviciilor SaaS?
Da. Domeniul de aplicare acoperă toate tipurile de software, inclusiv cel open source, IA și SaaS. CISA menționează că aceste categorii pot necesita elemente suplimentare, dar nu le definește în acest document, făcând referire, în schimb, la orientările comune ale G7 privind SBOM pentru IA, publicate în mai 2026.
Ce formate SBOM sunt acceptate în cadrul elementelor minime prevăzute de CISA 2026?
SPDX și CycloneDX, descrise ca fiind cele două formate utilizate pe scară largă pentru generarea și utilizarea listelor SBOM. Etichetele SWID au fost eliminate, fiind considerate „un format de date SBOM care nu este utilizat pe scară largă și pentru care nu există mai multe instrumente”. Versiunile învechite ale oricărui format nu ar trebui utilizate pentru software-ul nou.
