Hotet bestod i att utvecklarna, trots att de erbjuder sina produkter utan att ta betalt, ändå riskerade att hållas ansvariga för sårbarheter i sin kod när den användes i kommersiella sammanhang. Grund­regeln är nu liksom tidigare att den öppenkodsutvecklare som inte ägnar sig åt någon ”kommersiell aktivitet” – inga licenser, ingen betald support, inga konsulttjänster, inga indirekta inkomster via till exempel datainsamling – undantas från CRA. Men där den första lagtexten var otydlig om exakt var gränsen för kommersiella aktiviteter skulle gå är den nya texten klarare.

Några exempel på tillagda ­preciseringar:
• Projekt som tar emot bidrag eller annat stöd från dem som använder deras produkter är undantagna från CRA, så länge stödet inte är så stort att projektet kan anses vara drivet i vinstsyfte.
• Icke vinstdrivna stiftelser som Eclipse och Apache är undantagna, så länge de kan visa att eventuella vinster används till att utveckla verksamheten.
• Man kan ta betalt för att täcka faktiska kostnader för support och fortfarande vara undan­tagen från CRA.

EU har verkligen lyssnat på OSS-gemenskapen, säger Olle E. Johansson, konsult med lång erfarenhet av öppen källkod.

– Man har besökt konferenser och suttit med i mängder av möten, och tagit till sig av de synpunkter som har förts fram. Resultatet har blivit en lag som är mycket bättre och tydligare när det gäller hur ­öppen källkod ska hanteras.

Grundtanken med Cyber Resilience Act, att en tillverkare av vad EU kallar ”produkter med digitala element” ska hållas ansvariga för eventuella säkerhetshål i sina produkter, står hur som helst kvar. Vid sidan av tillverkarna, som i det här sammanhanget syftar på dem som erbjuder produkter mot betalning, introducerar den modifierade CRA en ny roll, ”Open Source Software Steward”, för individer och institutioner som utvecklar och tillhandahåller öppen källkod utan att ta betalt. Det legala ansvaret för sårbarheter, även i öppen källkod, hamnar på tillverkarna medan stewards generellt sett undantas.

Så hur ska du då göra om du vill sälja en produkt inom EU som innehåller komponenter med öppen källkod, du är ”tillverkare” enligt CRA? Till att börja med: granska koden, och testa den ordentligt. Kontrollera också med publika databaser som till exempel cve.org om det finns kända sårbarheter som inte har åtgärdats. Gör detta för all öppen källkod i den SBOM (software bill of materials, eller materiallista) du ska upprätta enligt CRA.

Det är viktigt att också uppskatta den administrativa bördan och kostnaden av att ta in öppen källkod. Själva koden är förvisso gratis, men som tillverkare är du enligt CRA skyldig att uppdatera programvaran i din produkt om en sårbarhet upptäcks; den skyldigheten gäller så länge produkten säljs och sedan ytterligare fem år. Med andra ord: om din produkt inkluderar grafikbiblioteket gd, och om någon rapporterar en sårbarhet i Googles libwebp (som ingår i gd) har du plötsligt en känd sårbarhet i din produkt. Och den kräver CRA att du åtgärdar, inte bara för nya köpare utan också i redan sålda produkter som står ute hos dina kunder. I just det här fallet kan man nog räkna med att det kommer ett uppdaterat bibliotek från Google, men rent formellt är du ansvarig gentemot dina kunder/användare att laga felet.

Helst ska produkter vara så konstruerade att säkerhetsuppdateringar installeras automatiskt. Om automatisk uppdatering inte är möjlig eller rimlig krävs ändå att man informerar kunderna om att uppdateringen finns och att de kan ladda ner och installera den.

Det är förstås också möjligt att du som tillverkare själv hittar, eller blir uppmärksammad på, en tidigare okänd sårbarhet i en öppenkodsmodul du använder. Då är du skyldig att meddela den som underhåller koden – dess Steward – om sårbarheten, och även dela med dig av eventuella rättelser du gjort i koden.

CRA kräver att ett utvecklarteam som tar in öppen källkod också tar höjd för att hålla koll på sina beroenden och för att hantera rättelser, uppdateringar och nya releaser.

En annan möjlighet, om öppenkodslicen­sen tillåter det, är att göra en egen kopia (”fork”) av en komponent. Det ger handlingsfrihet när det till exempel blir aktuellt att lägga till nya funktioner, men det innebär också ansvar att ta hand om vidareutveckling och felrättelser själv. Man får inte del av de förbättringar som sker i originalkomponenten, och på sikt lär den egna kopian hamna på efterkälken. Men ur CRA-synvinkel fungerar det: du som tillverkare har det lagliga ansvaret gentemot användarna, oavsett om du använder en inlånad öppenkodskomponent eller en egen kopia av den.

Rollen som Open Source Software Steward är som sagt helt ny, den fanns inte med i det första utkastet av CRA. En steward kan vara en enskild utvecklare som underhåller något kodbibliotek, men det kan också vara någon av de stora öppenkodsstiftelserna som ­Apache Software Foundation, PHP Founda­tion eller Python Software Foundation. Just dessa tre har, tillsammans med Eclipse Foundation och ett par till, gått samman för att gemensamt ta fram processer och specifikationer för utveckling av säker öppen programvara. En av anledningarna till detta, skriver organisationerna i ett gemensamt pressmeddelande, är att visa att man stödjer införandet av CRA och vill arbeta i lagens anda.

Gruppen ska samla in erfarenheter från sina medlemmar, och från andra som vill vara med i arbetet, av hur cybersäkerhet ska hanteras i utvecklingsprocessen. Detta ska sedan sammanjämkas till ett gemensamt förslag och dokumenteras för att kunna ligga till grund för kommande EU-standarder som ska precisera de allmänt hållna kraven i CRA. Och inte bara EU, liknande krav finns redan idag i USA och kommer sannolikt dyka upp på andra håll i världen också.

Open Source Software Foundation (openssf.org) är en viktig resurs för öppenkodsutvecklare som vill ha hjälp och stöd med att säkra sin kod. Bland annat driver stiftelsen Alpha-Omega (alpha-omega.dev), en tvåhövdad satsning där Alpha stöttar stora eller på annat sätt ­viktiga projekt ekonomiskt medan Omega automatiskt skannar tusentals öppenkodsprojekt för att lokalisera kända och potentiella sårbarheter.

CRA är ännu inte formellt fastställd, den träder sannolikt i kraft 2027, och många detaljer kommer att dyka upp senare i olika EU-standarder. Det finns ändå ingen anledning att vänta längre, säger Olle E. Johansson.

Artikeln är tidigare publicerad i magasinet Elektroniktidningen. Prenumerera kostnadsfritt!

– Inriktningen är klar och det går alldeles utmärkt att börja analysera sitt gap redan nu: vilka produkter har vi som behöver uppdateras för CRA? Är det några som måste skrotas för att de inte kommer att kunna uppfylla lagens krav? Vilken kompetens behöver vi tillföra i utvecklingsteamet? Sådana frågor behöver besvaras så tidigt som möjligt.