Kammarkollegiets nya ramavtal för mjukvara är ett viktigt steg – men i en värld av NIS 2, CRA och Schrems II lämnas just nu dörren fortfarande dörren på glänt för allvarliga risker.
Här förklarar vi de sju krav som saknas – och varför de är avgörande för en säker och suverän digitalisering.
På Digitalist välkomnar vi Kammarkollegiets ambition att modernisera upphandlingen av mjukvara och tjänster i offentlig sektor. Initiativet att samla kompetens och kraft kring öppen källkod är rätt väg framåt. Samtidigt riskerar det aktuella ramavtalsutkastet att bli omodernt redan innan det träder i kraft.
Varför? Jo, för att det inte fångar den verklighet som offentliga aktörer redan befinner sig i – en verklighet formad av nya EU-lagar, ökade säkerhetskrav och en snabbt föränderlig teknisk infrastruktur.
Myndigheter upphandlar idag inte bara "programvara" eller "systemutveckling". De upphandlar säkra, suveräna och regelefterlevande plattformar – plattformar som måste leva upp till lagar som NIS 2, Cyber Resilience Act (CRA) och den kommande molncertifieringen EUCS.
Vi vill bidra konstruktivt. Därför summerar vi här de sju centrala krav vi menar måste in i ramavtalet – för att det ska stå pall både juridiskt, tekniskt och säkerhetsmässigt.
1 & 2. Den "Trojanska hästen" som hotar vår suveränitet
Detta är den största och mest akuta bristen. Problemet är dubbelt – en juridisk lucka och en teknisk naivitet.
Den juridiska luckan
En till synes oskyldig klausul öppnar för att en leverantörs standardvillkor automatiskt börjar gälla vid personuppgiftsbehandling. Det låter ofarligt, men innebär i praktiken att amerikanska molnaktörer kan använda sina egna villkor och därmed föra svensk myndighetsdata under amerikansk lag (US CLOUD Act).
Konsekvensen: känslig offentlig data kan lagligen tillgängliggöras för utländska myndigheter – i strid med både GDPR och Schrems II-domen.
Teknisk naivitet
Begreppet "privat moln" definieras enbart utifrån tekniska faktorer som nätverk och serverkapacitet. Inga krav finns på vem som äger infrastrukturen, vilken jurisdiktion driftpersonalen lyder under eller om driften verkligen sker inom EU/EES.
Resultatet är att ett datacenter i Sverige, men ägt och övervakat från USA, fortfarande räknas som "privat moln" i ramavtalet. I praktiken innebär det att svensk offentlig data kan lämna EU digitalt – även när den fysiskt finns här.
Vårt krav:
Ta bort den juridiska klausulen, och komplettera definitionen av "privat moln" med krav på att både datalagring och driftpersonalen omfattas av EES-jurisdiktion. Det är grunden för verklig datasuveränitet.
3. Makers vs Takers: Ansvar i källkoden är din bästa försäkring
Öppen källkod är inte ”gratis” – den kräver ansvar och delaktighet.
Skillnaden mellan en Maker och en Taker är avgörande:
En Taker använder andras kod utan att bidra tillbaka; en Maker deltar aktivt, bidrar med patchar och följer utvecklingen uppströms. Sannolikheten att en Makers kan hantera sårbarheter snabbare och säkrare i jämförelse med en Taker är väldigt stor.
I takt med att Cyber Resilience Act träder i kraft kommer mjukvaruleverantörer få ett tydligt juridiskt ansvar för att hantera sårbarheter genom hela livscykeln.
En leverantör som inte deltar aktivt i de open source-projekt de säljer kommer helt enkelt inte kunna uppfylla lagen.
Vårt krav:
Ramavtalet måste skilja mellan ”Makers” och ”Takers”. Leverantörer ska kunna visa konkreta, dokumenterade bidrag till de projekt de bygger sina tjänster på – inte bara använda dem.
4 & 5. Sluta köra “latest”: Säkerheten i leveranskedjan kräver kontroll
Två punkter som hänger ihop – containerhärdning och transparens genom SBOM (Software Bill of Materials).
Den tickande bomben i osäkrade containers
Många driftmiljöer bygger fortfarande på publika container-bilder – ofta "latest"-versioner från Docker Hub, utan härdning och eller revisionskontroll.
Detta är inte inte förenligt med professionella leveranser, men det är så en majoritet av IT tjänsterna i Sverige levereras av både leverantörer och myndigheters interna it organisationer. Samtidigt vet vi att brister i leveranskedjorna är ett av de stora orsakerna bakom de attacker vi läser om dagligen i media. Det är därför viktigt att detta motarbetas redan i kravställningen, något som CRA och NIS2 även trycker på.
Riktig säkerhet kräver:
- Minimala bascontainers, exempelvis Alpine Linux, för att minska attackytan
- Körning utan root-rättigheter
- Kontinuerlig sårbarhetsskanning och dokumenterad patchhantering
Härdning tar tid och kräver kompetens – men utan det finns ingen verklig säkerhet.
Transparens genom SBOM
En SBOM fungerar som mjukvarans innehållsförteckning. Den listar exakt vilka komponenter, bibliotek och versioner som ingår. Med den kan man följa upp sårbarheter, mäta risker och uppfylla CRA:s krav på ansvar i leveranskedjan.
Utan SBOM vet du inte vad din programvara egentligen består av – och kan därför inte veta om den är säker. En SBOM behöver dessutom vara statisk till nästa leverans, något som helt fallerar när leverantörer tillåter uppdateringar i webbgränssnitt, eller dör tekniker loggar in på servrar och utför manuella uppdateringar.
En SBOM skall vara ett recept vi bygger från, inte ett skript som svarar på frågan "Vad är det som körs egentligen"?
Vårt krav:
Ramavtalet måste kräva dokumenterad SBOM och processer för containerhärdning. Säkerhet kan inte vara ett tillägg – den måste vara inbyggd i kontraktet.
6. Moln på riktigt – inte VPS i förklädnad
Ordet ”moln” har urvattnats. Riktig molnteknik handlar inte om var servrarna står, utan om hur applikationerna byggs och förvaltas.
Den internationella 12-/15-faktor-metodiken för applikationsutveckling skapar just den robusthet, skalbarhet och portabilitet som dagens regelverk kräver. Applikationer byggda enligt dessa principer:
- Är stateless och tål avbrott
- Är förberedda för CI/CD-pipelines och frekventa säkra uppdateringar
- Är portabla och mer fria från inlåsning
En traditionell VPS-lösning kan aldrig leverera detta.
Vårt krav:
Ställ ska-krav på att leverantörer kan visa att deras tjänster utvecklas enligt 12-/15-faktor-principer och har dokumenterad CI/CD-pipeline.
7. NIS2 kräver drift 24/7 – inte 99,5 % kontorstid
Många samhällskritiska system måste fungera dygnet runt. Trots det föreslås en standard-SLA på 99,5 % tillgänglighet – mätt enbart under kontorstid. Det är en nivå som kanske fungerade 2005, inte 2025.
NIS 2 ställer krav på ständig tillgänglighet, incidentrapportering och krisreaktion. En e-tjänstportal eller regionjournal måste ha övervakning och support dygnet runt – oavsett om det är helg eller natt.
Vårt krav:
Säkerställ att ramavtalet kräver 24/7-övervakning och definierar drift på nivåer som 99,9 % eller 99,99 %, mätt över hela året. Det är hygienfaktor i en NIS 2-värld.
8. Bevisa det! ISO 27001 och 42001 slår AI-genererade policydokument
Allt fler leverantörer visar upp ”processer enligt ISO”, men långt ifrån alla är faktiskt certifierade. I dag kan vem som helst be en AI-modell att generera en snygg policy som uppfyller anbudskraven – på papper.
Det räcker inte längre. Kvalitet och säkerhet måste vara verifierbar.
Vårt krav:
Gör externa revisioner obligatoriska. Leverantörer ska kunna uppvisa giltiga, oberoende revisioner eller certifikat (t.ex. ISO 27001 för informationssäkerhet eller ISO 42001 för AI-styrning). En riktig stämpel på att säkerheten finns i praktiken – inte bara i texten.
Sammanfattning: En checklista för säker och suverän digitalisering
Kammarkollegiet har tagit ett viktigt initiativ. Men för att Sverige ska få den trygghet och effektivitet som EU nu kräver måste fokus flyttas till verifierbarhet och kompetens.
Checklista för regelefterlevnad – 7 krav på din open source leverantör och deras tjänster
Inför dessa sju krav, och vi kan säkerställa att Sverige blir ett föregångsland för suveräna, transparenta och säkra digitala lösningar.