Kunders SBOM-förfrågningar: så svarar du

Levererar du komponenter eller inbyggd programvara till tillverkare? Se SBOM-guiden för leverantörer, som tar upp avtal, VEX och en SBOM per levererad programvaruversion.

Därför frågar kunderna nu

• Cyber Resilience Act. Tillverkare som säljer i EU behöver en SBOM för sin egen produkt och måste vara noggranna med de komponenter de tar in, så frågan vandrar vidare nedåt i leveranskedjan.
• NIS2. Väsentliga och viktiga entiteter måste hantera säkerheten i leveranskedjan. Direktivet nämner inte SBOM:er, men en SBOM är ett sätt för en köpare att se vad en leverantör levererar. Se SBOM:er som bevis för NIS2, ISO 27001 och SOC 2.
• Branschregler. FDA section 524B kräver en SBOM för cyberenheter, och andra branscher har egna regler.
• Deras eget sårbarhetsarbete. En kund som vet vad din produkt innehåller kan avgöra om en ny CVE påverkar dem utan att öppna ett supportärende.

Det här ska ni enas om innan du skickar något

Fråga	Varför det spelar roll
Vilken produkt och version?	En SBOM beskriver en release. Skicka den som kunden kör, inte det senaste bygget.
Vilket format?	De flesta förfrågningar godtar CycloneDX eller SPDX. Fråga om kunden behöver en specifik version.
Hur djupt?	Beroenden på högsta nivån räcker kanske inte. Räkna med att få frågor om transitiva beroenden.
En gång, eller med varje release?	Ett avtal kan förutsätta en ny SBOM för varje release, och det utesluter allt som görs för hand.
På vilka villkor?	En SBOM visar hur din produkt är byggd. Kom överens om sekretessvillkoren och hur filen ska levereras.

Det här innehåller ett bra svar

• En SBOM i det överenskomna formatet, för exakt den release som kunden kör.
• Varje komponent med namn, version, leverantör, licens och en paketidentifierare.
• Beroenderelationerna, så att ett transitivt paket kan spåras till det som drog in det.
• Datumet, verktyget som tog fram den och bygget den kom från.
• En ärlig notering om allt som SBOM:en inte täcker (se SBOM-fullständighet).

För hur filerna ser ut, se SBOM-exempel. Om de två formaten, se CycloneDX vs SPDX. För vad kunden sannolikt kontrollerar när filen kommer in, se checklistan för SBOM-kvalitet.

Misstag som kommer tillbaka senare

• Att skicka det senaste bygget i stället för det levererade. Byggen är inte reproducerbara som standard, så att bygga om samma commit ger ingen garanti för samma SBOM. Bara SBOM:en från bygget som producerade releasen visar vad kunden fick.
• Att sätta ihop den för hand för tillfället. Det uppfyller förfrågan en gång, och du måste göra om det för nästa kund och nästa release. Se SBOM-automatisering.
• Att lova mer än du kan upprepa. "Vi skickar en med varje release" är en enkel rad i ett avtal och svår att hålla utan automatisering.
• Att se SBOM:en som slutpunkten. Följdfrågan är "är ni drabbade av den här CVE:n?", och den kommer när nästa stora sårbarhet gör det.

Så blir du redo för nästa förfrågan

Förfrågningar blir enkla när SBOM:en redan finns. Ta fram en för varje release i pipelinen som bygger den, spara den med releasen och bevaka den för nya sårbarheter. Då kräver en förfrågan bara en nedladdning och en kort notering, och du kan besvara följdfrågan utifrån samma underlag.

Så hanterar CRACI det här

CRACI registrerar en SBOM från varje GitHub Actions-bygge som körs på dess runners, så varje release har redan en när någon frågar efter den.

• Export i CycloneDX eller SPDX, inklusive transitiva beroenden och de sårbarheter som hittats i komponenterna.
• Bevis från själva bygget. Varje komponent i SBOM:en fanns i bygget, och dolda beroenden som lockfile-baserade verktyg missar registreras.
• En fullständighetsstatus för varje jobb, så att du vet vad du skickar innan du skickar det.
• Bygghistorik. Du kan se tidigare byggen och deras SBOM:er, och vilka byggen som innehöll ett sårbart beroende, inom din lagringstid.
• Svar på följdfrågan. CRACI fortsätter att omvärdera bevakade SBOM:er, har stöd för VEX och visar vilka produkter som kör vilka versioner i inventarievyn.

Kunders SBOM-förfrågningar: vanliga frågor

Är vi skyldiga att ge kunder vår SBOM?

Det beror på din marknad och dina avtal. Cyber Resilience Act gör SBOM:en till en del av den tekniska dokumentationen, som lämnas till en marknadskontrollmyndighet på begäran, och kräver inte att den publiceras. En kunds rätt till den kommer oftast från avtalet, så kontrollera vad ni har kommit överens om.

Vilket SBOM-format ska vi skicka?

CycloneDX eller SPDX, det som kunden ber om. Om kunden inte har någon preferens fungerar båda. Fråga om kundens verktyg behöver en specifik version.

Måste vi ta med transitiva beroenden?

Cyber Resilience Act kräver åtminstone beroendena på högsta nivån, men många köpare förväntar sig hela trädet, och sårbarheter ligger ofta i transitiva paket. En fullständig SBOM är det säkrare svaret.

Ska SBOM:en gå till kunden under ett NDA?

Det är ett beslut för dig och din kund. En SBOM visar vad din produkt består av, så många leverantörer delar den under sitt befintliga avtal eller ett NDA i stället för att publicera den.

Hur ofta ska vi skicka en uppdaterad SBOM?

Så ofta som ni kommer överens om. Beroenden ändras med varje release, så en ny SBOM per release är det ärliga standardvalet, och det är bara praktiskt om SBOM:en kommer ur bygget.

Vad händer om kunden frågar om en äldre release?

Du behöver SBOM:en från bygget som producerade den releasen. CRACI sparar bygghistorik inom din lagringstid, 180 dagar som standard och anpassad lagringstid med Enterprise, så exportera det du behöver spara längre.

Vi har aldrig tagit fram en SBOM. Var börjar vi?

Börja med releasen som din kund kör och ett verktyg som utgår från ditt riktiga bygge. Om du använder GitHub Actions ger en flytt av bygget till CRACI-runners dig en registrerad SBOM från första körningen.