[KUNSKAPSAMARBETE] Ett fåtal produkter kan en central säkerhetsfunktion ofta hantera nära.
Men när organisationen växer från fem produkter till 50 eller 100 förändras spelplanen. Lösningen är inte att låta säkerheten växa i samma takt som produktportföljen utan att bygga säkerhetsförmåga ute i produktteamen.
Att införa en säker utvecklingsprocess, Secure Software Development Life Cycle (SSDLC), är förhållandevis enkelt när en organisation bara har några få produkter. Säkerhetsteamet kan arbeta nära utvecklarna, delta i hotmodellering, granska säkerhetsproblem och följa upp att sårbarheter åtgärdas.
Men vad händer när fem produkter blir 20, 50 eller kanske 100?
Då räcker det inte längre att låta ett centralt säkerhetsteam vara involverat i allt. Säkerhetsfunktionen kan inte växa i samma takt som produktorganisationen utan att kostnader och komplexitet snabbt drar iväg.
Samtidigt fungerar det sällan att bara lämna över ansvaret till produktteamen. Deras erfarenhet och säkerhetsmognad kan skilja sig kraftigt åt.
Utmaningen blir därför att hitta en modell där produktteamen tar ett större ansvar, samtidigt som den centrala säkerhetsfunktionen behåller den expertis, de gemensamma standarderna och den överblick som krävs.
Verktyg löser inte hela problemet
När organisationer börjar bygga ett SSDLC ligger fokus ofta på verktygen. SAST, DAST och SCA kopplas in i utvecklingsprocessen och säkerhetskontroller läggs till i CI/CD-pipelines.
Det är viktiga komponenter, men de skapar inte i sig en fungerande säkerhetsprocess.
Någon måste fortfarande tolka resultaten, avgöra vilka fynd som är mest kritiska, fördela ansvaret, följa upp åtgärder och kontrollera att problemen verkligen är lösta.
När antalet produkter ökar kan mängden information dessutom bli ett problem i sig. Tusentals säkerhetsfynd är svåra att analysera och rapportera manuellt. Här kan automatisering spela en viktig roll.
Ett exempel är användningen av lokala AI-agenter kopplade via MCP för att analysera fynd och sammanställa resultat. På så sätt kan stora mängder information bearbetas på några timmar i stället för under en vecka, vilket gör det möjligt att gå från veckovisa till dagliga genomgångar.
När säkerhetsdata är känslig finns samtidigt ett behov av att kontrollera var bearbetningen sker. Därför kan lokal behandling vara ett alternativ till att skicka informationen till externa molnbaserade AI-tjänster.
Men även avancerad automatisering löser bara en del av problemet.
Säkerhetskompetensen måste ut i organisationen
Produktteam behöver kunna hantera en större del av säkerhetsarbetet själva. Det kan handla om allt från grundläggande säkerhetskrav till mer avancerade aktiviteter som hotmodellering och detaljerade dataflödesdiagram.
Det betyder inte att det centrala säkerhetsteamet ska försvinna. Rollen behöver snarare förändras.
I stället för att själv utföra en stor del av säkerhetsarbetet behöver den centrala funktionen bygga upp förmågan hos resten av organisationen genom gemensamma arbetssätt, utbildning, stöd och uppföljning.
Ett praktiskt sätt att göra detta är att arbeta i omgångar.
Organisationen kan exempelvis börja med fem till tio prioriterade projekt. Säkerhetsteamet kartlägger då teamens mognad och identifierar skillnaden mellan befintliga arbetssätt och önskad nivå. Därefter införs de processer, säkerhetskrav och dokumentationsunderlag som saknas.
Under de första iterationerna finns säkerhetsteamet nära verksamheten och ger praktiskt stöd. När teamen blir mer självgående minskar det direkta stödet och säkerhetsfunktionen går vidare till nästa grupp av produkter.
På så sätt behöver varje ny produkt inte innebära en motsvarande ökning av säkerhetsorganisationen.
Säkerhetsambassadörer blir länken mellan teamen
En viktig del i den modellen är så kallade security champions personer som arbetar i produktteamen men som samtidigt tar ett särskilt ansvar för säkerhetsfrågorna.
De är inte en del av den centrala säkerhetsfunktionen. Deras styrka är i stället att de redan känner produkten, tekniken och teamets arbetssätt.
Championens roll kan vara att hjälpa kollegorna att följa säkerhetskraven, introducera nya arbetssätt och fungera som kontaktpunkt mot den centrala säkerhetsfunktionen när mer specialiserad kompetens behövs.
Med tiden kan rollen utvecklas. I början handlar det kanske främst om att få grundläggande säkerhetsrutiner på plats. Senare kan championen även bidra till rapportering, uppföljning och mer avancerade säkerhetsmått.
När flera team har champions skapas dessutom ett nätverk där erfarenheter och lösningar kan delas mellan produkterna.
Vem äger egentligen risken?
När säkerhetsansvaret decentraliseras uppstår en annan fråga: vem äger risken?
I en organisation där flera team och produkter delar komponenter eller funktioner är det inte alltid självklart vilket team som ska ansvara för ett säkerhetsproblem.
Att skriva in ett namn i ett riskregister räcker inte. Den som utses till riskägare måste också ha möjlighet att driva åtgärdsplanen, samordna berörda team och eskalera frågan när det behövs.
Det är särskilt viktigt för risker som går över produkt- och teamgränser.
En enkel princip är därför att ansvar bör följa handlingsförmåga. Den som äger risken behöver också ha tillräcklig auktoritet för att påverka situationen.
Det kräver i sin tur gemensamma arbetssätt för hur risker registreras, rapporteras, följs upp och eskaleras. Annars finns risken att varje produktteam utvecklar sitt eget system och att helhetsbilden går förlorad.
Fler säkerhetsfynd betyder inte automatiskt sämre säkerhet
När organisationer ska mäta effekten av sitt säkerhetsarbete hamnar antalet identifierade sårbarheter ofta högt på listan.
Det är ett enkelt mått men ett vanskligt sådant.
Om antalet fynd ökar kan det exempelvis bero på att testningen har blivit bättre eller att fler delar av produkterna nu omfattas av säkerhetskontroller. På samma sätt innebär färre fynd inte automatiskt att säkerheten har förbättrats.
Därför behövs en bredare uppsättning indikatorer.
Det kan handla om hur stor del av produktportföljen som omfattas av definierade säkerhetsprocesser och säkerhetsartefakter, hur självständigt teamen kan genomföra säkerhetsaktiviteter, hur lång tid det tar att åtgärda problem och i vilken utsträckning identifierade risker faktiskt minskar.
Även oberoende verifiering kan ge en annan bild än den interna uppföljningen. Ett internt penetrationstestteam kan exempelvis undersöka om etablerade säkerhetsprocesser faktiskt följs och om de ger det resultat som organisationen förväntar sig.
Från central kontroll till distribuerad förmåga
När antalet produkter växer blir den övergripande bilden allt viktigare.
Säkerhetsledningen behöver kunna se var de största luckorna finns, hur teamens säkerhetsmognad utvecklas och om rätt information når rätt beslutsfattare i tid.
Det innebär att central säkerhet fortfarande har en viktig roll men inte nödvändigtvis som den funktion som gör allt säkerhetsarbete.
Den långsiktigt skalbara modellen är snarare en där säkerhet blir en integrerad del av produktutvecklingen. Produktteamen bygger upp förmågan att hantera en större del av arbetet själva, medan den centrala säkerhetsfunktionen står för expertis, gemensamma standarder, stöd, uppföljning och organisationens övergripande riskbild.
När säkerhet på det sättet går från att vara en tjänst som levereras till produktteamen till att bli en del av hur de arbetar, blir det möjligt att skala säkerhetsarbetet utan att bygga en central organisation som måste växa i samma takt som produktportföljen.
Artikeln är ett kunskapsamarbete mellan Sigma Software Group och IT Media Group. Sponsrade inlägg och kunskapsamarbeten är en del av IT Media Groups annonserbjudande. Om du har frågor kring sponsrade inlägg, hör av dig till info@itmediagroup.se
