Kravet på SBOM i CRA är en mening långt. Bilaga I del II punkt 1 kräver att tillverkare identifierar och dokumenterar sårbarheter och komponenter i sina produkter, bland annat genom att ta fram en programvaruförteckning (SBOM) i ett vanligt förekommande, maskinläsbart format som omfattar åtminstone beroendena på högsta nivå.

Meningen lämnar utrymme för tolkning. Så här kan ni läsa den, och detta är vad en granskare sannolikt kontrollerar.

Vad förordningen kräver

  • Ett vanligt förekommande, maskinläsbart format. I praktiken SPDX eller CycloneDX, som JSON eller XML. En lista i PDF uppfyller inte kravet, och ett egenhändigt gjort kalkylblad räknas knappast som ett vanligt förekommande format.
  • Åtminstone beroendena på högsta nivå. Om er firmware använder bibliotek A och bibliotek A använder bibliotek B, är A på högsta nivå och B transitivt. Lagens minimum är A.
  • En del av den tekniska dokumentationen. SBOM:en hör hemma i den dokumentation ni sparar för myndigheterna, och ni lämnar den till en marknadskontrollmyndighet på motiverad begäran (bilaga VII punkt 8).
  • Sparas i minst tio år efter att produkten släppts ut på marknaden, eller under supportperioden om den är längre (artikel 13.13).

Kommissionen får fastställa SBOM:ens format och innehåll i en genomförandeakt (artikel 13.24). Fram till dess är vägledningar som BSI TR-03183-2 och NTIA:s minimielement en rimlig utgångspunkt.

Vad den inte kräver

Ni behöver inte publicera er SBOM. CRA kräver ingen publicering. Ni får dela den med användarna, och gör ni det ska användarinformationen ange var (bilaga II punkt 9). Många tillverkare lämnar den till företagskunder under sekretessavtal och håller den annars intern. Vad ni än väljer, ange samma val i SBOM-rutinen, den tekniska dokumentationen och användarinformationen. En granskare jämför dem.

Högsta nivån är ett minimum. Sikta högre.

Många av de allvarliga sårbarheterna de senaste åren fanns i transitiva komponenter som ingen hade listat. En SBOM på högsta nivå uppfyller lagens bokstav men lämnar er blinda precis där det gör ont. Om era verktyg kan ta fram hela beroendeträdet, använd det.

En SBOM per släppt version

En SBOM beskriver ett bygge, inte en produkt. När version 4.0.1 levereras med ett åtgärdat bibliotek skiljer sig dess SBOM från 4.0.0. Spara en SBOM per släppt version tillsammans med releasen. När en ny sårbarhet dyker upp behöver ni svara för varje version som fortfarande finns ute, inte bara den senaste.

Varför det spelar roll i dag, inte 2027

Kravet på SBOM gäller från den 11 december 2027. Behovet börjar tidigare. Rapporteringen enligt artikel 14 gäller sedan den 11 september 2026, och den första frågan är alltid densamma: vilka av våra produkter och versioner innehåller den berörda komponenten, och går den sårbara funktionen att nå? Med en SBOM per version tar det minuter. Utan den kan det ta dagar, och 24-timmarsklockan väntar inte.

När en komponent finns men inte kan utnyttjas i er produkt, dokumentera analysen som en VEX-uppgift. Den visar att ni undersökte saken och varför ni inte rapporterade.

Där firmware-SBOM:er brister

Skannrar fungerar bra på paketmanifest. Inbyggd programvara består sällan bara av paketmanifest.

  • Binärfiler från kretsleverantörer. Radiofirmware, bootloaders och stängda drivrutiner kommer ofta som binärer utan metadata. Lägg in dem manuellt utifrån leverantörens uppgifter och ange källan.
  • Inkopierad kod. Ett bibliotek som kopierades in i ert repo för flera år sedan, kanske med lokala ändringar, syns inte för verktyg som läser pakethanterare. Leta upp det och lista det med sin ursprungliga version.
  • Statisk länkning. Kod som länkats in i en enda avbild lämnar inga separata filer att hitta. Ta fram SBOM:en från byggsystemet, som vet vad det länkade, inte bara från den färdiga avbilden.
  • Backend. Om er molntjänst är en del av produkten (databehandling på distans), överväg att ta med dess komponenter i SBOM:ens omfattning.
  • Leverantörskomponenter. Be leverantörerna om SBOM:er för det de levererar. Det är en del av er tillbörliga aktsamhet för komponenter (artikel 13.5), och från december 2027 behöver leverantörer som säljer komponenter separat ändå sådana.

Vad en användbar SBOM-post innehåller

För varje komponent: namn, version, leverantör, en unik identifierare (package URL eller CPE), en kryptografisk hash, licensen och beroenderelationen. För SBOM:en som helhet: produkt och version, upphovsperson, tidpunkt och vilket verktyg och vilken version som tog fram den. Den unika identifieraren är viktigast, eftersom det är den som gör att SBOM:en kan matchas automatiskt mot sårbarhetsdatabaser.

En kort checklista

  1. Välj SPDX eller CycloneDX och bestäm djupet: högsta nivån som minimum, hela trädet som mål.
  2. Ta fram SBOM:en i byggkedjan, från samma källa som releasen.
  3. Lägg in binära och inkopierade komponenter manuellt, med källa.
  4. Spara en SBOM per släppt version, oförändrad, i minst tio år.
  5. Matcha alla SBOM:er för versioner som stöds mot sårbarhetskällor, minst dagligen.
  6. Dokumentera fynd som inte kan utnyttjas som VEX-uppgifter.
  7. Bestäm om och hur ni delar SBOM:en, och säg samma sak i alla dokument.

Artikeln förklarar förordning (EU) 2024/2847 med enkla ord. Den är inte juridisk rådgivning.