SBOM-verzoeken van klanten: zo beantwoordt u er een

Levert u componenten of embedded software aan fabrikanten? Zie de SBOM-gids voor leveranciers, die contracten, VEX en een SBOM per geleverde softwareversie behandelt.

Waarom klanten er nu om vragen

• De Cyber Resilience Act. Fabrikanten die in de EU verkopen, hebben een SBOM van hun eigen product nodig en moeten zorgvuldig omgaan met de componenten die ze opnemen, dus de vraag schuift door in de keten.
• NIS2. Essentiële en belangrijke entiteiten moeten ketenbeveiliging aanpakken. De richtlijn noemt SBOM's niet, maar met een SBOM kan een afnemer zien wat een leverancier levert. Zie SBOM's als bewijs voor NIS2, ISO 27001 en SOC 2.
• Sectorregels. FDA section 524B vereist een SBOM voor cyber devices, en andere sectoren hebben hun eigen regels.
• Hun eigen werk aan kwetsbaarheden. Een klant die weet wat er in uw product zit, kan zelf bepalen of een nieuwe CVE hem raakt, zonder een supportticket te openen.

Wat u afspreekt voordat u iets stuurt

Vraag	Waarom het ertoe doet
Welk product en welke versie?	Een SBOM beschrijft één release. Stuur die van de versie die de klant draait, niet de nieuwste build.
Welk formaat?	De meeste verzoeken accepteren CycloneDX of SPDX. Vraag of ze een specifieke versie nodig hebben.
Hoe diep?	Afhankelijkheden op het hoogste niveau zijn mogelijk niet genoeg. Reken erop dat naar transitieve wordt gevraagd.
Eenmalig, of bij elke release?	Een contract kan voor elke release een nieuwe SBOM verwachten, en dan valt alles wat handmatig gaat af.
Onder welke voorwaarden?	Een SBOM laat zien hoe uw product is opgebouwd. Spreek de geheimhoudingsvoorwaarden af en hoe het bestand wordt aangeleverd.

Wat een goed antwoord bevat

• Een SBOM in het afgesproken formaat, voor de exacte release die de klant draait.
• Elk component met naam, versie, leverancier, licentie en een pakket-ID.
• De afhankelijkheidsrelaties, zodat een transitief pakket te herleiden is tot wat het heeft binnengehaald.
• De datum, de tool die de SBOM heeft gemaakt en de build waaruit hij komt.
• Een eerlijke toelichting op alles wat de SBOM niet dekt (zie SBOM-volledigheid).

Hoe de bestanden eruitzien, leest u in SBOM-voorbeelden. Over de twee formaten, zie CycloneDX vs SPDX. Wat de klant waarschijnlijk bij ontvangst controleert, leest u in de SBOM-kwaliteitschecklist.

Fouten die later terugkomen

• De nieuwste build sturen in plaats van de geleverde. Builds zijn standaard niet reproduceerbaar, dus dezelfde commit opnieuw bouwen biedt geen garantie op dezelfde SBOM. Alleen de SBOM uit de build die de release heeft opgeleverd, laat zien wat de klant heeft ontvangen.
• Hem voor de gelegenheid met de hand samenstellen. Dat voldoet één keer aan het verzoek, en u moet het herhalen voor de volgende klant en de volgende release. Zie SBOM-automatisering.
• Meer beloven dan u kunt herhalen. "We sturen er een bij elke release" staat zo in een contract, maar is zonder automatisering moeilijk waar te maken.
• De SBOM als eindpunt zien. De vervolgvraag is "bent u getroffen door deze CVE?", en die komt zodra de volgende grote kwetsbaarheid opduikt.

Zo bent u klaar voor het volgende verzoek

Verzoeken worden eenvoudig als de SBOM er al is. Maak er een voor elke release in de pipeline die hem bouwt, bewaar hem bij de release en monitor hem op nieuwe kwetsbaarheden. Dan vraagt een verzoek alleen nog om een download en een korte toelichting, en beantwoordt u de vervolgvraag vanuit hetzelfde record.

Hoe CRACI dit aanpakt

CRACI legt een SBOM vast van elke GitHub Actions-build die op zijn runners draait, zodat elke release er al een heeft wanneer iemand erom vraagt.

• Export in CycloneDX of SPDX, inclusief transitieve afhankelijkheden en de kwetsbaarheden die in de componenten zijn gevonden.
• Bewijs uit de build zelf. Elk component in de SBOM zat in de build, en verborgen afhankelijkheden die tools op basis van lockfiles missen, worden vastgelegd.
• Een volledigheidsstatus voor elke job, zodat u weet wat u stuurt voordat u het stuurt.
• Buildgeschiedenis. Binnen uw bewaartermijn ziet u eerdere builds en hun SBOM's, en welke builds een kwetsbare afhankelijkheid bevatten.
• Antwoorden op de vervolgvraag. CRACI blijft gemonitorde SBOM's opnieuw beoordelen, ondersteunt VEX en toont in de inventarisweergave welke producten welke versies draaien.

SBOM-verzoeken van klanten: veelgestelde vragen

Zijn we verplicht klanten onze SBOM te geven?

Dat hangt af van uw markt en uw contracten. De Cyber Resilience Act maakt de SBOM onderdeel van de technische documentatie, die op verzoek naar een markttoezichtautoriteit gaat, en verplicht niet tot publicatie. Het recht van een klant op de SBOM komt meestal uit het contract, dus controleer wat u hebt afgesproken.

Welk SBOM-formaat moeten we sturen?

CycloneDX of SPDX, afhankelijk van wat de klant vraagt. Heeft de klant geen voorkeur, dan werken beide. Vraag of de tools van de klant een specifieke versie nodig hebben.

Moeten we transitieve afhankelijkheden opnemen?

De Cyber Resilience Act vraagt minimaal om de afhankelijkheden op het hoogste niveau, maar veel afnemers verwachten de volledige boom, en kwetsbaarheden zitten vaak in transitieve pakketten. Een volledige SBOM is het veiligere antwoord.

Moet de SBOM onder een NDA naar de klant?

Dat bepaalt u samen met uw klant. Een SBOM laat zien waaruit uw product bestaat, dus veel leveranciers delen hem onder hun bestaande contract of een NDA in plaats van hem te publiceren.

Hoe vaak moeten we een bijgewerkte SBOM sturen?

Zo vaak als u afspreekt. Afhankelijkheden veranderen met elke release, dus een nieuwe SBOM per release is de eerlijke standaard, en dat is alleen haalbaar als de SBOM uit de build komt.

Wat als de klant naar een oudere release vraagt?

Dan hebt u de SBOM nodig uit de build die die release heeft opgeleverd. CRACI bewaart de buildgeschiedenis binnen uw bewaartermijn, standaard 180 dagen en met een aangepaste bewaartermijn op Enterprise, dus exporteer alles wat u langer wilt bewaren.

We hebben nog nooit een SBOM gemaakt. Waar beginnen we?

Begin met de release die uw klant draait en een tool die uitgaat van uw echte build. Werkt u met GitHub Actions, dan krijgt u door de build naar CRACI-runners te verplaatsen vanaf de eerste run een vastgelegde SBOM.