Docker SBOM: jak go wygenerować i czego w nim brakuje

Jak wygenerować SBOM obrazu Docker

Istnieją trzy popularne sposoby. BuildKit może zapisać SBOM podczas budowania obrazu i dołączyć go do obrazu jako poświadczenie. Docker Scout i Syft generują go z istniejącego już obrazu, lokalnego lub w rejestrze.

W czasie buildu, za pomocą BuildKit

Należy dodać --sbom=true lub jego długą formę --attest type=sbom do docker buildx build. BuildKit uruchamia na wyniku swoją wtyczkę skanera Syft i dołącza SBOM do obrazu jako dokument SPDX JSON. Dzięki eksporterowi local można obejrzeć SBOM, zanim cokolwiek zostanie wypchnięte:

# Build the image, attach an SBOM attestation and push it
docker buildx build --sbom=true -t registry.example.com/app:1.0 --push .

# The long form of the same option
docker buildx build --attest type=sbom -t registry.example.com/app:1.0 --push .

# Check the SBOM before pushing: write the build result to ./out
docker buildx build --sbom=true --output type=local,dest=out .
# out/sbom.spdx.json is the SBOM

Odczytanie SBOM dołączonego do obrazu

docker buildx imagetools inspect odczytuje poświadczenie z rejestru. Wszystko, co dotyczy SBOM, znajduje się pod .SBOM w szablonie Go:

# Print the SPDX document attached to the image
docker buildx imagetools inspect registry.example.com/app:1.0 \
  --format "{{ json .SBOM.SPDX }}"

# List each package and its version
docker buildx imagetools inspect registry.example.com/app:1.0 \
  --format "{{ range .SBOM.SPDX.packages }}{{ .name }}@{{ .versionInfo }}{{ println }}{{ end }}"

Z istniejącego obrazu, za pomocą Docker Scout

docker scout sbom używa poświadczenia SBOM obrazu, jeśli ono istnieje. Jeśli nie, sam indeksuje zawartość obrazu. Domyślnie wypisuje JSON, a do pliku zapisuje z opcją --output:

# List the packages in an image
docker scout sbom --format list registry.example.com/app:1.0

# Write an SPDX or CycloneDX SBOM to a file
docker scout sbom --format spdx --output app.spdx.json registry.example.com/app:1.0
docker scout sbom --format cyclonedx --output app.cdx.json registry.example.com/app:1.0

Z istniejącego obrazu, za pomocą Syft

Syft to skaner open source, na którym oparta jest wtyczka BuildKit. Należy wskazać mu obraz i wybrać format opcją -o. Dodanie =file zapisuje każdy format do osobnego pliku:

# CycloneDX JSON to the terminal
syft registry.example.com/app:1.0 -o cyclonedx-json

# Both formats, each to its own file
syft registry.example.com/app:1.0 -o spdx-json=app.spdx.json -o cyclonedx-json=app.cdx.json

SPDX czy CycloneDX?

Poświadczenia BuildKit są zawsze w SPDX. Docker Scout zapisuje SPDX lub CycloneDX, a Syft oba te formaty oraz inne. Oba standardy wymieniają pakiety, wersje, licencje i package URL, więc wybór zwykle zależy od narzędzia, które będzie czytać SBOM. Różnice opisuje strona CycloneDX czy SPDX.

Jak skaner obrazów tworzy SBOM

Wszystkie te narzędzia działają tak samo. Rozpakowują warstwy obrazu i odczytują znalezione metadane pakietów: bazę pakietów systemu operacyjnego i metadane pozostawione przez menedżery pakietów języków. Każdy pakiet, który potrafią zidentyfikować, staje się wpisem w SBOM, łącznie z pakietami pochodzącymi z obrazu bazowego.

Uwzględnienie etapów buildu i kontekstu buildu

Domyślnie BuildKit skanuje tylko etap końcowy. W buildzie wieloetapowym kompilatory, narzędzia buildu i pakiety używane we wcześniejszych etapach nie trafiają do obrazu końcowego, więc nie ma ich też w jego SBOM. Dokumentacja poświadczeń SBOM Dockera opisuje dwa argumenty buildu, które rozszerzają skan. BUILDKIT_SBOM_SCAN_STAGE dodaje etap, a BUILDKIT_SBOM_SCAN_CONTEXT dodaje kontekst buildu:

# syntax=docker/dockerfile:1
# Scan the build context as well as the image
ARG BUILDKIT_SBOM_SCAN_CONTEXT=true

FROM golang:1.25 AS build
# Include this build stage in the SBOM
ARG BUILDKIT_SBOM_SCAN_STAGE=true
WORKDIR /src
COPY . .
RUN go build -o /out/app .

FROM scratch
COPY --from=build /out/app /app
ENTRYPOINT ["/app"]

Oba muszą być zadeklarowane przez ARG w Dockerfile. Samo ustawienie ich przez --build-arg nie daje efektu, choć --build-arg może nadpisać wartość zadeklarowaną w Dockerfile. Z eksporterem local każdy skanowany etap otrzymuje własny plik, na przykład sbom-build.spdx.json obok sbom.spdx.json.

Co skan nadal pomija

Skanowanie etapów zamyka jedną lukę. Skaner nadal jednak odczytuje pliki, a część tego, czego używa build, nie zostawia żadnego pliku lub zostawia taki, którego nie da się zidentyfikować:

• Pliki bez metadanych pakietów. Plik binarny pobrany przez curl, archiwum rozpakowane w kroku RUN lub skopiowany kod zewnętrzny. Niektóre pliki binarne zawierają informacje o buildzie czytelne dla skanera, na przykład binaria Go; wiele ich nie zawiera.
• To, co build pobrał i usunął. Pakiet lub instalator, który krok RUN pobiera, używa i usuwa w tej samej warstwie, nie zostawia w systemie plików niczego do odczytania przez jakikolwiek skaner, w etapie końcowym lub nie.
• Jak coś się tam znalazło. SBOM ze skanu wymienia to, co jest. Nie mówi, z jakiego rejestru lub hosta pochodzi pakiet ani który krok go pobrał.
• Nieoznaczone etapy. Skanowanie etapów trzeba włączyć, dla każdego etapu lub globalnie. Etap bez tego argumentu nadal jest pomijany.
• Ustawienia skanu. To, co się pojawi, zależy od sposobu uruchomienia skanera. W jednym projekcie pojedyncza flaga Syft decyduje, czy pakiety npm w ogóle pojawią się w wyniku.

Dlaczego to ważne

Przejęte narzędzie buildu lub obraz bazowy wpływa na to, co Państwo dostarczają, nawet jeśli nigdy nie pojawia się w obrazie końcowym. A plik binarny bez metadanych może zawierać podatność, na którą nie wskazuje żaden wpis SBOM. Gdy pojawia się biuletyn, trzeba wiedzieć nie tylko, co jest w obrazie, ale też co posłużyło do jego zbudowania.

Rejestrować także build

SBOM obrazu odpowiada na pytanie, co jest wewnątrz obrazu. Zapis buildu odpowiada na pytanie, co build pobrał: pobrane obrazy bazowe i pakiety pobrane przez każdy krok, łącznie z ukrytymi zależnościami, których nie wymienia żaden lockfile. CRACI rejestruje to podczas działania Państwa zadania GitHub Actions, przez proxy rozpoznające pakiety na runnerze, a API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu dla zadania. SBOM obrazu służy do opisania tego, co Państwo dostarczają, a zapis buildu do opisania, jak to powstało.

Zob. porównanie narzędzi SBOM, SBOM-y z czasu buildu oraz jak wygenerować SBOM w GitHub Actions.

Docker SBOM: najczęściej zadawane pytania

Jak wygenerować SBOM obrazu Docker?

Na trzy popularne sposoby. Dodać --sbom=true do docker buildx build, a BuildKit dołączy do obrazu SBOM w SPDX. Uruchomić docker scout sbom na istniejącym obrazie. Lub uruchomić Syft, na przykład syft IMAGE -o cyclonedx-json. Wszystkie trzy odczytują pakiety znalezione w obrazie.

Czym jest skaner SBOM?

To narzędzie, które odczytuje pliki, takie jak katalog źródłowy, lockfile lub obraz kontenera, i zapisuje SBOM pakietów, które potrafi zidentyfikować. Skanerami SBOM są Syft, Trivy, Docker Scout i wtyczka Syft w BuildKit. Opisują pliki, które mają przed sobą, a nie build, który je wytworzył.

Jaki format SBOM wytwarza Docker?

Poświadczenia BuildKit to dokumenty SPDX JSON dołączone do obrazu. Docker Scout może wypisać listę pakietów lub zapisać SPDX albo CycloneDX. Syft zapisuje oba, a także inne. Należy wybrać format oczekiwany przez narzędzie, które będzie korzystać z SBOM.

Jak skaner tworzy SBOM z obrazu Docker?

Rozpakowuje warstwy obrazu i odczytuje znalezione metadane pakietów: bazę pakietów systemu operacyjnego i pliki pakietów języków, takie jak metadane zainstalowanych pakietów npm lub Python. Każdy pakiet, który potrafi zidentyfikować, staje się wpisem w SBOM.

Dlaczego SBOM obrazu może pominąć komponent?

Ponieważ może wymienić tylko to, co potrafi zidentyfikować w odczytywanych plikach. Plik binarny pobrany przez curl nie ma metadanych pakietu, pakiet pobrany i usunięty przez krok buildu nie zostawia niczego do odczytania, a wcześniejsze etapy buildu są pomijane, chyba że włączą Państwo skanowanie etapów.

Czy SBOM obrazu nadal jest przydatny?

Tak. To właściwy zapis tego, co znajduje się w dostarczanym obrazie, łącznie z pakietami z obrazu bazowego. Nie opisuje jednak, jak obraz zbudowano, dlatego gdy ma to znaczenie, należy połączyć go z zapisem buildu.