Docker image SBOM hogyan?

Fórumok

Elsősorban az érdekelne, hogy valaki csinált-e már ilyesmit, mert kereséseim eddig nem vezettek eredményre. A forráskódolvasás még hátra van...

A probléma: van egy termék (Collabora Online), egy docker image formájában (collabora/code). Ehhez kellene legyártani egy SBOM-ot standard eszközökkel, licenc és sebezhetőségi infók kinyerése céljából. Eddig a dologból annyi valósul meg, hogy ha mondjuk ráengedem a syft-et az image-re, akkor elkészül az SBOM, ami elsősorban a Debian alaprendszer csomagjairól tartalmaz információt, a Collabora Online-ról alig valamit.

Például a Collabora Online-hoz vannak publikálva CVE-k a GitHub-on, de hiába nézek egy ismerten sebezhető verziót, nem kerül be semmi róla az SBOM file-ba. 

A másik probléma, hogy a Collabora Online egy pár C/C++ libet statikusan linkel, és egy pár harmadik féltől származó Javascript modult beépít. Pontosan tudjuk, hogy mik ezek, verzióval, licenccel. De a scanner nem találja meg, amit meg is értek, de hova és milyen formátumban kellene letenni ezeket az információkat az image-be, hogy a scannerek megtalálják?

Eddig úgy voltunk vele, hogy a megrendelő scannelte az image-et, rugózott egy sort azon, hogy a Debian alaprendszerben a Perl egy moduljának nem kompatibilis a licence (nem is használjuk, úgyhogy erővel leszedtem), meg hogy a zlib-ben biztonsági hiba van (nincs, mert a sérülékenységet tartalmazó file nem része a csomagnak), szóval egyáltalán nem azt az infót adja a scanner, amire szükség volna, nevezetesen annak a programnak a licenc információit és sérülékenységi információit, ami maga a termék.

Hozzászólások

Nehéz terep. A docker desktop ad egy olyan scout kimenetet (talán parancssori docker is), amiben benne van minden, ami a dockerHub-on is fent van. De ez és semmi sem analizálja rendesen a teljes callGraph-ot, azaz mit hívnak belőle az alkalmazások. Egy csomag sokmindent tartalmazhaz, a CVE-k pedig sokmindenre sírnak.

Néha meg kell elégedni azzal, hogy nins benne hihg+critical CVE.

lerántottam az image-et, csak szokásos debian sérülékenységek vannak benne, amiktől akkor szabadulhatsz meg, ha épp kiadnak egy debian verziót és 1-5 napig nem benne CVE (kivéve ha egy több éves benne pihen). Ha meg tudod oldani, hogy alpine comagra felépíted az image-et magad, akkor tudsz tiszta lenni, egyébként elengedném.

Köszi a választ, de a célom nem az, hogy kijöjjön, hogy minden OK, mert ha pl. letörölném a Debian csomagadatbázist, akkor nem találna egyáltalán semmit. Mondjuk ha egy distroless image-ben gondolkodnék. Én azt szeretném, hogy igenis találja meg és sorolja fel a Collabora Online komponenseinek verziószámait és licenceit, és ha valaki egy régi image-et scannel, mondjuk egy 24.04.3.2-es verziójút, annak jöjjön ki, hogy "CVE-2024-37311 Remote host TLS certificates are not fully verified - High" stb. 

docker scout quickview collabora/code:24.04.11.3.1

van egy termék (Collabora Online), egy docker image formájában (collabora/code). Ehhez kellene legyártani egy SBOM-ot standard eszközökkel, licenc és sebezhetőségi infók kinyerése céljából.

Magát az SBOM filet a

docker sbom ....

paranccsal tudod előállítani (ezt nyilván tudod) viszont ez a csomag informácikból dolgozik. Így ha van az image -ben olyan komponens ami nem csomagból települ, az nem kerül az SBOM -ba. Ugyan akkor ha a scaner eszköznek nem része a megfelelő információ, nem találja meg a sebezhető csomagot, binárist, akármit.

Én azt hiszem inkább olyan eszközt keresnék, ami nem csak a csomagverziókból dolgozik, hanem az image tartalmát file szinten is elemzi.

Eddig úgy voltunk vele, hogy a megrendelő scannelte az image-et

Én igyekeznék ennél a verziónál maradni, nem jó ennek a felelősségét magadra húzni, ha csak nem vagy IBF/CISO.

rugózott egy sort azon, hogy ... a zlib-ben biztonsági hiba van

A nap végén muszáj lesz felvállalni néhány sebezhetőséget és inkább a kihasználhatóságát gátolni, végső esetben felkészülni a kárelhárításra.

Valamint, ha jól rémlik az SBOM egy json file, tehát ha nem csal meg az emlékezetem, te is ki tudod egészíteni.

----
올드보이

> Így ha van az image -ben olyan komponens ami nem csomagból települ, az nem kerül az SBOM -ba.

Én is ezt tapasztalom, de ez jól van-e így? Szerintem elég tipikus, hogy valaki a saját szoftverét dockerizálja, de mintha ez az egész technológia arra lenne felépítve, hogy feltételezi, hogy a disztribúciókban meglévő csomagokból rakunk össze image-eket. 

Nem nincs, de a legtöbb eszköz ennyit tud. Ezért írtam, hogy egy más megközelítés talán célravezetőbb.

Esetleg Greenbone -al lehetne kísérletezni, olyan targetet beállítani, ami a kicsomagolt docker image -re mutat.

A közeljövőben nekem is foglalkoznom kell majd a kérdéskörrel. Nálunk a cégnél, a Harbor bevezetése, vagy a Qualys licence kibővítése került szóba. Nyilván egyik se öt perc, illetve mind a két software inkább K8s környezet vizsgálatára specializált

Szerintem elég tipikus, hogy valaki a saját szoftverét dockerizálja...

Nem egy PHP -s, NodeJs -es projecttel van rossz tapasztalatom és ahogy mondod, pont a fejlesztési, bevezetési fázisra nincs jóformán megoldása az iparnak.

----
올드보이

Saját tapasztalat alapján az előttem szólók a Docker vonatkozást már elmondták. Tehát a docker image-ben a csomagokat fogod tudni scannelni. A benne lévő custom app az nem lesz benne a BOM-ban.

Ellenben ezt én nem ezen a ponton közelíteném meg. 2 külön dologról beszélünk. Van egy appod (collabora online), meg van egy környezeted (Debian a Dockerben). Ez két tök külön BOM. Az app BOM-ját akkor kell előállítani, amikor azt buildeled (pl. java esetében van maven plugin ami pont ezt csinálja, az összes include-olt komponenst berakja a BOM-ba). Aztán jöhet a konténer build és a másik BOM.

Tulajdonképpen a saját appodról kellene első körben készíteni egy "bizonylatot", aztán a konténerről. Ez a kettő _együtt_ adná ki a kvázi végleges "bizonylatot" a komponensekről. 

Tudom h. ez nem egy Java projekt, de itt a példa amiről beszéltem, sztem majd minden nyelvhez létezik ilyesmi: https://github.com/CycloneDX/cyclonedx-maven-plugin

Nem biztos h. ez a szent grál, de én ebbe az irányba indulnék. A cégnél is ilyesmit kezdtünk bevezetni, igaz h. majdnem minden Java amit ellenőrizni kell, így a maven dependency-ket scanneljük. Ugye ez a lentebb írt static build-re erősen hajaz, mert a jar-ba amit építünk bepakoljuk a depeket is. Ha ugye belefordítod így vagy úgy az adott lib adott verzióját, akkor a konténerben lévő újabb openssl igazából csalásnak is számít sztem, hiszen nem is azt használod. Ugyanakkor lehet ez egy jó irányú csalás is, mert pl. olyan zlibet fordítasz bele, amiben javítottál valamit, szóval az első hozzászólással is maximálisan egyetértek: ez egy nehéz terep. Minél kevesebb a hackelés és az egyedi komponens, annál könnyebb egyébként boldogulni.

Én még ezt javasolnám egyébként, tesztelgetem és működik, egészen jó: https://dependencytrack.org

Ez már az SBOM-ból dolgozik, de korrekt riportot tud csinálni CVE-kkel meg mindennel és csillivilli, tök egyszerű összerakni akár konténerben is. Vmi Java izé + cassandra db :) 

> Eddig úgy voltunk vele, hogy a megrendelő scannelte az image-et, rugózott egy sort azon, hogy a Debian alaprendszerben a Perl egy moduljának nem kompatibilis a licence (nem is használjuk, úgyhogy erővel leszedtem), meg hogy a zlib-ben biztonsági hiba van (nincs, mert a sérülékenységet tartalmazó file nem része a csomagnak), szóval egyáltalán nem azt az infót adja a scanner, amire szükség volna, nevezetesen annak a programnak a licenc információit és sérülékenységi információit, ami maga a termék.

Fentebb írták, hogy az SBOM nem is feltétlen arra való, hogy egy custom termék custom CVE-it tartalmazza, hanem arra, hogy ha van ismert sérülékenység a termék által használt fuggőségekben (Java package, NPM package, Compsoer pakcage, stb) akkor azt listázza. Ha a termék zárt forrású, és a bináris csomagjai sincsenek fenn sehol, akkor nem lesz benne a SBOM-ban.

Ami a másik részét illeti, hogy tudnillik olyan CVE hibajelzéseket is kapsz, amik nem alkalmazhatók az image-re (pl zlib), nos, ezért van az, hogy relatív kevés helyen használják kizárólagosan az ilyen scannelések eredményét döntéshez. Általában megküldik a gyártó(k)nak/beszállító(k)nak a sérülékenységi reportot, amire ők aztán reagálnak, hogy pl "ez nem érvényes ránk, mert a sérülékenységet tartalmazó fájlt nem szállítjuk, a többi viszont kritikus része az alkalmazásnak" és ilyenkor bypassolódik az a sérülékenység, azzal a megállapodással, hogy amennyiben mégis kihasználják, úgy az a szakvéleményt kiállító partner felelőssége lesz.

Nincs, és szerintem a közeljövőben nem is lesz olyan security report, ami 100%-os lefedettséget ad, és nem lesznek benne fals pozitívok vagy fals negatívok. Ez _egyfajta_ security measurement, de közel sem ultimate solution. Vannak olyan eszközök, amik az alkalmazás bemeneteit scannelve keresnek mindenféle sérülékenységet, vannak pentesterek, és white hat hackerek, akik feltárják a sérülékeny funkcionalitásokat. De sem külön-külön, sem összességében nem érhető el 100%-os lefedettség, kizárólag törekedni lehet rá. Ez egy ilyen játék, sajnos.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ez alapján akkor járok a legjobban, ha az alaprendszert még jobban minimalizálom, mert abból gyakorlatilag nem kell semmi. Teljesen distroless-re még nem sikerült megcsinálni, de ez is egy irány volt. Mivel olyan binárisokat állítunk elő, hogy lehetőleg minden modern Linux distrón fusson, kénytelenek vagyunk statikusan linkelni egy csomó függőséget (pl. a LibreOfficeKit-en keresztül a LibreOffice összes 3rd party lib függőségét). Ezeknek a libeknek a sérülékenységmentességéről végső soron én gondoskodom (és/vagy a LibreOffice projekt). 

A másik ilyen játék a licencek tesztelés volt, itt is jól letesztelték az alaprendszer csomagjainak licenceit, de arról nem kaptak infót, hogy a Collabora Online milyen komponenseket használ fel, és azoknak mik a licenceik. Szerencsére ez nem is hiányzott, de ezt akartam volna valahogy "kivezetni", hogy scannelhető legyen. De erre is csak hackeket találtam egyelőre (mint pl. copyright file-ok az /usr/share/doc alatt, csak egyelőre úgy tűnik, hogy inkább a forráskód egyes részeinek különböző licenccel ellátására jó ez, a statikus linkelés koncepciója teljesen idegen tőle).

Vagy minden libet shared módon oldasz meg az alaprendszer részeként. És akkor igazából az appod csak a saját kódod, azt meg onnantól kód szinten kell ellenőrizni, nem is játszik annyira az SBOM. Alapvetően szerintem ki kell választani az irányt és azt erőltetni, mert minél vegyesebb a cucc, annál többet fogsz szívni, mert mindenre is készülni kell.