Docker Scout vytvorí SBOM, samotný zoznam balíkov však nie je audit

Docker Scout vytvorí SBOM kontajnerového obrazu príkazom docker scout sbom --format spdx --output sbom.spdx.json local://moja-aplikacia:vydanie. Predponu local:// použite pre obraz uložený v počítači; pre obraz v registri ju nahraďte predponou registry://. Referencia príkazu Docker Scout uvádza aj formát CycloneDX, zápis do súboru a výber platformy obrazu.

Výstup je strojovo čitateľný inventár identifikovaných balíkov. Pri vydaní má zmysel skontrolovať formát, názvy a verzie očakávaných komponentov a uložiť súbor spolu s identitou obrazu. Samotný inventár ešte neposudzuje bezpečnosť aplikácie.

Export z lokálneho obrazu

Najprv zostavte obraz, napríklad príkazom docker build -t moja-aplikacia:vydanie ., a pri exporte použite tú istú značku. Predpona local:// obmedzí vyhľadávanie na lokálne úložisko obrazov. Ak tam obraz nie je, príkaz nemá namiesto neho načítať rovnako označený obraz z registra. Názov obrazu v tomto postupe je ilustračný; v projekte ho nahraďte skutočnou referenciou.

Ak ďalší nástroj očakáva CycloneDX, použite docker scout sbom --format cyclonedx --output sbom.cdx.json local://moja-aplikacia:vydanie. Formát zadajte výslovne: predvolený výstup príkazu je JSON, ktorý nie je automaticky SPDX JSON. Na rýchle prezretie nájdených balíkov slúži docker scout sbom --format list local://moja-aplikacia:vydanie, ale tento čitateľný zoznam nie je exportom vo zvolenom štandardnom formáte.

Export obrazu z registra

Pre publikovaný obraz použite napríklad docker scout sbom --format spdx --output sbom.spdx.json registry://registry.example.org/tim/aplikacia:vydanie. Adresa registra je ilustračná. Predpona registry:// určuje zdroj jednoznačne: Docker Scout nebude analyzovať lokálny obraz, ktorý má náhodou rovnakú značku. Bez výslovnej predpony sa najprv hľadá lokálna kópia a až potom obraz v registri.

Pri archivácii vydania uprednostnite referenciu s digestom publikovaného obrazu a tú istú identitu zaznamenajte k súboru SBOM. Značka sa môže presunúť na iný obsah, kým digest pomenúva konkrétny obraz. Ak vydávate varianty pre viacero platforiem, zaznamenajte aj analyzovanú platformu; Docker Scout umožňuje vybrať ju prepínačom --platform. Inak sa pri neskoršom porovnaní môžu líšiť balíky len preto, že výstupy patria odlišným variantom obrazu.

Kontrola formátu a očakávaných komponentov

Po exporte skontrolujte, či súbor existuje a dá sa spracovať ako JSON. V dokumente SPDX hľadajte údaj o verzii špecifikácie a záznamy balíkov; pri CycloneDX označenie formátu a záznamy komponentov. Prípona .json nestačí ako dôkaz formátu, pretože aj predvolený výstup Docker Scoutu používa JSON. Táto prvá kontrola odhalí zámenu formátu alebo prázdny či poškodený artefakt, nenahrádza však úplnú validáciu podľa príslušnej schémy.

Potom zvoľte komponenty, ktorých prítomnosť v hotovom obraze viete odôvodniť zostavovacím postupom: napríklad systémový balík zo základného obrazu a knižnicu inštalovanú pre beh aplikácie. Pri každom skontrolujte názov, verziu a identifikátor balíka, ak je uvedený, napríklad PURL. Celkový počet záznamov je slabá kontrola: dva súbory môžu mať rovnaký počet položiek a pritom obsahovať iné verzie.

Ak očakávaná knižnica chýba, overte, či sa vôbec dostala do finálneho obrazu. Pri viacfázovom zostavení môže zostať iba vo fáze používanej na kompiláciu. Ďalšou možnosťou je, že spôsob uloženia súborov alebo metadát neumožnil nástroju balík rozpoznať. Chýbajúci záznam preto skúmajte vo vzťahu ku konkrétnemu zostaveniu, nie iba podľa deklarácie závislosti v zdrojovom kóde.

SBOM ako artefakt vydania

V CI generujte SBOM z obrazu určeného na vydanie a uložte ho medzi artefakty toho istého behu. Ak export prebieha na runneri, ktorý obraz zostavil a stále ho má lokálne, použite local://. Ak beží až po publikovaní, analyzujte obraz cez registry://. K súboru zaznamenajte digest obrazu, platformu, použitý formát a identifikátor zdrojového commitu. Tak sa dá pri neskoršej kontrole určiť, ktorému zostaveniu inventár patrí.

Návod Dockeru k SBOM rozlišuje export súboru od atestácie pripojenej k obrazu pri zostavení. Docker Scout navyše použije existujúcu SBOM atestáciu, ak je pri obraze dostupná; inak obsah obrazu indexuje. Ak proces vydania vyžaduje, aby bol SBOM dostupný priamo pri publikovanom obraze, samotné uloženie súboru medzi artefakty CI túto požiadavku nesplní.

Prečo sa inventár obrazu líši od exportu repozitára

Hotový obraz a graf závislostí repozitára opisujú odlišné veci. V obraze môžu byť balíky základného operačného prostredia aj knižnice pridané počas zostavenia. Manifest projektu môže naopak uvádzať závislosť, ktorá sa do finálneho obrazu nedostala. Dva platné exporty preto nemusia mať rovnaké komponenty ani rovnaký počet záznamov.

Dokumentácia GitHubu k exportu SBOM opisuje výstup SPDX z aktuálneho grafu závislostí repozitára vrátane verzií, identifikátorov balíkov, licencií a tranzitívnych ciest; nezahŕňa projekty závislé od daného repozitára. Pri porovnávaní spárujte obraz so zdrojovým commitom, z ktorého bol zostavený, a skúmajte konkrétne názvy a verzie. Rozdiel medzi manifestom a obrazom potom môže ukázať, čo zostalo mimo finálnej fázy a čo do nej priniesol základný obraz.

Inventár a bezpečnostné posúdenie

Export SBOM zaznamenáva identifikované komponenty, ale sám neurčuje, či sa známa zraniteľnosť dá v danej konfigurácii využiť, či zostavenie prebehlo dôveryhodným spôsobom alebo či obraz spĺňa pravidlá projektu. Na také závery treba inventár spojiť s informáciami o zraniteľnostiach, kontextom použitia komponentov a samostatnými kontrolami zostavenia. Pri vydaní má preto SBOM jasnú úlohu: zachovať dohľadateľný zoznam obsahu presného obrazu, s ktorým môžu tieto kontroly ďalej pracovať.

Prečítajte si aj:

• Export Slacku nie je záloha: ZIP obsahuje odkazy na súbory, nie súbory
• Údaj zmizol z Googlu, nie z webu: ako požiadať o odstránenie
• Cloud šifruje súbory, nie všetky stopy: ako nastaviť Cryptomator