Docker SBOM: näin generoit sen ja mitä siitä puuttuu

Näin generoit SBOM:n Docker-kuvalle

Yleisiä tapoja on kolme. BuildKit voi kirjoittaa SBOM:n kuvaa buildatessaan ja liittää sen kuvaan attestaationa. Docker Scout ja Syft generoivat sen jo olemassa olevasta kuvasta, paikallisesti tai rekisterissä.

Buildin aikana BuildKitillä

Lisää --sbom=true tai sen pitkä muoto --attest type=sbom komentoon docker buildx build. BuildKit ajaa lopputulokselle Syft-skannerilisäosansa ja liittää SBOM:n kuvaan SPDX JSON -dokumenttina. Buildaa local-exporterilla, niin voit katsoa SBOM:ia ennen kuin pushaat mitään:

# 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

Lue kuvaan liitetty SBOM

docker buildx imagetools inspect lukee attestaation takaisin rekisteristä. Kaikki SBOM:iin liittyvä on sen Go-templatessa kohdassa .SBOM:

# 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 }}"

Olemassa olevasta kuvasta Docker Scoutilla

docker scout sbom käyttää kuvan SBOM-attestaatiota, jos sellainen on. Jos ei ole, se indeksoi kuvan sisällön itse. Oletuksena se tulostaa JSONia ja kirjoittaa tiedostoon valitsimella --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

Olemassa olevasta kuvasta Syftillä

Syft on avoimen lähdekoodin skanneri, jonka päälle BuildKitin lisäosa on rakennettu. Osoita se kuvaan ja valitse formaatti valitsimella -o. Lisää =file, niin kukin formaatti kirjoitetaan omaan tiedostoonsa:

# 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 vai CycloneDX?

BuildKitin attestaatiot ovat aina SPDX-muotoisia. Docker Scout kirjoittaa SPDX:ää tai CycloneDX:ää, ja Syft kirjoittaa molempia muiden formaattien ohella. Molemmat standardit luettelevat paketit, versiot, lisenssit ja package URL:t, joten valinta riippuu yleensä työkalusta, joka lukee SBOM:n seuraavaksi. Erot: CycloneDX vs. SPDX.

Miten kuvaskanneri rakentaa SBOM:n

Kaikki nämä työkalut toimivat samalla tavalla. Ne purkavat kuvan kerrokset ja lukevat löytämänsä pakettien metatiedot: käyttöjärjestelmän pakettitietokannan ja kielten paketinhallintatyökalujen jälkeensä jättämät metatiedot. Jokaisesta tunnistamastaan paketista tulee SBOM-merkintä, myös peruskuvasta tulleista paketeista.

Ota mukaan buildivaiheet ja build-konteksti

Oletuksena BuildKit skannaa vain viimeisen vaiheen. Monivaiheisessa buildissa aiemmissa vaiheissa käytetyt kääntäjät, build-työkalut ja paketit eivät ole lopullisessa kuvassa, joten ne eivät ole myöskään sen SBOM:ssa. Dockerin SBOM-attestaatioiden dokumentaatio kuvaa kaksi build-argumenttia, jotka laajentavat skannausta. BUILDKIT_SBOM_SCAN_STAGE lisää vaiheen ja BUILDKIT_SBOM_SCAN_CONTEXT lisää build-kontekstin:

# 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"]

Molemmat on esiteltävä Dockerfilessa ARG-käskyllä. Pelkkä --build-arg ei vaikuta mitenkään, vaikka --build-arg voikin ohittaa Dockerfilessa esitellyn arvon. local-exporterilla jokainen skannattu vaihe saa oman tiedostonsa, esimerkiksi sbom-build.spdx.json tiedoston sbom.spdx.json viereen.

Mitä skannaukselta silti jää näkemättä

Vaiheiden skannaus sulkee yhden aukon. Skanneri lukee kuitenkin edelleen tiedostoja, ja osa siitä, mitä buildi käyttää, ei jätä jälkeensä tiedostoa, tai ei ainakaan sellaista, jonka skanneri pystyisi tunnistamaan:

• Tiedostot ilman pakettien metatietoja. curlilla ladattu binääri, RUN-vaiheessa purettu tarball tai sisään kopioitu vendoroitu koodi. Osa binääreistä, kuten Go-binäärit, sisältää skannerin luettavissa olevia build-tietoja; monet eivät.
• Mitä buildi latasi ja poisti. Paketti tai asennusohjelma, jonka RUN-vaihe hakee, käyttää ja poistaa samassa kerroksessa, ei jätä tiedostojärjestelmään mitään luettavaa yhdellekään skannerille, oli kyse viimeisestä vaiheesta tai ei.
• Miten asiat päätyivät kuvaan. Skannauksesta tehty SBOM luettelee, mitä kuvassa on. Se ei kerro, mistä rekisteristä tai palvelimelta paketti tuli tai mikä vaihe sen haki.
• Vaiheet, joita et merkinnyt. Vaiheiden skannaus otetaan käyttöön erikseen, vaihekohtaisesti tai kaikille. Vaihe ilman argumenttia jää edelleen pois.
• Skannauksen asetukset. Tulos riippuu siitä, miten skanneri ajetaan. Eräässä projektissa yksi Syftin valitsin ratkaisee, näkyvätkö npm-paketit tuloksessa lainkaan.

Sama ongelma Yocto-buildeissa: miksi SBOM-skannerit eivät näe kaikkea Yocto-buildien sisältöä.

Miksi tällä on merkitystä

Vaarantunut build-työkalu tai peruskuva vaikuttaa siihen, mitä toimitat, vaikka se ei koskaan näkyisi lopullisessa kuvassa. Ja binääri ilman metatietoja voi sisältää haavoittuvuuden, johon mikään SBOM-merkintä ei viittaa. Kun tietoturvatiedote julkaistaan, sinun on tiedettävä sekä se, mitä kuvan buildaamiseen meni, että se, mitä kuvassa on.

Tallenna myös buildi

Kuvan SBOM vastaa kysymykseen, mitä kuvan sisällä on. Buildin tallenne vastaa kysymykseen, mitä buildi toi mukanaan: sen hakemat peruskuvat ja kunkin vaiheen hakemat paketit, myös piilossa olevat riippuvuudet, joita mikään lukitustiedosto ei luettele. CRACI tallentaa tämän GitHub Actions -jobisi ajon aikana runnerilla toimivan, paketit tunnistavan välityspalvelimen kautta, ja API palauttaa jobin SBOM:t, verkkojäljet ja alkuperätiedot. Käytä kuvan SBOM:ia siihen, mitä toimitat, ja buildin tallennetta siihen, miten se tehtiin.

Katso SBOM-työkalut vertailussa, buildin aikana tallennetut SBOM:t ja näin generoit SBOM:n GitHub Actionsissa.

Docker-SBOM:t: usein kysytyt kysymykset

Miten generoin SBOM:n Docker-kuvalle?

Yleisiä tapoja on kolme. Lisää --sbom=true komentoon docker buildx build, niin BuildKit liittää kuvaan SPDX-muotoisen SBOM:n. Aja docker scout sbom olemassa olevalle kuvalle. Tai aja Syft, esimerkiksi syft IMAGE -o cyclonedx-json. Kaikki kolme lukevat kuvasta löytämänsä paketit.

Mikä on SBOM-skanneri?

Työkalu, joka lukee tiedostoja, kuten lähdekoodihakemiston, lukitustiedoston tai konttikuvan, ja kirjoittaa SBOM:n tunnistamistaan paketeista. Syft, Trivy, Docker Scout ja BuildKitin Syft-lisäosa ovat SBOM-skannereita. Ne kuvaavat edessään olevia tiedostoja, eivät buildia, joka ne tuotti.

Mitä SBOM-formaattia Docker tuottaa?

BuildKitin attestaatiot ovat kuvaan liitettyjä SPDX JSON -dokumentteja. Docker Scout voi tulostaa pakettiluettelon tai kirjoittaa SPDX:ää tai CycloneDX:ää. Syft kirjoittaa molempia ja muitakin. Valitse formaatti, jota SBOM:ia käyttävä työkalu odottaa.

Miten skanneri rakentaa SBOM:n Docker-kuvasta?

Se purkaa kuvan kerrokset ja lukee löytämänsä pakettien metatiedot: käyttöjärjestelmän pakettitietokannan ja kielten pakettitiedostot, kuten asennettujen npm- tai Python-pakettien metatiedot. Jokaisesta tunnistamastaan paketista tulee merkintä SBOM:iin.

Miksi kuvan SBOM:sta puuttuisi komponentti?

Koska se voi luetella vain sen, minkä se tunnistaa lukemistaan tiedostoista. Curlilla ladatussa binäärissä ei ole pakettien metatietoja, buildivaiheen lataama ja poistama paketti ei jätä mitään luettavaa, ja aiemmat buildivaiheet jäävät pois, ellet ota vaiheiden skannausta käyttöön.

Onko kuvan SBOM silti hyödyllinen?

On. Se on oikea tallenne siitä, mitä toimittamasi kuvan sisällä on, peruskuvan paketit mukaan lukien. Se ei vain kuvaa, miten kuva buildattiin, joten käytä sen rinnalla buildin tallennetta silloin, kun sillä on merkitystä.