<KodLexikon/>
Illustration för security-programmering
← Alla artiklar
security11 min läsning2026-03-13

Sveriges e-plattform hackad: Vad utvecklare kan lära sig av CGI-intrånget

Jenkins-felkonfiguration, Docker-escape och hårdkodade nycklar i .git/config. Så fick en hotaktör tillgång till källkoden bakom Sveriges digitala identitet.

Den 12 mars 2026 publicerade en hotaktör under namnet ByteToBreach fullständig källkod från Sveriges e-plattform. Koden kom från ett intrång hos CGI Sverige AB — det kanadensiska IT-konsultbolaget som förvaltar stora delar av Sveriges digitala infrastruktur. Läckan inkluderade system som Mina Engagemang, Signe e-ID och SHS-integrationsplattformen.

För utvecklare är det här inte bara en nyhet. Det är en katalog över misstag som många av oss gör varje dag. Jenkins utan autentisering. Docker-gruppen som bakdörr. SSH-nycklar i .git/config. Låt oss gå igenom vad som hände och vad du kan göra för att undvika samma fällor.

Attackkedjan: Från Jenkins till fullständig kontroll

Intrånget började med en felkonfigurerad Jenkins-instans. Jenkins är ett av de mest använda CI/CD-verktygen, och när det exponeras utan korrekt autentisering blir det en inbjudan. Angriparen fick åtkomst till build-pipelines, miljövariabler och — kritiskt — Docker.

Jenkins-användaren var medlem i Docker-gruppen på värdmaskinen. Det är en vanlig genväg som ger Jenkins tillgång att bygga Docker-images utan sudo. Men det innebär också att Jenkins kan starta en container som monterar hela värdsystemets filsystem:

# Docker-escape: montera värdfilsystemet
docker run -v /:/host --privileged -it ubuntu bash

# Nu har du root-åtkomst till hela servern
cat /host/etc/shadow
cat /host/root/.ssh/id_rsa
ls /host/var/lib/jenkins/workspace/

Från den positionen hämtade angriparen SSH-nycklar, .hprof-filer (Java heap dumps med klartext-lösenord) och .git/config-filer med inbäddade credentials till CGI:s interna GitLab.

Felkonfiguration #1: Jenkins utan autentisering

En Jenkins-instans som är åtkomlig utan inloggning är öppen för alla. Det räcker inte med en brandvägg — du behöver autentisering på applikationsnivå.

# Jenkinsfile: Kontrollera att inga hemligheter exponeras i loggar
pipeline {
  agent any

  environment {
    // Använd Jenkins Credentials Plugin - ALDRIG hårdkoda
    DB_PASSWORD = credentials('prod-db-password')
    API_KEY     = credentials('external-api-key')
  }

  stages {
    stage('Build') {
      steps {
        // Maskera känsliga värden i konsoloutput
        sh '''
          set +x
          echo "Building with masked credentials..."
          ./build.sh --db-url="jdbc:postgresql://db:5432/app"
        '''
      }
    }
  }

  post {
    always {
      // Rensa workspace efter varje build
      cleanWs()
    }
  }
}

Använd Jenkins Credentials Plugin istället för miljövariabler i klartext. Aktivera Role-Based Access och kräv LDAP- eller SAML-autentisering. Exponera aldrig Jenkins på publika nätverk.

Felkonfiguration #2: Docker-gruppen som eskaleringsvektor

Att lägga till en användare i Docker-gruppen är i praktiken samma sak som att ge dem root-åtkomst. Docker-demonen kör som root, och alla i gruppen kan starta containers med fulla privilegier.

# INTE SÅ HÄR - ger i praktiken root
sudo usermod -aG docker jenkins

# ISTÄLLET: Använd rootless Docker
# Installation (som jenkins-användaren):
dockerd-rootless-setuptool.sh install

# Eller använd Podman (rootless by default):
podman build -t myapp .
podman run --rm myapp

# CI/CD-alternativ: Kaniko (bygger images utan Docker-daemon)
# Kräver ingen Docker-socket och körs i userspace
executor:
  - image: gcr.io/kaniko-project/executor:latest
    command: ["/kaniko/executor"]
    args:
      - "--context=."
      - "--destination=registry.example.com/myapp:latest"

Rootless Docker eller Podman eliminerar risken helt. I CI/CD-miljöer är Kaniko det bästa alternativet — det bygger container-images utan att behöva en Docker-daemon över huvud taget.

Felkonfiguration #3: Hemligheter i .git/config

Angriparna hittade inbäddade credentials direkt i .git/config-filer. Det är vanligare än man tror — särskilt i interna repon där ”ingen utomstående ser koden ändå”.

# SÅ HÄR ser en läckt .git/config ut:
[remote "origin"]
  url = https://admin:SuperSecret123@gitlab.internal.cgi.se/e-plattform/signe.git

# KORREKT: Använd credential helper
git config --global credential.helper store
# Eller ännu bättre - SSH-nycklar med passphrase:
git config --global url."git@gitlab.internal:".insteadOf "https://gitlab.internal/"

# Skanna efter läckta hemligheter INNAN commit:
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

# Installera:
pip install pre-commit
pre-commit install

Gitleaks som pre-commit hook fångar hemligheter innan de hamnar i historiken. Men det räcker inte — du behöver också skanna befintliga repon:

# Skanna ett helt repo efter historiska hemligheter
gitleaks detect --source=. --verbose

# Skanna bara staged ändringar
gitleaks protect --staged

# GitHub: Aktivera push protection
# Settings → Code security → Secret scanning → Push protection ✓

Vad läckte: Systemen bakom Sveriges digitala identitet

Läckan omfattade källkod för flera kritiska system:

  • Mina Engagemang — Frontend och backend för medborgarportalen där svenskar hanterar sina myndighetsärenden.
  • Signe & e-ID — E-signeringsportalen med SAML-metadata. Sveriges digitala underskriftsinfrastruktur.
  • SHS Integration — Routing och konfiguration för säker datautväxling mellan myndigheter.
  • Företrädarregistret — Auktoriserings-tjänster för fullmakter och behörigheter.

Utöver källkod hittades även RCE-testendpoints (Remote Code Execution), SQL-konfigurationer och Jenkins SSH-nycklar som möjliggjorde lateral rörelse i nätverket. 95% av Sveriges 10,7 miljoner invånare använder dessa e-tjänster.

Leverantörsberoendet: CGI och offentlig sektor

CGI är inte en liten aktör. De förvaltar kritisk IT-infrastruktur åt regeringar i flera länder. När en enda leverantör komprometteras sprider sig skadan över alla deras kunder. Dagen före e-plattformsläckan hackades även Viking Line— ett annat CGI-konto.

För utvecklare i offentlig sektor är lärdomen tydlig: supply chain securityär inte valfritt. Du behöver:

  • Regelbundna säkerhetsgranskningar av leverantörers CI/CD-miljöer
  • Nollförtroende-arkitektur — ingen implicit åtkomst baserat på nätverksposition
  • Separering av miljöer — test, staging och produktion ska aldrig dela credentials
  • Incidentresponsplan som inkluderar tredjepartsintrång

Praktisk checklista: Säkra din CI/CD-pipeline

Baserat på CGI-intrånget, här är en konkret checklista:

# 1. Jenkins: Aktivera autentisering och RBAC
#    Manage Jenkins → Security → Enable security ✓
#    Authorization: Project-based Matrix

# 2. Docker: Aldrig Docker-gruppen för CI-användare
id jenkins  # Kontrollera grupper
# Om "docker" syns → ta bort och använd rootless

# 3. Hemligheter: Skanna alla repon
for repo in /var/lib/jenkins/workspace/*/; do
  echo "=== Scanning $repo ==="
  gitleaks detect --source="$repo" --no-banner
done

# 4. SSH-nycklar: Rotera omedelbart
ssh-keygen -t ed25519 -C "deploy@$(hostname)" -f ~/.ssh/deploy_key
# Lägg till den nya nyckeln i GitLab/GitHub
# Ta bort den gamla

# 5. .hprof-filer: Rensa och blockera
find / -name "*.hprof" -delete
# Lägg till i .gitignore globalt:
echo "*.hprof" >> ~/.config/git/ignore

# 6. Nätverkssegmentering: Jenkins ska inte nå produktion
# iptables/nftables: Begränsa Jenkins-serverns utgående trafik
# till enbart nödvändiga endpoints

Sveriges och Danmarks digitala säkerhet

Sverige har länge varit föregångare inom öppen källkod i offentlig sektor. Myndigheten för digital förvaltning (DIGG) publicerar kod på GitHub, och Offentligkod.se katalogiserar öppen programvara i svensk förvaltning. Ironiskt nog läckte den proprietära koden, medan den öppna koden aldrig utgjorde en risk.

Danmark har tagit en annan väg med OS2 — ett föreningsbaserat samarbete mellan kommuner för öppen källkod. Med NIS2-direktivet implementerat i juli 2025 och ett nytt Ministerium för Beredskap etablerat i januari 2025, skärps kraven på alla leverantörer av kritisk infrastruktur.

Den gemensamma lärdomen: säkerhet handlar inte om att dölja koden — det handlar om att dölja nycklarna. CGI-intrånget berodde inte på att källkoden var värdefull i sig själv, utan på att credentials, konfigurationer och åtkomstnycklar låg inbäddade i den.

Sammanfattning

CGI-intrånget är inte exotiskt. Det är en kedja av vardagliga felkonfigurationer som många utvecklare känner igen. Jenkins utan MFA. Docker-gruppen som genväg. Hemligheter i repon ”för att det är internt ändå”.

Det som gör den här incidenten annorlunda är skalan: 95% av Sveriges befolkning berörs. Men den tekniska attackkedjan? Den kan replikeras mot vilken organisation som helst med samma typ av brister. Börja med din egen CI/CD-pipeline idag.

Källor

  1. Cointelegraph — Hackers Claim They Leaked Swedish E-Government Source Code (2026-03-12)
  2. DarkWebInformer — Full Source Code of Sweden's E-Government Platform Leaked (2026-03-12)
  3. DIGG Sweden — github.com/diggsweden
  4. Offentligkod.se — offentligkod.se
  5. r/programming (Reddit) — Diskussionstråd med 322+ uppröster (2026-03-12)