Under lång tid har sårbarheter i rena SaaS-tjänster varit svåra att följa upp: de saknade ofta CVE nummer och blandades ihop med klassisk produkt-/on-prem-logik. Nu finns en officiell lösning: CVE-taggen ”exclusively-hosted-service”.

Vad betyder den?

Taggen används när alla drabbade produkter endast finns som fullt hostade tjänster. Om både hostad och on-prem påverkas ska taggen inte användas. Det gör att vi kan särskilja ren SaaS från allt annat i CVE flödet och snabbare förstå vilken typ av åtgärd som faktiskt krävs.

Varför är det här viktigt?

– Tydligare ansvar och snabbare beslut: Molnleverantörer som Microsoft och Google markerar nu SaaS-CVE:er med denna tagg – ofta för att signalera att ingen kundåtgärd krävs eftersom fixen rullats ut i tjänsten. Det minskar brus och gör rapporteringen mer transparent.

– Bättre spårbarhet: Att SaaS sårbarheter får CVE nummer och konsekvent taggas stänger en gammal lucka i sårbarhetshantering där molnbrister tidigare föll mellan stolarna.

– Mognare prioritering: När källposten (CVE) anger att det rör sig om en “exclusively hosted service” kan vi prioritera rätt: bevaka påverkan, säkerställa kompensatoriska kontroller – men slippa lägga tid på patchplaner där leverantören redan åtgärdat. (Notera att alla verktyg ännu inte exponerar taggen lika tydligt.)

Exempel i praktiken

Microsofts första publiceringar av “cloud service CVEs” använder taggen för att klargöra att ingen kundpatch behövs (t.ex. CVE-2024-35260). Google Cloud har infört samma arbetssätt för kritiska brister i sina tjänster.

Min rekommendation

– Lägg till ett steg i er triagerutin som kontrollerar om CVE-posten har taggen ”exclusively-hosted-service”.

– Om taggen finns: bekräfta drifts-påverkan, verifiera att leverantören rullat ut fixen och dokumentera beslutet – men undvik onödig “patch-teater”.

– Om taggen saknas eller on-prem också påverkas: hantera enligt ordinarie process.

Detta är ett litet men viktigt steg mot bättre transparens och effektivare sårbarhetshantering i en verklighet där SaaS är normen.

Detta är ett gästinlägg skrivet av Oskar Edbro.

Att digital suveränitet har seglat upp som ett nyckelbegrepp är knappast förvånande. I ett geopolitiskt läge präglat av osäkerhet blir det avgörande att veta var data lagras, vem som tekniskt och juridiskt kan komma åt den och vilken lagstiftning som gäller. Vi är fortfarande beroende av hyperscalers som Microsoft Azure, Amazon Web Services och Google Cloud Platform, men vi kan inte lite på dessa leverantörer full ut.

Varför en plan B är nödvändig

• Amerikanska FISA §702 och liknande extraterritoriella lagar ger amerikanska myndigheter möjlighet att kräva utlämning av data – även om den lagras i EU-regioner
• Nya sanktioner eller exportkontroller kan snabbt begränsa åtkomsten till molnresurser.
• Domstolsbeslut (t.ex. Schrems II) har redan gjort det juridiskt riskabelt att lagra personuppgifter utanför EU/EES utan tillräckliga skyddsåtgärder
• Nationella säkerhetskrav i bl.a. Norge och Danmark uppmanar offentliga verksamheter att utreda hur de kan migrera bort från amerikanska molntjänster vid behov
• Kostnads- och prestandaoptimering kräver förhandlingsutrymme – något man bara får om man faktiskt kan byta leverantör

Så bygger du verklig handlingsfrihet

1. Dataklassificera – identifiera vilka informationsmängder som måste stanna inom EU/EES.
2. Designa för portabilitet – använd container- och orkestreringslösningar som fungerar oberoende av underliggande moln.
3. Upprätta exit-planer – kräv tydliga processer, tidsramar och kostnader för data-export i alla avtal.
4. Implementera multi- eller hybrid-cloud – sprid risker genom redundans hos olika leverantörer eller regioner.
5. Automatisera deployment – Infrastructure-as-Code gör det möjligt att återskapa hela miljöer hos en ny leverantör med kort varsel.
6. Bevaka lagstiftning och standarder – följ EU-initiativ som NIS 2, CRA och utvecklingen kring FISA §702-förlängningar.
7. Testa att återställning av backuper fungerar – Och att dessa med fördel ligger inom Sverige/EU.

Rekommenderade verktyg och ramverk

Kolla även in följande sajt för EU-alternativ:

• european-alternatives.eu

Nästa steg för din organisation

1. Utför en GAP-analys av nuvarande leverantörslåsning (En gapanalys, eller GAP-analys är ett verktyg för att identifiera skillnader mellan en organisations nuvarande tillstånd och dess önskade framtida tillstånd)
2. Prioritera åtgärder för system med hög riskprofil eller personuppgifter.
3. Testa er beredskap – Öva och testa att flytta en av era tjänster till en alternativ plattform
4. Förankra hos ledningen – digital suveränitet är lika mycket en affärsstrategisk som teknisk fråga. Förbered Er på att det kommer att kosta tid och resurser inom Er organisation!

Slutsats

Digital suveränitet handlar inte om att överge molnet, utan om att behålla kontrollen och förhandlingsstyrkan när omvärlden snabbt förändras. Genom att planera för data-portabilitet och ha en klar plan B minskar ni både juridisk och operativ risk den dag ni faktiskt behöver flytta.