Från ”docker compose up” till regelefterlevnad – varför "latest" inte räcker -Moderna molnapplikationer del 2

Det är idag enkelt att sätta upp nya applikationer med hjälp av öppen källkod och moderna verktyg. Men att bygga på "latest" av officiella releaser utan kontroll räcker inte längre. Nya EU-regler som CRA och NIS 2 kräver spårbarhet, dokumentation och riskhantering – något som utvecklingsmiljöer "rakt ut ur repos" sällan klarar. Här förklarar vi varför det är dags att lämna snabbvägarna och börja bygga hållbart.
Från ”docker compose up” till regelefterlevnad – varför "latest" inte räcker -Moderna molnapplikationer del 2
Tomas Persson
2025-05-13

Att leverera tjänster med "latest" av en officiell release är ofta direkt oseriöst

Det är idag extremt enkelt att sätta upp en ny tjänst med hjälp av open source och alla verktyg för utveckling som finns tillgängliga. 

- Git clone <projekt>
- docker compose up
sen funkar allt... eller?

Men officiella "latest"-releaser är sällan avsedda för produktion – och även om de är det, är det mycket svårt att uppfylla CRA (Cyber Resilience Act) och NIS 2 med dem. Ironiskt nog är det ändå så många IT-organisationer och stora leverantörer av tjänster levererar i produktion idag: snabbt, enkelt, men utan kontroll.

Den initiala nyttan är stor – men långsiktigt är strategin ohållbar!

I denna artikel ska vi förklara varför detta inte är en hållbar strategi och varför ni inte kommer att kunna möte de nya regleringarna med denna approch. 

Lösningsinriktning: Vad innebär regleringarna i praktiken?

Både CRA och NIS 2 kräver nya sätt att tänka kring applikationer och leveranser:

Cyber Resilience Act (CRA) - Systemägare ska kunna redovisa:


  1. Vad som kördes – exakta version och komponenter
  2.  När det kördes – tidslinje och uppdateringslogg
  3. Vilka sårbarheter som var kända vid drift
  4. Vad man gjorde åt dem – åtgärder och dokumentation

NIS 2 skärper ansvaret ytterligare. Det räcker inte att något ”känns säkert”.


Det måste finnas bevis – i form av loggar, ansvarsfördelning och åtgärdsplaner – som visar att ni har agerat proaktivt. 


Missar kan leda till sanktioner, både ekonomiska och juridiska.

Begränsningar i traditionell teknikstack

Att jobba vidare med lösningar baserade på VPS och traditionella servrar innebär konkreta utmaningar:


  1. Möjlighet till manuella ändringar (ingen spårbarhet)
  2. Ofta ingen versionerad pipeline eller CI/CD-struktur
  3. Uppdateringar kan ofta ske via "klick" i adminpaneler - (loggning och kontroll saknas)

En sådan miljö är i praktiken omöjlig att revidera i enlighet med CRA och NIS 2.

Exempel: Att använda "latest" mot att själv ta kontroll

För att förklara hur stor skillnaden är skall vi ge er ett verkligt exempel: OpenWebUI, ett open source-verktyg för AI-gränssnitt.

Så här såg det ut 2025-05-13

OpenWebUI

official image

  • 1390 CVEs
  • 4 Critical CVEs
  • Running as root

 OpenWebUI

Digitalist

  • 118 Kända CVEs
  • 0 Critical
  • Running with app user 



Den officiella image:en är inte byggd för produktion – men används som det. Det är inte bara oseriöst – det är en säkerhetsrisk.

Trots detta väljer många IT organisationer och leverantörer att helt bygga sina produktionsmiljöer baserat på dessa releaser.

Målet är alltid O CVEs

Ni ser ovan att även i vår release finns ett antal CVEs, det är normalt att man har det även om 118 kanske är lite i överkant. Det viktiga är att man alltid kontinuerligt arbetar med dessa och att man loggar sina riskbedömningar. 

Att ta kontroll: en modern strategi för produktion

Separera beroenden – paketera allt själv

  • Alla beroenden till OpenWebUI hanteras separat
  • Vi tar ansvar för kompatibilitet mellan alla komponenter

Automatisera

  • CI/CD med tester och scanning
  • Snabb feedback på fel och sårbarheter

Ha kompetens på det ni kör


  • För att prioritera 100+ CVEs krävs förståelse för hur applikationen faktiskt fungerar
  • De flesta säkerhetsbrister är inte relevanta – men utan kunskap saknas förmågan att veta vilka.

Kostnader – men också konsekvenser

Att göra jobbet enligt CRA och NIS 2 tar tid – det kostar. Problemet är att många leverantörer inte gör det jobbet idag. När du jämför pris på en tjänst bör du också jämföra:


  • Ingår dokumentation enligt CRA?
  • Finns versionshistorik över driftade system?
  • Sker leveranser utan manuella steg
  • Har leverantören ansvar för beroenden?
  • Finns teknisk kompetens för CVE-hantering?

Det här är inte valfria krav längre – det är tvingande.


CRA och NIS 2 är lagstadgade regleringar som redan gäller eller snart träder i kraft. 


Sammanfattning: Vad du bör kräva av en leverantör eller IT avdelning

En säker och compliant förvaltning kräver:


  • Spårbarhet – Ingen manuell förändring utan logg eller tester
  • Kontroll – Skanning och automatiska tester i drift
  • Modern – Byggd för moln, scriptad och containeriserad
  • Kompetent – Förvaltas av team med faktisk kunskap om stacken


Vill du lära dig mer om säkra molnapplikationer?

Håll utkik efter nästa inlägg i Bloggserien "Moderna molnapplikationer"!


Dela
Taggar
Arkiv
Moderna molnapplikationer för myndigheter: Så ökar ni säkerheten, effektiviteten och regelefterlevnaden
Molnapplikationer är inte längre bara en tekniktrend – de har på kort tid blivit en central del av hur organisationer utvecklar, driver och skalar digitala tjänster.