The Linux Foundation gjorde i 2021 en undersøkelse som blant annet viste at 98% av deltakerne hørte til organisasjoner som på en eller annen måte benyttet Open Source komponenter i sine produkter. Selv om det har klare fordeler, er det å bygge programvare med Open Source verktøy eller bibliotek i grunn noe som åpner for sårbarheter som kan være vanskelige å holde oversikt over.
I dag finnes det flere verktøy og tjenester som har som formål å bidra til å overvåke potensielle sårbarheter knyttet til slike komponenter. Disse verktøyene scanner kildekode og genererer en oversikt over avhengigheter, sårbarheter og forslag til mitigering der det er mulig. De kan også overvåke sårbarhetsdatabaser og gi beskjed dersom nye sårbarheter knyttes til avhengighetene i prosjektet. Disse tjenestene er egnet for utviklingsteam, både i utviklingsfasen og etter publikasjon. Men denne informasjonen er utilgjengelig for brukere uten tilgang til kildekoden. Med andre ord er det ikke mulig for brukere av programvare å finne tilstrekkelig informasjon om innholdet og potensielle sårbarheter. For å bidra til større åpenhet rundt innholdet i programvare, har “The Software Bill of Materials” (SBOM) blitt utviklet.
Software Bill of Materials (SBOM)
En mye brukt analogi er at SBOM er en programvares ekvivalent til en matvares næringsinnholdsliste. En SBOM er en standardisert liste over komponenter, moduler og biblioteker brukt i et prosjekt, for å sikre åpenhet om avhengigheter i programvare der kildekoden ikke er tilgjengelig for brukerne. Denne listen kan brukes til å sjekke avhengighetene opp mot sårbarhetsdatabaser, for eksempel ved å bruke en tjeneste som Snyk eller et verktøy som OWASPs dependency-check.
SBOM i norsk programvare
I lys av nylige dataangrep på kritiske samfunnsfunksjoner i Norge, og et påfølgende behov for å styrke cybersikkerheten i norske organisasjoner, er det svært relevant å undersøke hvordan man kan overvåke indirekte sårbarheter i kritisk programvare. Etter et resultatløst Google-søk på SBOM og Norge, ble jeg interessert i å undersøke dette videre og vurdere potensialet for å innføre dette som en standard i norskprodusert programvare og som krav til programvare tatt i bruk i norske organisasjoner.
I 2021 utstedte Joe Biden en presidentordre som alle føderale organer er forpliktet å følge, gjeldende for programvare tatt i bruk i USA; “… Such guidance shall include standards, procedures, or criteria regarding: … (vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;“, er et slikt påbud noe vi også bør vurdere i Norge? Videre spesifiserte de; “Within 60 days of the date of this order, the Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration, shall publish minimum elements for an SBOM.”. Dette tyder på at det vil komme minstekrav for hva en SBOM bør inneholde, om ikke annet i USA. Undersøkelsen viste at deltakerne savnet en standard, så dette kan være starten på en bransjedekkende standard for SBOM. Det er i øyeblikket (minst) tre konkurrerende SBOM-formater; SPDX fra Linux Foundation, CycloneDX fra OWASP, og SWID som er definert i ISO/IEC 19770-2. Figuren under viser NTIAs forslag til minstekrav for innholdet i en SBOM.
Fremtidsutsikter
I den samme undersøkelsen utført av The Linux Foundation svarer deltakerne at de opplever at SBOM har fordeler som går ut over det å gjøre det lettere å overvåke sårbarheter knyttet til komponentene i applikasjonen. SBOM kan også bidra til økt bevissthet og forståelse for risiko knyttet til avhengighetene i et prosjekt og viktigheten av å ha kontroll på sårbarheter også utenfor utviklingsteamet.
FOSSA oppsummerer undersøkelsen med 6 punkter:
- Presidentordren har hatt effekt
- Sikkerheten rundt programvarens leverandørkjede krever flere løsninger
- Sikkerhet er ikke den eneste fordelen med SBOM
- Det er ennå tidlig i utviklingsfasen for SBOM
- Maskin-lesbarhet og avhengighetsdybde (“dependency depth”) er de viktigste behovene for SBOM
- “Open Source” er overalt.
Denne artikkelen antyder at bruken av SBOM øker, og at fremtidsutsiktene for en industri-dekkende standard for SBOM er gode. Likevel er det mangler når det kommer til faste rammer rundt format, hyppighet av re-generering og dybde på avhengighetstrær. Noe av dette kan forklares med at SBOM ennå er relativt nytt.
Artikkelen er skrevet som en del av sommerjobb i SINTEF i regi av SFI NORCICS