Säkerhetsgranskning steg för steg i CI/CD-pipelinen

En effektiv DevSecOps-pipeline har säkerhetskontroller i varje fas. Här är den modell vi rekommenderar och implementerar hos våra kunder:

Fas 1: Planering och design — threat modeling

Innan en enda rad kod skrivs bör teamet genomföra threat modeling. Det innebär att systematiskt identifiera vilka hot som är relevanta för den komponent som ska byggas: vilka data hanteras, vilka gränssnitt exponeras, vilka aktörer kan tänkas attackera.

STRIDE-modellen (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) är ett beprövat ramverk. Det viktiga är inte vilken metod ni väljer, utan att ni gör det innan arkitekturbeslut cementeras. Designfel som identifieras här kostar en bråkdel att åtgärda jämfört med samma fel upptäckt i produktion.

Fas 2: Kodskrivning — IDE-plugins och pre-commit hooks

Utvecklarens editor är den första försvarslinjen. SAST-verktyg som Semgrep eller SonarLint kan köras direkt i IDE:n och flagga osäkra mönster medan utvecklaren skriver kod. Pre-commit hooks med verktyg som GitLeaks fångar hårdkodade hemligheter (API-nycklar, lösenord) innan de ens når versionshanteringen.

Det här steget handlar om snabb feedback. En utvecklare som får en varning tre sekunder efter att ha skrivit en osäker SQL-fråga lär sig snabbt. En utvecklare som får samma feedback tre veckor senare i en säkerhetsrapport glömmer kontexten.

Fas 3: Build och CI — automatiserade skanningar

Här körs de tunga automatiserade kontrollerna:

• SAST (Static Application Security Testing) — analyserar källkoden utan att köra den. Hittar injektionssårbarheter, osäker kryptering, auktoriseringsproblem.
• SCA (Software Composition Analysis) — skannar tredjepartsberoenden mot kända sårbarheter (CVE-databaser). Verktyg som Trivy eller Snyk ger besked om ett npm-paket eller en Maven-artefakt har kända säkerhetshål.
• Container-skanning — om ni bygger container-images (och det gör de flesta), bör varje image skannas mot kända sårbarheter i basimage och installerade paket.

En pipeline som fallerar vid kritiska säkerhetsfynd (severity high/critical) etablerar en tydlig kvalitetsgrind. Vår erfarenhet är att detta initialt upplevs som frustrerande av utvecklare, men inom några veckor anpassar sig teamet och antalet blockerande fynd minskar dramatiskt.

Fas 4: Test och staging — DAST och integrationstester

När applikationen är deployad i en testmiljö kan dynamiska tester köras:

• DAST (Dynamic Application Security Testing) — testar den körande applikationen utifrån, som en angripare. OWASP ZAP är standardverktyget här och kan automatiseras i CI/CD.
• IAST (Interactive Application Security Testing) — kombinerar SAST och DAST genom att instrumentera applikationen under test.
• Automatiserade säkerhetsregressioner — testsviter som verifierar att tidigare åtgärdade sårbarheter inte återintroduceras.

Fas 5: Produktion — runtime-skydd och övervakning

Säkerhetsgranskning slutar inte vid deploy. I produktion behövs:

• Runtime Application Self-Protection (RASP) eller Web Application Firewall (WAF)
• Loggaggregering och SIEM — centraliserad analys av säkerhetshändelser
• Kontinuerlig sårbarhetsskanning — nya CVE:er publiceras dagligen; era produktionssystem måste skannas löpande

Det är här Opsios 24/7 SOC/NOC adderar verkligt värde. Automatiserade skanningar hittar kända sårbarheter, men det krävs mänsklig analys för att bedöma kontext: är den här sårbarheten exploaterbar i just er miljö? Vilken åtgärd ger störst riskreduktion per insatt timme?

Managerad molnsäkerhet

Verktygskedjan — vad som faktiskt fungerar 2026

Marknaden svämmar över av DevSecOps-verktyg. Baserat på vad vi ser fungera i produktion hos svenska organisationer rekommenderar vi följande grunduppsättning:

En viktig princip: börja med få verktyg som ni faktiskt använder och agerar på. Fem skanners som genererar tusentals varningar som ingen tittar på är värre än en skanner med tydliga regler och obligatorisk åtgärd.

Managerad DevOps

NIS2, GDPR och regulatorisk drivkraft

Svenska organisationer — särskilt inom kritisk infrastruktur, hälso- och sjukvård, energi och finans — står under ökande regulatoriskt tryck att dokumentera sin säkerhetshantering.

NIS2-direktivet, som trädde i kraft 2024, ställer explicita krav på riskhanteringsåtgärder för cybersäkerhet, inklusive:

• Policies och rutiner för riskanalys och informationssäkerhet
• Incidenthantering och rapportering (inom 24 timmar för tidiga varningar)
• Säkerhet i leveranskedjan — vilket direkt berör tredjepartsberoenden i er kodbas
• Kryptering och åtkomstkontroll

En väl implementerad DevSecOps-pipeline genererar automatiskt mycket av den dokumentation som NIS2 kräver: vilka skanningar har körts, vilka fynd har identifierats, vilka åtgärder har vidtagits, och av vem. Den spårbarheten är guld värd vid en granskning från tillsynsmyndighet.

GDPR ställer krav på "lämpliga tekniska och organisatoriska åtgärder" (artikel 32). Automatiserad säkerhetsgranskning i CI/CD är ett konkret sätt att visa att ni tar det kravet på allvar. Integritetsskyddsmyndigheten (IMY) har i flera tillsynsärenden lyft fram bristande tekniska skyddsåtgärder som grund för sanktionsavgifter.

Molnsäkerhet och efterlevnad

Kulturskiftet: den svåraste delen

Vi kan vara ärliga: verktygen är den enkla biten. Det som avgör om en DevSecOps-satsning lyckas eller misslyckas är kulturen.

Vanliga fallgropar

"Säkerhetsteamet äger fortfarande allt." Om utvecklare skickar sina fynd till en säkerhetsavdelning som prioriterar och åtgärdar, har ni bara automatiserat den gamla processen. Utvecklare måste äga sina fynd.

"Vi slog på allt på en gång." Att aktivera SAST, DAST, SCA och container-skanning i samtliga pipelines samma dag genererar en tsunami av varningar. Teamet blir överväldigat och stänger av verktygen. Börja med en kategori, etablera en arbetsprocess, och skala sedan.

"Säkerhetsfynd blockerar aldrig bygget." Om skanningsresultat bara genererar rapporter som ingen läser, förändras ingenting. Ni behöver definierade tröskelvärden där bygget faktiskt fallerar — och ledningens stöd att hålla den linjen även under leveranspress.

Vad som faktiskt fungerar

• Security champions — utse en utvecklare per team som får extra säkerhetsutbildning och fungerar som brygga till säkerhetsspecialisterna.
• Gamification — mät och synliggör säkerhetsskuld per team. Inte för att skuldbelägga, utan för att skapa medvetenhet.
• Blameless post-mortems — när sårbarheter hittas i produktion, analysera processen, inte personen. Varför passerade det alla kontroller? Vad kan automatiseras?
• Utbildning integrerad i arbetsflödet — korta, kontextuella utbildningsmoduler som triggas av specifika fynd ("Du skrev en SQL-fråga som är sårbar för injektion — här är varför och hur du fixar det").

Molnspecifika överväganden

De flesta svenska organisationer kör arbetsbelastningar på AWS, Azure eller Google Cloud — ofta i kombination. Varje molnplattform erbjuder inbyggda säkerhetstjänster som bör integreras i er DevSecOps-pipeline:

AWS (eu-north-1, Stockholm): AWS Security Hub aggregerar fynd från GuardDuty, Inspector och tredjepartsverktyg. Inspector kan automatiskt skanna ECR-images och Lambda-funktioner. Integrera med AWS CodePipeline eller er egen CI/CD.

Azure (Sweden Central): Microsoft Defender for Cloud ger liknande aggregering. Azure DevOps Pipelines har inbyggt stöd för säkerhetsskanningsuppgifter. GitHub Advanced Security (GHAS) är en stark option för organisationer som använder GitHub.

Multimoln: Här blir tredjepartsverktyg som Prisma Cloud, Wiz eller Orca värdefulla för att få en enhetlig säkerhetsbild. Alternativt kan open source-stacken (Trivy + Checkov + OPA) ge god täckning utan leverantörslåsning.

Oavsett plattform är IaC-skanning (Infrastructure as Code) kritiskt. Om ni definierar infrastruktur i Terraform, Pulumi eller CloudFormation ska den koden genomgå samma säkerhetsgranskning som applikationskoden. Checkov och tfsec fångar felkonfigurationer som publikt exponerade S3-buckets eller databaser utan kryptering — innan de ens skapas.

Managerade molntjänster

Mätning och KPI:er

Vad som inte mäts förbättras inte. Relevanta mätvärden för DevSecOps-säkerhetsgranskning:

• Mean Time to Remediate (MTTR) — hur lång tid tar det från att en sårbarhet identifieras till att den är åtgärdad? Mål: under 48 timmar för kritiska fynd.
• Sårbarhetsdensitet — antal kända sårbarheter per 1 000 rader kod. Trenden är viktigare än absolutvärdet.
• Pipeline pass rate — andel byggen som passerar säkerhetsgranskningarna. En gradvis ökning visar att teamet lär sig.
• Tid till feedback — hur snabbt får utvecklaren besked om ett säkerhetsproblem? Mål: under 10 minuter i CI.
• Andel åtgärdade fynd — hur stor del av identifierade sårbarheter som faktiskt åtgärdas (inte bara suppressas).

Flexeras State of the Cloud har konsekvent visat att säkerhet rankas som en av de största utmaningarna för molnbaserad utveckling. DevSecOps-mätvärden ger er konkret data att visa ledningen att investeringen ger resultat.

Cloud FinOps

Så kommer ni igång — en pragmatisk plan

Månad 1–2: Välj ett pilotteam och en applikation. Implementera SAST (Semgrep) och SCA (Trivy) i CI-pipelinen. Sätt tröskelvärden på "critical only" för att undvika varningsutmattning.

Månad 3–4: Lägg till secrets-skanning (GitLeaks) och IaC-skanning (Checkov). Utse en security champion i pilotteamet. Börja mäta MTTR.

Månad 5–6: Introducera DAST (OWASP ZAP) i staging-miljön. Sänk tröskelvärdena till att inkludera "high severity". Genomför en retrospektiv: vad fungerar, vad behöver justeras?

Månad 7–12: Skala till fler team. Implementera threat modeling i planeringsfasen. Integrera med SIEM/SOC för runtime-övervakning. Dokumentera processer för NIS2-efterlevnad.

Månad 12+: Förfina policies, automatisera compliance-rapportering, och etablera kontinuerlig förbättring genom regelbundna säkerhetsretrospektiver.

Molnmigrering

Vanliga frågor

Vad skiljer DevSecOps från vanlig DevOps?

I DevOps ligger fokus på snabba leveranser genom samarbete mellan utveckling och drift. DevSecOps utökar det med säkerhet som en integrerad del av varje steg — från planering och kodskrivning till deploy och drift. Säkerhet blir hela teamets ansvar istället för en separat granskningsfunktion.

Vilka verktyg behöver vi för DevSecOps-säkerhetsgranskning?

En grundläggande verktygskedja inkluderar SAST (statisk kodanalys, t.ex. SonarQube eller Semgrep), SCA (beroendeanalys, t.ex. Snyk eller Trivy), DAST (dynamisk testning, t.ex. OWASP ZAP) och secrets-skanning (t.ex. GitLeaks). Dessa integreras direkt i er CI/CD-pipeline.

Hur lång tid tar det att implementera DevSecOps?

Räkna med 3–6 månader för att etablera grundläggande automatiserad säkerhetsskanning i CI/CD. Det verkliga kulturskiftet — där utvecklare naturligt tänker säkerhet — tar 12–18 månader. Börja med ett pilotteam och skala sedan gradvis.

Är DevSecOps relevant för små utvecklingsteam?

Absolut. Små team har ofta färre formella granskningsprocesser, vilket gör automatiserade säkerhetskontroller ännu viktigare. Open source-verktyg som Trivy, Semgrep och OWASP ZAP ger stark grundsäkerhet utan licenskostnad.

Hur hänger DevSecOps ihop med NIS2-kraven?

NIS2-direktivet kräver att organisationer som omfattas har dokumenterade processer för riskhantering och incidentrapportering. En DevSecOps-pipeline med automatiserad säkerhetsgranskning, loggning och spårbarhet ger direkt underlag för NIS2-efterlevnad — särskilt artiklarna om riskhanteringsåtgärder.