Ändå kommer Cyber Resilience (CRA), den kommande EU-­förordningen om CE-märkning för programvara, att innebära stora förändringar för flertalet utvecklare. CRA föreskriver nämligen att mycket av den här informationen ska delas med omvärlden – kunder i första hand men också myndig­heter. Sådant som idag är inkapslat i byggskript, make-filer och Jiraköer ska plockas fram i ljuset och publiceras. Och informationen ska hållas aktuell och tillgänglig tills fem år har gått sedan produkten slutade säljas.

– Förordningen kommer sannolikt antas senare i år, och därefter har alla tillverkare av produkter med programvara 18 månader på sig att få en process på plats för hantering och redovisning av sårbarheter samt 36 månader för att kvalificera sig för CE-märkningen, annars får de inte sälja sina produkter inom EU. Det gäller att vara redo, säger Olle E. Johansson, konsult i det egna företaget Edvina.

Syftet med att införa CRA är ytterst att köparen av en produkt ska få tillräckligt med information för att kunna bedöma om programkoden lever upp till ställda säkerhetskrav, och dessutom kunna lita på att eventuella sårbarheter som upptäcks efter köpet kommer att rättas till. I stora affärer hanteras den typen av krav vid förhandling och kontraktsskrivning, men den som säljer över disk till konsumenter och småföretag behöver ha en smidigare process – gärna automatiserad.

Två begrepp som ofta nämns i det här sammanhanget är SBOM (Software bill of materials, dvs materiallistor) och VEX (Vulnerability Exploitability eXchange, låt oss kalla det sårbarhetsaviseringar). Det rör sig om standardiserade format för att utbyta information om i det ena fallet kodmoduler och -bibliotek som ingår i det levererade systemet och i det andra fallet hur man har hanterat, eller avser att hantera, upptäckta sårbarheter. Det är inga nya begrepp, materiallistor är till exempel redan idag ett krav om du säljer till statliga myndigheter i USA, men de är nyttiga byggstenar för den som vill sätta ihop en automatiserad, CRA-kompatibel pipeline för program­varuproduktion.

Olle-E-Johansson

– Det är många som pekar på SBOM som ”lösningen” på CRA, men det är viktigt att komma ihåg att det bara är ett filformat, en transportmekanism om du så vill, säger Olle E. Johansson.

– Materiallistan ska förstås finnas där men lösningen är det system du bygger med hjälp av den och sårbarhetsaviseringarna för att utvärdera risker och prioritera arbetsuppgifter.

Och för att vara riktigt noga är det inte ETT filformat utan flera; det finns olika standarder att välja på som alla fyller i stort sett samma funktion.

Den information som behövs för att generera en materiallista finns som sagt normalt samlad i ett byggskript eller liknande, så det räcker med att lägga till ett byggsteg med lämpligt verktyg som skapar en lista för varje byggd version. Och om den egna produkten inkluderar moduler från andra leverantörer som kommer med egna materiallistor behöver man kunna ­importera dessa. ­Säkerhetskommuniteten OWASP har en praktisk webb­tjänst, Dependency Track [dependencytrack.org], som hanterar import, granskning och uppdatering av externa materiallistor.

Och vad är då sårbarhetsavi­seringar? Jo, om en sårbarhet upptäcks i din produkt, endera i egen kod eller i kod från en underleverantör, förväntas du svara med en deklaration om hur du kommer hantera den.

Fyra svar är möjliga:
• INGEN PÅVERKAN
(vår produkt använder inte just den här funktionen)
• PÅVERKAN
(användarna ­behöver vidta mått och steg, t ex uppdatera)
• LÖST
(felet är åtgärdat i en nyare version)
• VI UNDERSÖKER
(vi vet inte ännu)

Aviseringar ska utfärdas inte bara för senaste versionen av produkten utan också för äldre versioner så länge de täcks av CRA – fem år från försäljningsdatum. Och till skillnad från en materiallista, som är låst till en viss version av produkten och inte ändras, är sårbarhetsaviseringarna ett levande dokument som uppdateras så snart en sårbarhet som berör produkten upptäcks.

– Rätt hanterade kan de här dokumenten underlätta rejält för telefonsupporten nästa gång ett större säkerhetshål dyker upp. Dina kunder har material­listan och kan se om den trasiga ­modulen finns med i din produkt, och i så fall kan de läsa aviseringen för att se hur de ska göra, säger Olle E. Johansson.

Den av OWASP ­framtagna standarden CycloneDX ­[cyclonedx.org] är en bra startpunkt för dig som vill läsa mer om det här och få tips på öppenkodsverktyg.

Den kritik som har riktats mot CRA handlar huvudsakligen om hur regleringarna riskerar att slå mot utvecklare av öppen källkod: är det rimligt att den utvecklare som utan krav på ersättning låter sin kod användas av andra ska hållas ansvarig, juridiskt och ekonomiskt, för eventuella sårbarheter i koden? Problemet är i stort sett unikt för programvara; få andra näringar torde ha ett så stort utbud av insatsvaror som är både gratis och av god kvalitet.

Formellt sett undantas öppen källkod från reglerna i CRA, men det är ett fribrev med reservationer: kod som används i ”kommersiella aktiviteter” kan falla under CRA även om koden i sig är öppen och fritt tillgänglig. Och som exempel på kommersiella aktiviteter listas till exempel att åta sig betald teknisk support på koden eller att samla in användardata som kan utnyttjas för riktad annonsering.

GitHub är sannolikt världens största katalog för öppna källkodsprojekt, och Mike Links­vayer som är företagets chef för utvecklarrelationer har spaltat upp de tre i hans tycke viktigaste invändningarna mot CRA i dess nuvarande form.

1. Utvecklare som tar emot donationer riskerar att hamna under CRA-regelverket.
Att utveckla och underhålla öppen källkod kan vara ett tröstlöst arbete, och inte får man betalt heller. Samtidigt används koden av stora företag och myndigheter som möjligen skulle vilja betala för den men inte kan göra det. Donationer till en stiftelse eller liknande har varit ett sätt att brygga det gapet, där apache.org är ett välkänt exempel.

2. Utvecklare som är ­sponsrade av, eller anställda av, företag riskerar också att omfattas av CRA.
Ett annat sätt för företag att bidra är att ha anställda som ägnar sin arbetstid, hela eller del av den, till utveckling och underhåll av till öppen källkod. Även detta riskerar att bli omöjligt under CRA.

3. Kravet på omedelbar redovisning av sårbarheter omöjliggör dagens modell med samordnad redovisning.
Tanken med att öppet redovisa upptäckta sårbarheter är god, men det finns en fara med att göra det för snabbt: om informationen kommer i fel händer kan den utnyttjas för attacker mot dem som använder produkten i fråga. Vid samordnad redovisning hemlighålls sårbarheten till dess att det finns en rättelse tillgänglig, och då redovisas problem och lösning samtidigt. Det begränsar utrymmet för eventuella angripare att utnyttja sårbarheten.

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

Det finns vissa paralleller med EU:s reglering av persondata. När GDPR infördes 2018 reagerade åtskilliga amerikanska medier med att blockera besökare från EU, och risken är att många reagerar likadant på CRA och slutar distribuera sin öppna kod inom EU.