En kundes innkjøpsteam sender en liste med spørsmål, og ett av dem er kort: kan dere levere en programvarestykkliste (software bill of materials, SBOM)? Bak spørsmålet ligger en rimelig bekymring. Produktet ditt er delvis bygget av kode andre har skrevet, og når det blir funnet en svakhet i en av de delene, vil kunden din vite om den finnes i det de kjøpte.
Dette essayet forklarer hva dokumentet er, hvor forespørselen kommer fra, og hva du bør kunne svare. Det er ikke juridisk rådgivning, og ingenting her sier om produktet ditt oppfyller noen lov. Den vurderingen hører til deg og rådgiverne dine.
Hva en programvarestykkliste er
Det er en liste over delene programvaren din består av, og hvordan delene henger sammen. Amerikanske National Telecommunications and Information Administration (NTIA) beskriver den i The Minimum Elements For a Software Bill of Materials (SBOM), publisert 12. juli 2021, som «en formell oversikt som inneholder detaljene og forsyningskjedeforholdene til ulike komponenter som brukes til å bygge programvare».
Hvorfor kjøpere og myndigheter ber om en
En kjøper spør fordi en liste gjør et vanskelig spørsmål mulig å besvare. Når en svakhet i en mye brukt komponent blir kjent, kan en kunde som har listen din, sjekke den mot sine egne oversikter. En kunde uten den må spørre deg, og vente.
I Europa har forespørselen nå et rettslig grunnlag for noen produkter. Forordning (EU) 2024/2847, Cyber Resilience Act, vedtatt 23. oktober 2024, definerer en programvarestykkliste i artikkel 3 som «en formell oversikt som inneholder detaljer om og forsyningskjedeforhold for komponenter som inngår i programvareelementene i et produkt med digitale elementer».
Kravene til håndtering av sårbarheter i vedlegg I del II begynner med nr. 1, som ber produsenter om å «identifisere og dokumentere sårbarheter og komponenter i produkter med digitale elementer, blant annet ved å utarbeide en programvarestykkliste i et vanlig brukt og maskinlesbart format som minst dekker produktenes avhengigheter på øverste nivå».
Den samme forordningen sier hvem som får se den. Vedlegg VII, om teknisk dokumentasjon, tar den med «der det er relevant» og «etter en begrunnet anmodning fra en markedstilsynsmyndighet». Vedlegg II, om informasjon til brukere, ber om hvor den er tilgjengelig bare «dersom produsenten beslutter å gjøre programvarestykklisten tilgjengelig for brukeren». Etter artikkel 71 gjelder vedlegg I fra 11. desember 2027.
Om produktet ditt faller inn under forordningens virkeområde, er et spørsmål for rådgiverne dine. Essayet vårt Cyber Resilience Act, for produktledere dekker virkeområdet, datoene og resten av det teksten krever, så vi gjentar det ikke her.
Hva minimumselementene er
NTIA-rapporten deler minimumselementene inn i tre områder: datafelt, støtte for automatisering, og praksis og prosesser.
Datafeltene er de grunnleggende faktaene som registreres for hver komponent:
- Leverandørnavn: hvem som har laget, definert eller identifisert komponenten.
- Komponentnavn: hva leverandøren kaller den.
- Komponentens versjon: hvilken utgave av den du bruker.
- Andre unike identifikatorer: ytterligere identifikatorer som hjelper med å finne komponenten i andre oversikter.
- Avhengighetsforhold: hvilken komponent som inneholder hvilken.
- Forfatter av SBOM-dataene: hvem som skrev oversikten.
- Tidsstempel: når oversikten ble laget.
For støtte for automatisering ber rapporten om at oversikten er maskinlesbar, slik at den kan leses i stor skala. Den nevner tre formater som oppfyller dette: SPDX, CycloneDX og SWID-tagger.
Under praksis og prosesser dekker rapporten hvor ofte en ny oversikt lages (med hvert nytt bygg eller hver ny utgivelse), hvor dypt den går (minst komponentene på øverste nivå), hvordan du markerer det du ikke vet, hvordan oversikten deles og med hvem, og hvordan feil håndteres.
Det våre egne bygg viser
ClickDeeper, vårt eget produkt, viser hvor fort en slik oversikt blir utdatert. ClickDeeper leverte mer enn tusen lanseringer på tre måneder. I det tempoet er en oversikt som ikke fornyes ved hver lansering, utdatert allerede ved den neste.
Delene endrer seg også. I produktene vi drifter, venter nypubliserte versjoner av tredjepartspakker i 72 timer før de kan lanseres i et produkt. Nye pakkeversjoner venter før de når deg beskriver hva det gir deg.
Hva du bør kunne svare
Forespørselen er kort, men det ærlige svaret hviler på noen få ting som noen i selskapet ditt bør eie:
- Om dere kan lage en, for den versjonen en gitt kunde kjører.
- Hvor dypt den går, og om dere markerer delene dere ikke er sikre på.
- Hvem som holder den oppdatert når nye versjoner leveres.
- Hvem som kan få den, på hvilke vilkår, og hvordan en forespørsel når riktig person.
- Hva dere gjør videre når en av de listede komponentene viser seg å ha en svakhet.
Det siste betyr mest for kunden som spurte. En liste viser hva som er inni; det de egentlig kjøper, er tillit til at du vil handle på den.
Avklar disse spørsmålene én gang, og gi hvert av dem en eier. Da er neste innkjøpsliste et spørsmål om å slå opp, og du kan løfte blikket mot dit produktet skal.
Der vi kommer inn
Vi lager ikke programvarestykklister, og vi reviderer ikke avhengighetene dine. Vi gir heller ikke juridisk rådgivning eller lover samsvar, og vi vil ikke si når du er klar. Svarene over er dine å gi.
Der vi hjelper, er med sikkerhetsarbeid på produktet ditt, de delene du velger. Vi arbeider innenfor tilgangen du gir, og ikke noe mer. Arbeidet havner i ditt eget kodelager. Koden vi bygger for deg, er din. Du bestemmer hva som leveres. Ingenting når brukerne dine uten din godkjenning. Det starter med en samtale, helt uforpliktende. Harden security before the questionnaire arrives (på engelsk) viser hvordan det arbeidet ser ut.
