Som teknisk ledare balanserar du dagligen mellan två motpoler: behovet av att leverera nya funktioner snabbt, och kravet på stabilitet och säkerhet. Ofta vinner hastigheten. Det är naturligt – det är nya features som driver affären framåt. Men om säkerhetsarbetet ständigt prioriteras ner till "senare", bygger ni upp en säkerhetsskuld som kan bli betydligt dyrare än den tekniska skulden att betala av.

Många ledare känner igen oron. Man vet att man borde ha bättre koll, men man saknar processerna för det. Risken är att man invaggas i en falsk trygghet där man litar på att brandväggar och enstaka stickprov (som ett årligt pentest) ska fånga upp allt. Men dagens hotbild ser annorlunda ut, och den börjar ofta långt innan koden når produktionsmiljön.

Grunden vi bygger på – och riskerna med den

Ingen bygger mjukvara helt från grunden idag. En stor del av en modern applikation består av färdiga moduler, bibliotek och ramverk. Det är effektivt och helt nödvändigt för att hålla utvecklingstakten uppe.

Men detta medför också en risk som vi måste vara medvetna om. När vi importerar ett paket från npm, NuGet eller PyPI, importerar vi också koden "som den är". Det finns en utbredd missuppfattning om att "många ögon" på Open Source automatiskt garanterar säkerhet. Så är inte alltid fallet.

Vi har sett en ökning av så kallade Supply Chain Attacks, där populära paket kapas eller innehåller sårbarheter som ligger dolda länge. Om ni litar blint på att repository-ägaren ansvarar för säkerheten, lämnar ni en del av kontrollen utanför er egen organisation. Problemet är inte att vi använder tredjepartskod, utan att vi ofta saknar processer för att granska och uppdatera den.

När koden får tillgång till data – hanteringen av Secrets

Sårbar kod är dock sällan farlig i isolation. Risken eskalerar först när koden interagerar med er miljö. För att applikationen – och de moduler den innehåller – ska kunna utföra sitt jobb, måste den kunna "prata" med databaser, molntjänster och externa API:er.

För att möjliggöra denna kommunikation krävs digitala nycklar, certifikat och lösenord (secrets).

Det är i hanteringen av dessa secrets som vi ofta ser onödiga risker. I en stressad vardag är det lätt hänt att en utvecklare hårdkodar en anslutningssträng eller råkar checka in en API-nyckel i versionshanteringen. Om ni inte aktivt skannar koden efter dessa misstag, vet ni inte om att nyckeln ligger där, tillgänglig för alla med tillgång till repot.

Problemet förstärks av att många system använder statiska secrets. Nycklarna skapas dag ett och byts sedan aldrig ut. Skulle en sådan nyckel läcka ut (exempelvis via en sårbar tredjepartsmodul eller en oskyddad loggfil) har obehöriga tillgång till systemet tills någon manuellt upptäcker och byter den. Saknas rutiner för att rotera nycklar blir exponeringstiden lång och skadan svår att begränsa.

Affärsrisken med att laga i efterhand

Utöver den tekniska risken finns en tydlig ekonomisk aspekt. Att upptäcka säkerhetsbrister sent i processen, exempelvis vid ett pentest strax innan release, är kostsamt.

• Tid och pengar: Att åtgärda en designmiss när systemet redan är byggt tar resurser från nyutveckling. Det blir "brandkårsutryckningar" istället för planerat arbete.
• Säljprocessen: Allt fler kunder, särskilt inom Enterprise, ställer idag tuffa krav på säkerhet. Om ni får en "Security Questionnaire" och inte kan svara tryggt på hur ni hanterar sårbarheter eller tredjepartskod, riskerar ni att tappa affären.

Säkerhet är inte längre bara en IT-fråga, det är en förutsättning för att vara en trovärdig leverantör.

Vägen framåt: Shift Left och smartare rutiner

Lösningen handlar inte om att anställa en armé av säkerhetsexperter eller att sluta använda Open Source. Det handlar om att flytta säkerhetsarbetet tidigare i processen – Shift Left.

För dig som ledare handlar det om att ge teamet rätt förutsättningar:

1. Synliggör problemet: Inför verktyg som automatiskt skannar beroenden (Software Composition Analysis - SCA) och varnar för kända sårbarheter i tredjepartskod. Det ger er kontrollen åter.
2. Automatisera detektering: Använd verktyg i era utvecklingsflöden som varnar om någon försöker checka in secrets. Det är lättare att stoppa det vid incheckning än att städa upp det i efterhand.
3. Planera för rotation: Det kanske viktigaste steget för att minska effekten av en eventuell läcka är att inte ha eviga lösenord. Börja titta på hur ni kan rotera era secrets regelbundet. Om en nyckel bara är giltig en kort tid, minskar värdet av den drastiskt för en angripare.

Säkerhet behöver inte vara en bromskloss. Genom att integrera dessa kontroller i den dagliga utvecklingen bygger ni en kultur där det är lätt att göra rätt. Det ger inte bara säkrare system, utan också en tryggare nattsömn för dig som ansvarig.