Kunders SBOM-anmodninger: sådan svarer du

Leverer du komponenter eller indlejret software til producenter? Se SBOM-guiden for leverandører, som dækker kontrakter, VEX og en SBOM pr. leveret softwareversion.

Hvorfor kunderne spørger nu

• Cyber Resilience Act. Producenter, der sælger i EU, skal have en SBOM for deres eget produkt og skal udvise omhu med de komponenter, de tager ind, så spørgsmålet bevæger sig ned gennem forsyningskæden.
• NIS2. Væsentlige og vigtige enheder skal tage hånd om sikkerheden i forsyningskæden. Direktivet nævner ikke SBOM'er, men en SBOM er én måde, hvorpå en køber kan se, hvad en leverandør leverer. Se SBOM'er som dokumentation for NIS2, ISO 27001 og SOC 2.
• Sektorregler. FDA section 524B kræver en SBOM for cyber devices, og andre sektorer har deres egne regler.
• Deres eget sårbarhedsarbejde. En kunde, der ved, hvad der er i dit produkt, kan se, om en ny CVE berører dem, uden at oprette en supportsag.

Hvad du skal aftale, før du sender noget

Spørgsmål	Hvorfor det betyder noget
Hvilket produkt og hvilken version?	En SBOM beskriver én release. Send den, kunden kører, ikke det seneste build.
Hvilket format?	De fleste anmodninger accepterer CycloneDX eller SPDX. Spørg, om kunden har brug for en bestemt version.
Hvor dybt?	Afhængigheder på øverste niveau er måske ikke nok. Regn med at blive bedt om de transitive.
Én gang eller ved hver release?	En kontrakt kan forvente en ny SBOM for hver release, og det udelukker alt, der laves i hånden.
På hvilke vilkår?	En SBOM viser, hvordan dit produkt er bygget. Aftal fortrolighedsvilkårene, og hvordan filen leveres.

Det indeholder et godt svar

• En SBOM i det aftalte format for præcis den release, kunden kører.
• Hver komponent med navn, version, leverandør, licens og en pakkeidentifikator.
• Afhængighedsrelationerne, så en transitiv pakke kan spores til det, der trak den ind.
• Datoen, det værktøj, der producerede den, og det build, den kom fra.
• En ærlig note om alt det, SBOM'en ikke dækker (se SBOM-fuldstændighed).

Hvordan filerne ser ud, kan du se i SBOM-eksempler. Om de to formater, se CycloneDX vs SPDX. Hvad kunden sandsynligvis tjekker ved modtagelsen, kan du se i tjeklisten for SBOM-kvalitet.

Fejl, der kommer tilbage senere

• At sende det seneste build i stedet for det leverede. Builds er ikke reproducerbare som standard, så en genbygning af det samme commit giver ingen garanti for den samme SBOM. Kun SBOM'en fra det build, der producerede releasen, viser, hvad kunden modtog.
• At samle den i hånden til lejligheden. Det opfylder anmodningen én gang, og du må gentage det for den næste kunde og den næste release. Se SBOM-automatisering.
• At love mere, end du kan gentage. "Vi sender en med hver release" er let at skrive ind i en kontrakt og svært at overholde uden automatisering.
• At behandle SBOM'en som afslutningen. Det næste spørgsmål er "er I berørt af denne CVE?", og det kommer, når den næste store sårbarhed gør.

Sådan er du klar til næste anmodning

Anmodninger bliver lette, når SBOM'en allerede findes. Producér en for hver release i den pipeline, der bygger den, gem den sammen med releasen, og overvåg den for nye sårbarheder. Så kræver en anmodning kun en download og en kort note, og du kan svare på det næste spørgsmål ud fra den samme registrering.

Sådan håndterer CRACI det

CRACI registrerer en SBOM fra hvert GitHub Actions-build, der kører på dets runnere, så hver release allerede har en, når nogen beder om den.

• Eksport i CycloneDX eller SPDX, inklusive transitive afhængigheder og de sårbarheder, der er fundet i komponenterne.
• Dokumentation fra selve buildet. Hver komponent i SBOM'en var med i buildet, og skjulte afhængigheder, som lockfile-baserede værktøjer overser, bliver registreret.
• En fuldstændighedsstatus for hvert job, så du ved, hvad du sender, før du sender det.
• Build-historik. Du kan se tidligere builds og deres SBOM'er, og hvilke builds der indeholdt en sårbar afhængighed, inden for din opbevaringsperiode.
• Svar på det næste spørgsmål. CRACI bliver ved med at genvurdere overvågede SBOM'er, understøtter VEX og viser, hvilke produkter der kører hvilke versioner, i inventory-visningen.

Kunders SBOM-anmodninger: ofte stillede spørgsmål

Er vi forpligtet til at give kunderne vores SBOM?

Det afhænger af dit marked og dine kontrakter. Cyber Resilience Act gør SBOM'en til en del af den tekniske dokumentation, som på anmodning går til en markedsovervågningsmyndighed, og den kræver ikke, at den offentliggøres. En kundes ret til den kommer som regel fra kontrakten, så tjek, hvad du har aftalt.

Hvilket SBOM-format skal vi sende?

CycloneDX eller SPDX, alt efter hvad kunden beder om. Har kunden ingen præference, kan begge bruges. Spørg, om kundens værktøjer har brug for en bestemt version.

Skal vi have transitive afhængigheder med?

Cyber Resilience Act kræver som minimum afhængighederne på øverste niveau, men mange købere forventer hele træet, og sårbarheder sidder ofte i transitive pakker. En fuld SBOM er det sikrere svar.

Skal SBOM'en gå til kunden under en NDA?

Det er din og din kundes beslutning. En SBOM viser, hvad dit produkt består af, så mange leverandører deler den under deres eksisterende kontrakt eller en NDA i stedet for at offentliggøre den.

Hvor ofte skal vi sende en opdateret SBOM?

Så ofte som I aftaler. Afhængigheder ændrer sig med hver release, så en ny SBOM pr. release er den ærlige standard, og det er kun praktisk, hvis SBOM'en kommer ud af buildet.

Hvad hvis kunden spørger til en ældre release?

Du skal bruge SBOM'en fra det build, der producerede den release. CRACI gemmer build-historik inden for din opbevaringsperiode, som standard 180 dage og med tilpasset opbevaring på Enterprise, så eksportér alt, du skal beholde længere.

Vi har aldrig lavet en SBOM. Hvor skal vi starte?

Start med den release, din kunde kører, og et værktøj, der arbejder ud fra dit rigtige build. Hvis du bruger GitHub Actions, giver det dig en registreret SBOM fra første kørsel at flytte buildet til CRACI-runnere.