SBOM-forespørsler fra kunder: slik svarer du

Leverer du komponenter eller innebygd programvare til produsenter? Se SBOM-guiden for leverandører, som dekker kontrakter, VEX og en SBOM per levert programvareversjon.

Derfor spør kundene nå

• Cyber Resilience Act. Produsenter som selger i EU, trenger en SBOM for sitt eget produkt og må vise aktsomhet med komponentene de tar inn, så spørsmålet beveger seg nedover leverandørkjeden.
• NIS2. Vesentlige og viktige enheter må ta tak i sikkerheten i leverandørkjeden. Direktivet nevner ikke SBOM-er, men en SBOM er én måte for en kjøper å se hva en leverandør leverer. Se SBOM-er som bevis for NIS2, ISO 27001 og SOC 2.
• Sektorregler. FDA section 524B krever en SBOM for cyberenheter, og andre sektorer har egne regler.
• Deres eget sårbarhetsarbeid. En kunde som vet hva som er i produktet ditt, kan se om en ny CVE berører dem uten å åpne en supportsak.

Dette bør du avtale før du sender noe

Spørsmål	Hvorfor det er viktig
Hvilket produkt og hvilken versjon?	En SBOM beskriver én utgivelse. Send den de kjører, ikke det nyeste bygget.
Hvilket format?	De fleste forespørsler godtar CycloneDX eller SPDX. Spør om de trenger en bestemt versjon.
Hvor dypt?	Avhengigheter på toppnivå er kanskje ikke nok. Regn med å bli spurt om de transitive.
Én gang, eller med hver utgivelse?	En kontrakt kan forutsette en ny SBOM for hver utgivelse, noe som utelukker alt som gjøres for hånd.
På hvilke vilkår?	En SBOM viser hvordan produktet ditt er bygget. Avtal konfidensialitetsvilkårene og hvordan filen skal leveres.

Dette inneholder et godt svar

• En SBOM i det avtalte formatet, for den nøyaktige utgivelsen kunden kjører.
• Hver komponent med navn, versjon, leverandør, lisens og en pakkeidentifikator.
• Avhengighetsforholdene, så en transitiv pakke kan spores til det som trakk den inn.
• Datoen, verktøyet som produserte den, og bygget den kom fra.
• En ærlig merknad om alt SBOM-en ikke dekker (se SBOM-fullstendighet).

Hvordan filene ser ut, viser SBOM-eksempler. Om de to formatene, se CycloneDX vs SPDX. Hva kunden sannsynligvis sjekker ved mottak, viser sjekklisten for SBOM-kvalitet.

Feil som kommer tilbake senere

• Å sende det nyeste bygget i stedet for det leverte. Bygg er ikke reproduserbare som standard, så å bygge samme commit på nytt gir ingen garanti for samme SBOM. Bare SBOM-en fra bygget som produserte utgivelsen, viser hva kunden mottok.
• Å sette den sammen for hånd for anledningen. Det dekker forespørselen én gang, og du må gjenta det for neste kunde og neste utgivelse. Se SBOM-automatisering.
• Å love mer enn du kan gjenta. «Vi sender en med hver utgivelse» er en enkel setning i en kontrakt og en vanskelig en å holde uten automatisering.
• Å behandle SBOM-en som sluttstreken. Oppfølgingsspørsmålet er «er dere berørt av denne CVE-en?», og det kommer når neste store sårbarhet gjør det.

Slik er du klar for neste forespørsel

Forespørsler blir enkle når SBOM-en allerede finnes. Produser en for hver utgivelse i pipelinen som bygger den, oppbevar den sammen med utgivelsen, og overvåk den for nye sårbarheter. Da tar en forespørsel bare en nedlasting og en kort merknad, og du kan svare på oppfølgingsspørsmålet ut fra den samme registreringen.

Slik håndterer CRACI dette

CRACI registrerer en SBOM fra hvert GitHub Actions-bygg som kjører på runnerne, så hver utgivelse allerede har en når noen ber om den.

• Eksport i CycloneDX eller SPDX, inkludert transitive avhengigheter og sårbarhetene som er funnet i komponentene.
• Dokumentasjon fra selve bygget. Hver komponent i SBOM-en var med i bygget, og skjulte avhengigheter som lockfile-baserte verktøy går glipp av, blir registrert.
• En fullstendighetsstatus for hver jobb, så du vet hva du sender før du sender det.
• Byggehistorikk. Du kan se tidligere bygg og SBOM-ene deres, og hvilke bygg som inneholdt en sårbar avhengighet, innenfor oppbevaringstiden din.
• Svar på oppfølgingsspørsmålet. CRACI vurderer overvåkede SBOM-er fortløpende på nytt, støtter VEX og viser hvilke produkter som kjører hvilke versjoner i inventarvisningen.

SBOM-forespørsler fra kunder: ofte stilte spørsmål

Er vi pålagt å gi kundene SBOM-en vår?

Det avhenger av markedet og kontraktene dine. Cyber Resilience Act gjør SBOM-en til en del av den tekniske dokumentasjonen, som gis til en markedstilsynsmyndighet på forespørsel, og krever ikke at den publiseres. En kundes rett til den kommer vanligvis fra kontrakten, så sjekk hva du har avtalt.

Hvilket SBOM-format bør vi sende?

CycloneDX eller SPDX, det kunden ber om. Har de ingen preferanse, fungerer begge. Spør om verktøyene deres trenger en bestemt versjon.

Må vi ta med transitive avhengigheter?

Cyber Resilience Act ber om minst avhengighetene på toppnivå, men mange kjøpere forventer hele treet, og sårbarheter ligger ofte i transitive pakker. En fullstendig SBOM er det tryggere svaret.

Bør SBOM-en gå til kunden under en NDA?

Det er opp til deg og kunden din. En SBOM viser hva produktet ditt består av, så mange leverandører deler den under eksisterende kontrakt eller en NDA i stedet for å publisere den.

Hvor ofte bør vi sende en oppdatert SBOM?

Så ofte som dere avtaler. Avhengigheter endres med hver utgivelse, så en ny SBOM per utgivelse er det ærlige utgangspunktet, og det er bare praktisk mulig hvis SBOM-en kommer ut av bygget.

Hva om kunden spør om en eldre utgivelse?

Du trenger SBOM-en fra bygget som produserte den utgivelsen. CRACI beholder byggehistorikk innenfor oppbevaringstiden din, 180 dager som standard med tilpasset oppbevaring på Enterprise, så eksporter alt du må beholde lenger.

Vi har aldri laget en SBOM. Hvor begynner vi?

Begynn med utgivelsen kunden din kjører, og et verktøy som jobber ut fra det faktiske bygget ditt. Bruker du GitHub Actions, får du en registrert SBOM fra første kjøring ved å flytte bygget til CRACI-runnere.