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
Magát az SBOM filet a
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.
É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.
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
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
> 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
via @snq-