Den traditionelle model og dens omkostninger
I den klassiske softwareudviklingsmodel var sikkerhed domænet for et specialiseret team, der testede systemet lige før produktionsudrulning. Fundne sårbarheder genererede dyre omveje — udviklere måtte vende tilbage til for længst afsluttede opgaver, forstå konteksten fra uger tilbage og indføre ændringer, der forstyrrede andre allerede testede elementer. Frustrationen var gensidig: sikkerhedsteamet blev opfattet som blokade, udviklerne som uforberedte på at skrive sikker kode.
Shift-left-filosofien
Shift-left betyder bogstaveligt at flytte sikkerhedsaktiviteter til venstre på projektets tidslinje — fra test- og udrulningsfasen til design- og kodningsfasen. Jo tidligere en sårbarhed opdages, desto billigere og enklere er det at rette den. En udvikler, der ser en sårbarhedsadvarsel i sit udviklingsmiljø sekunder efter at have skrevet problematisk kode, retter den øjeblikkeligt uden konteksttab og uden at forstyrre hele teamets arbejdsflow.
Automatisering i CI/CD-pipelinen
Shift-left realiseres ved at bygge automatiske sikkerhedskontroller ind i hvert trin af den kontinuerlige integrations- og leveringspipeline. Hver kode-commit starter en sekvens af sikkerhedsverifikationer, der blokerer overgangen til næste trin ved opdagelse af alvorlige sårbarheder.
- SAST (statisk kodeanalyse) — detekterer sårbarheder i kildekoden uden at køre den: SQL-injektioner, usikre deserialiseringer, brug af farlige funktioner
- SCA (softwaresammensætningsanalyse) — scanner afhængigheder for kendte sårbarheder, tjekker licenser, detekterer forældede biblioteker
- Hemmelighedsscanning — blokerer utilsigtet commit af adgangskoder, API-nøgler og certifikater til repositoriet
- DAST (dynamisk analyse) — tester den kørende applikation i et testmiljø ved at simulere angreb på API'er og webgrænseflader
- Container- og infrastrukturtest — verifikation af Docker-image-konfiguration og infrastrukturdefinitioner for sikkerhedsfejl
Sikkerhed som kode
Modne organisationer behandler sikkerhedspolitikker som kode — de definerer dem i konfigurationsfiler gemt i repositoriet, underlagt review og test. Det betyder, at WAF-regler, netværkspolitikker, konfigurationer af anomalidetektionssystemer og RBAC-politikker styres med samme stringens som applikationskode. Ændringer kræver review, historikken er reviderbar, rollback er mulig inden for minutter.
Kultur som fundament
Værktøjer uden kultur giver ikke resultater. DevSecOps kræver, at udviklere forstår sikkerhedskonsekvenserne af designbeslutninger og ser advarsler ikke som forhindringer, men som værdifuld feedback. Det kræver investering i uddannelse, tilgængelighed af sikkerhedseksperter som designpartnere (ikke revisorer), klare målepunkter og delt ansvar for sårbarheder. ESKOM.AI anvender DevSecOps-modellen i udviklingen af egne systemer, hvor testautomatisering kombineres med en kultur af delt ansvar for sikkerhed i hver fase af udviklingscyklussen.