2026. július 29-én a CISA közzétette a 2026-os minimális követelményeket Software Bill of Materials (SBOM), amely felváltja a 2021 óta hatályos NTIA-alapelveket, és amelyet az NSA, az FBI, valamint 15 nemzetközi kiberbiztonsági ügynökség közreműködésével állítottak össze.
A „2026-os minimális elemek az szoftver-alkatrészjegyzékhez ( Software )” (Bill of Materials (SBOM) ) című dokumentum a CISA frissített előírása arról, hogy milyen adatokat kell tartalmaznia egy SBOM-nak, és a legjelentősebb változás szerkezeti jellegű, nem pedig mennyiségi: a 2026-os előírás nem tiltja a forráskód-manifesztből generált SBOM-okat, de előírja a készítőknek, hogy jelentsék be, hogyan készült az SBOM, hogy készítsenek hash-értéket a futtatható artefaktumról, és hogy jelöljék meg minden olyan mezőt, amelyet nem tudtak kitölteni. A kizárólag manifesztből álló SBOM most már géppel olvasható formában is feltünteti saját hiányosságait.
MetaDefender Software Supply Chain OPSWAT szoftverellátási lánc-biztonsági platformja, amelyet artefaktumok, bináris fájlok és konténerkép-rétegek elemzésére terveztek – pontosan az az adatkategória, amelyre az új hash-, generációs kontextus- és lefedettségi követelmények most szükségessé teszik.
Rövid áttekintés
- 17 adatmező — 9 SBOM-metadat, 8 alkatrészadat
- 6 gyakorlat és folyamat
- 10 új terület, 8 jelentős frissítés, 1 eltávolítás (Hozzáférés-ellenőrzés, beolvasztva a Terjesztés és kézbesítés területébe)
- Minden szoftverre vonatkozik, „beleértve a nyílt forráskódú szoftvereket, a mesterséges intelligencia-szoftvereket és a SaaS-t is”
- Nem új követelmények – a szervezetek SBOM-jainak létrehozási és lekérdezési módjának finomítása
A 2026-os SBOM-változások, amelyeknek a kizárólag forráskódon alapuló SBOM-ok a legnehezebben tudnak megfelelni
1. Az összetevő hash-értéke megköveteli a futtatható artefaktumot
A „Komponens hash-értéke” és a „Komponens hash-algoritmusa” pontosan meghatározzák, hogy mi kerül hash-elésre: „az a kimenet, amely egy kriptográfiai hash-algoritmusnak egy futtatható komponens-artefaktumra való alkalmazásával jön létre”. Nem a manifest-bejegyzés, és nem is a deklarált verziós karakterlánc.
- A package-lock.json, a pom.xml vagy a requirements.txt fájlt olvasó elemző nem érint semmilyen futtatható artefaktumot, ezért mindkét hash-mező „ismeretlen” értéket ad vissza
- Ha létezik hash, az algoritmusnak a következőket kell használnia: az IANA hash-függvények szöveges neveit hasznosítania, és egy olyan hatóság, mint például a NIST, által jóváhagyottnak kell lennie
- A hash-értékek teszik lehetővé a címzett számára, hogy ellenőrizze: a leírt alkatrész valóban megegyezik-e a kiszállított alkatrésszel
2. Az SBOM-készítés kontextusa miatt a módszer a nyilvántartás részét képezi
Az SBOM-készítés kontextusa a legkevésbé feltűnő, ugyanakkor szerkezetileg a legjelentősebb kiegészítés: „a szoftver életciklusának relatív szakasza és az SBOM-készítő által az SBOM létrehozásakor rendelkezésre álló adatok”. A CISA három értéket határoz meg – a fordítás előtt, a fordítás során és a fordítás után –, és mindegyiket az SBOM előállítási módjához köti: a forráskódból létrehozott SBOM a legkorábbi szakaszhoz tartozik, míg a bináris elemző eszközökkel készült SBOM a legkésőbbihez.
- A beszerzési csapatok megadhatják, hogy az életciklus melyik szakaszát fogadják el, és előnyben részesíthetik a lefordított programkódból származó SBOM-okat a forráskód-szintűekkel szemben.
- A sebezhetőségkezelő platformok a megadott kontextus alapján súlyozhatják az eredményeket
- A forráskódból származó SBOM továbbra is megengedett, de már nem mutatható be úgy, mintha egyenértékű lenne a kész bináris fájlból előállított SBOM-mal
3. A lefedettség felváltja a mélységet, minimális követelmény nélkül
A 2021-es „mélységi” elem kizárólag a legfelső szintű függőségeket írta elő — a CISA most úgy fogalmaz, hogy ez a meghatározás „inkább az akkori SBOM-eszközök képességeit tükrözte, mintsem a megalapozott biztonsági döntések meghozatalához szükséges információk mélységét”. A lefedettségi követelmény szigorúbb: „a célszoftvert alkotó összes komponens, beleértve a tranzitív függőségeket is. Nincs minimális mélységi követelmény.”
A teszt működőképes. A címzettnek „arra a következtetésre kell jutnia, hogy egy újonnan bejelentett sebezhetőség nem érinti őt, ha az SBOM nem tartalmazza a sebezhetőséggel összefüggő komponenst”. A hiány maga bizonyítéknak minősül, ami azonban csak akkor áll fenn, ha a lefedettség kellően teljes. A manifeszt elemzése önmagában valószínűleg nem felel meg ennek a követelménynek az alábbi esetekben:
- Statikusan beágyazott és gyártói kód — nem hagy maga után manifesztbejegyzést
- C és C++ projektek — nincs olyan univerzális csomagkezelő, amely nyomon követné a fordításkor beépített DLL-eket és megosztott objektumokat
- Másolt forráskód — amelyet a CISA úgy ír le, hogy „gyakorlatilag egy olyan függőség, amelyet célszerűbb fork-ként és függőségi kapcsolattként nyomon követni”
- Container kép rétegek — olyan csomagok, amelyeket a layer parancsokkal telepítettek, és nem a manifesztben deklaráltak
Az ismeretlen információkat mostantól be kell jelenteni
- A szerzőknek meg kell különböztetniük a számukra ismeretlen információkat a szándékosan elhallgatott információktól
- A szerzőknek ajánlott olyan eljárást kialakítaniuk, amely lehetővé teszi a címzettek számára, hogy érdeklődjenek a biztonsági okokból kitakart tartalmakról.
- „A szervezetek az SBOM-ot hiányosnak tekinthetik, ha az SBOM összeállítója elhallgatja a lényeges alkatrészekre vonatkozó adatokat”
- A „hibák figyelembevétele” elvet azzal indokolták, hogy a címzettek „elvárhatják, hogy az SBOM-adatok pontosak legyenek” – a „nem megfelelő eszközök kiválasztásából” eredő hibák mostantól jogosan figyelembe vehetők a címzett kockázatértékelésében
A CISA által a 2026-os SBOM-elemeken végrehajtott további módosítások
Módosítás | Mi ez? | Miért fontos ez? |
SBOM-készítő aláírása (új) | Az SBOM-készítőhöz kapcsolódó digitális aláírás | Lehetővé teszi a címzett számára, hogy ellenőrizze, hogy az SBOM hiteles-e, és az aláírás után nem módosították-e |
Alkatrész-licenc (új) | Az egyes komponensekhez tartozó licenc | Felmerülő szerzői jogi és megfelelési kockázatok; a CISA az SPDX-licencazonosítókra hívja fel a figyelmet |
Géppel feldolgozható adatok (korábban: Automatizálási támogatás) | Kizárólag SPDX és CycloneDX | A SWID-et elhagyták, mivel nem volt széles körben elterjedt; így az elfogadott formátumok száma kettőre csökkent |
Alkatrészgyártó (korábban: Beszállító neve) | Komponensenként egy megnevezett szervezet | Ha a forrás nem egyértelmű, kifejezett „ismeretlen eredetű” tartalékértéket ad hozzá |
Gyakoriság (frissítve) | Minden verzióhoz, frissítéshez és összeállításhoz egy új SBOM, amely tartalmazza a módosított komponenseket | Ezt a ritmust kézzel nehéz fenntartani, ami arra készteti a csapatokat, hogy az automatizált generálás felé forduljanak |
A fejlesztés utáni hiányosságok kiküszöbölése
A 2026-os frissítés tükrözi a CISA azon értékelését, miszerint az SBOM-eszközök már annyira kiforrottak, hogy magasabb szintű elvárásoknak kell megfelelniük, és az információk, amelyekre a CISA jelenleg számít, a build-folyamat végső szakaszában találhatók.
A MetaDefender™ Software Supply Chain közvetlenül a lefordított artefaktumból generál SBOM-adatokat:
- Nem csupán a függőségi fájlokat, hanem az artefaktumokat, a bináris fájlokat és a konténerkép-rétegeket is beolvassa
- A C, C++ és C# bináris fájlokat a a Portable Executable metaadatok és a szignatúra-alapú azonosítás segítségével
- SBOM-okat generál a CycloneDX és az SPDX formátumban, és kiegészíti a meglévő jelentéseket, hogy feltárja a korábbi vizsgálatok során kimaradt alkatrészeket és CVE-ket
- Hivatkozásokat tartalmaz a GHSA, a CVE és az EUVD adatbázisokra, valamint jelzi a követelményeknek nem megfelelő licenceket
- Integrálható a CI/CD-folyamatokkal és az olyan artefaktum-nyilvántartásokkal, mint például a JFrog Artifactory, így az SBOM-készítés minden egyes buildhez társítható
Ha szeretné megtudni, hogyan támogatja az MetaDefender , azSoftware és azSupply Chain az SBOM-követelményeket a fejlesztési életciklus egészében:
GYIK
Mi változott a CISA 2026 SBOM-ra vonatkozó minimális elemekben?
A frissítés tíz új adatmezőt vezet be, nyolc jelentős módosítást hajt végre, és egy elemet eltávolít. A legjelentősebb szerkezeti változás a „Depth” (Mélység) helyett a „Coverage” (Lefedettség) bevezetése, míg az új mezők – köztük a „Component Hash Value” (Alkatrész hash-értéke), az „SBOM Generation Context” (SBOM-készítés kontextusa) és az „SBOM Author Signature” (SBOM-szerző aláírása) – magasabb elvárásokat támasztanak az SBOM-adatok előállításával és ellenőrzésével kapcsolatban.
A CISA 2026 szerinti SBOM-minimumszerkezeti elemek kötelezőek-e?
Nem. A CISA nem határoz meg megfelelési határidőt, sem végrehajtási mechanizmust, és kijelenti, hogy a dokumentum „nem minősül tanácsnak megfelelési, szabályozási vagy jogi célokra”. A gyakorlati érvényesülést a közbeszerzési követelmények és az SBOM-alapértékekre hivatkozó szabályozások biztosítják, például az EU kiberreziliencia-törvénye.
A CISA 2026 SBOM-ra vonatkozó minimális követelmények bináris vagy a fordítás utáni elemzést írnak elő?
Nem kifejezetten. Ugyanakkor a „Component Hash Value” mezőhöz hozzáférésre van szükség a futtatható artefaktumhoz, az „SBOM Generation Context” mező esetében a szerzőknek meg kell adniuk az életciklus-fázist, a kitöltetlen mezőket pedig „ismeretlen” jelöléssel kell ellátni. A kizárólag forráskódot tartalmazó SBOM tehát megfelel a formátumnak, miközben dokumentálja a saját hiányosságait.
A CISA 2026-os előírások szerinti minimális elemek vonatkoznak-e a mesterséges intelligencia szoftverekre és a SaaS-szolgáltatásokra?
Igen. A hatály kiterjed minden szoftverre, beleértve a nyílt forráskódú szoftvereket, a mesterséges intelligenciát és a SaaS-szolgáltatásokat is. A CISA megjegyzi, hogy ezek a kategóriák további elemeket tehetnek szükségessé, de azokat itt nem határozza meg, hanem a mesterséges intelligenciára vonatkozó, 2026 májusában közzétett G7-es közös SBOM-iránymutatásra hivatkozik.
Mely SBOM-formátumokat fogadja el a CISA 2026 a minimális elemek között?
Az SPDX és a CycloneDX, amelyeket az SBOM-ok létrehozásához és felhasználásához széles körben alkalmazott két formátumként írnak le. A SWID-címkéket eltávolították, mivel „nem egy széles körben használt SBOM-adatformátum, amelyhez több eszköz is létezik”. Bármely formátum elavult verzióit nem szabad új szoftverekhez használni.
