Den traditionella modellen och dess kostnader
I den klassiska mjukvaruutvecklingsmodellen var säkerhet domänen för ett specialiserat team som testade systemet strax före produktionsdriftsättning. Upptäckta brister genererade kostsamma omvägar — utvecklare var tvungna att återgå till sedan länge avslutade uppgifter, förstå sammanhanget från veckor tillbaka och införa ändringar som störde andra redan testade element. Frustrationen var ömsesidig: säkerhetsteamet uppfattades som blockerare, utvecklarna som oförberedda att skriva säker kod.
Shift-left-filosofin
Shift-left innebär bokstavligen att flytta säkerhetsaktiviteter åt vänster på projektets tidslinje — från test- och driftsättningsfasen till design- och kodningsfasen. Ju tidigare en brist upptäcks, desto billigare och enklare är det att åtgärda den. En utvecklare som ser en bristsvarning i sin utvecklingsmiljö sekunder efter att ha skrivit problematisk kod åtgärdar den omedelbart, utan kontextförlust och utan att störa hela teamets arbetsflöde.
Automatisering i CI/CD-pipelinen
Shift-left förverkligas genom att bygga in automatiska säkerhetskontroller i varje steg av den kontinuerliga integrations- och leveranspipelinen. Varje kodcommit startar en sekvens av säkerhetsverifieringar som blockerar övergången till nästa steg vid upptäckt av allvarliga brister.
- SAST (statisk kodanalys) — detekterar brister i källkoden utan att köra den: SQL-injektioner, osäkra deserialiseringar, användning av farliga funktioner
- SCA (analys av programvarukomposition) — skannar beroenden efter kända brister, kontrollerar licenser, detekterar föråldrade bibliotek
- Hemlighetsskanning — blockerar oavsiktlig commit av lösenord, API-nycklar och certifikat till arkivet
- DAST (dynamisk analys) — testar den körande applikationen i en testmiljö genom att simulera attacker mot API:er och webbgränssnitt
- Container- och infrastrukturtester — verifiering av Docker-imagekonfiguration och infrastrukturdefinitioner avseende säkerhetsfel
Säkerhet som kod
Mogna organisationer behandlar säkerhetspolicyer som kod — de definierar dem i konfigurationsfiler lagrade i arkivet, underkastade granskning och testning. Det innebär att WAF-regler, nätverkspolicyer, konfigurationer av anomalidetekteringssystem och RBAC-policyer hanteras med samma stringens som applikationskod. Ändringar kräver granskning, historiken är reviderbar, rollback är möjlig inom minuter.
Kultur som grund
Verktyg utan kultur ger inga resultat. DevSecOps kräver att utvecklare förstår säkerhetskonsekvenserna av designbeslut och ser varningar inte som hinder utan som värdefull feedback. Det innebär investering i utbildning, tillgänglighet av säkerhetsexperter som designpartners (inte revisorer), tydliga mätvärden och delat ansvar för brister. ESKOM.AI tillämpar DevSecOps-modellen vid utveckling av egna system, där testautomatisering kombineras med en kultur av delat ansvar för säkerhet i varje fas av utvecklingscykeln.