De flesta team ser säker utveckling som en teknisk fråga. Den lever i verktygen, i pipelines och i vanorna hos dem som skriver koden. Det stämmer, men det missar något som revisorer och företagsköpare bryr sig mycket om. Säker utveckling är också ett kontrollområde för efterlevnad, och precis som varje kontroll måste den styras, dokumenteras och backas av bevis.

En säker utvecklingslivscykel, eller SSDLC, är de kontroller som ser till att säkerhet byggs in i hur du designar, granskar och släpper mjukvara, i stället för att skruvas på i efterhand. Det här inlägget tittar på SSDLC ur ett styrningsperspektiv: vad kontrollområdet omfattar, varför revisorer förväntar sig en dokumenterad process och hur OptiTech gör det till en levande del av ditt program.

Varför SSDLC är en efterlevnadsfråga

Varje större ramverk du möter förväntar sig att du utvecklar mjukvara säkert. SOC 2 Type II frågar hur du hanterar förändring och skyddar system. ISO 27001 har uttryckliga kontroller för säker utveckling, säker kodning och åtskilda miljöer. NIS2 och DORA för in driftsäkerhet och leverantörskedjans säkerhet i omfattningen för allt fler företag. GDPR förväntar sig dataskydd genom design och som standard.

Inget av de ramverken talar om vilken skanner du ska köra. De ställer i stället en styrningsfråga: kan du visa att säkerhet är en medveten och repeterbar del av hur du bygger och levererar? Det är skillnaden mellan ett team som råkar skriva noggrann kod och en organisation som kan bevisa sin process för en utomstående.

SSDLC är där du svarar på den frågan. Det är ett kontrollområde, inte en enskild kontroll, och det sträcker sig över design, utveckling, testning och release.

Säker design som utgångspunkt

Säkerhetsbeslut är billigast i designfasen och dyrast efter release. En styrd SSDLC börjar med att göra säker design till ett dokumenterat steg snarare än en eftertanke.

På policynivå betyder det några saker du kan peka på. Du bestämmer när en förändring är tillräckligt betydande för att kräva en designgranskning. Du definierar vem som godkänner den granskningen. Du fångar hotöverväganden för känsliga funktioner, så att riskerna namnges innan koden finns. Du behöver inte tung ceremoni för varje förändring, men du behöver en tydlig regel för när djupare granskning gäller och ett spår som visar att den skedde.

I OptiTech lever säker design som en kontroll med en ägare och en kadens. Policyn som styr den är versionshanterad, designgranskningarna loggas som bevis, och alltihop kopplas tillbaka till de ramverk som kräver det.

Kodgranskning och ansvarsfördelning

Kodgranskning är en av de mest effektiva säkerhetskontroller du har, och en som revisorer gillar, eftersom den upprätthåller ansvarsfördelning. Personen som skriver en ändring bör inte vara den enda som godkänner att den går vidare.

Ur ett styrningsperspektiv är kontrollen inte själva granskningsverktyget. Det är regeln att ändringar behöver oberoende granskning innan de når produktion, plus beviset att regeln håller i praktiken. Du definierar policyn, du gör kollegial granskning obligatorisk för de kodvägar som spelar roll, och du behåller ett spår som visar att granskningarna faktiskt sker.

Ansvarsfördelning går djupare än granskning. De som godkänner en ändring, de som kan driftsätta den och de som förvaltar produktionsmiljön bör inte vara samma person utan en kompenserande kontroll. Revisorer letar efter den uppdelningen eftersom den begränsar både misstag och missbruk. OptiTech spårar ansvarsfördelning som en egen kontroll, med policyn, de ansvariga ägarna och bevisen på ett ställe.

Beroende- och sårbarhetsskanning

Modern mjukvara är mestadels sammansatt av komponenter du inte har skrivit själv. Det gör dina beroenden till en del av din attackyta och en del av din efterlevnadsberättelse. NIS2 och DORA förväntar sig särskilt att du hanterar risker i leverantörskedjan, inte bara din egen kod.

På styrningsnivå är kontrollen en dokumenterad process för att hitta och åtgärda kända sårbarheter enligt ett bestämt schema. Du bestämmer hur ofta du skannar, vem som äger fynden och hur snabbt du åtar dig att åtgärda problem utifrån allvarlighetsgrad. Just den sista delen betyder mest för revisorer. En servicenivå för åtgärdande, till exempel att kritiska brister rättas inom ett bestämt antal dagar, gör en vag avsikt till en mätbar kontroll.

OptiTech dokumenterar skanningsprocessen som en kontroll, kopplar åtgärdsmålen till din policy och behåller de återkommande skanningsresultaten som bevis. När en revisor frågar hur du hanterar en kritisk sårbarhet visar du policyn, målet och spåret som visar att du nådde det.

Releasegodkännanden och ändringshantering

Ögonblicket då en ändring når produktion är ögonblicket då risken blir verklig. Releasegodkännande är kontrollen som säger att inget levereras utan rätt godkännande, och ändringshantering är spåret över vad som levererades, när och vem som godkände det.

För efterlevnad är styrningsfrågan enkel. Kan du visa att produktionsändringar följer en definierad godkännandeväg, och kan du ta fram bevis för en given release? Det beviset omfattar oftast godkännandet, granskningen och en länk tillbaka till ändringen som gjordes. Akuta ändringar behöver sin egen dokumenterade väg, för revisorer vet att incidenter inte väntar på den normala processen, och de kommer att fråga hur du hanterar undantagen.

OptiTech knyter releasegodkännanden till kontrollområdet SSDLC, så att godkännandespåren, de ansvariga ägarna och undantagsprocessen ligger bredvid de ramverk de uppfyller.

Vad revisorer faktiskt frågar efter

Över alla de här områdena frågar revisorer efter samma två saker. Visa mig policyn, och visa mig beviset att du följde den under revisionsperioden.

Policyn är den dokumenterade processen: dina regler för designgranskning, kodgranskning, skanning och release. Beviset är att processen kördes: de loggade granskningarna, skanningsresultaten, godkännandespåren, åtgärdshistoriken. En kontroll utan policy ser tillfällig ut. En policy utan bevis ser önsketänkt ut. Du behöver båda, och du behöver dem sammankopplade.

Det är precis här kalkylark och spridda dokument faller isär. Policyn lever på ett ställe, beviset på ett annat, och vid revisionen är ingen säker på att de två fortfarande stämmer överens.

Så spårar OptiTech SSDLC-kontroller

OptiTech behandlar SSDLC som ett kontrollområde i ditt bredare program. Varje kontroll, säker design, kodgranskning, ansvarsfördelning, beroendeskanning och releasegodkännande, har en ägare, en versionshanterad policy och en plats att bifoga bevis. Varje kontroll kopplas till de ramverk som kräver den, så att en enda policy för kodgranskning kan uppfylla SOC 2, ISO 27001 och mer på samma gång, utan att du spårar den fem gånger.

Eftersom allt driftas inom EU i Stockholm och Frankfurt stannar dina bevis innanför den datalagringsgräns dina kunder förväntar sig. Och eftersom samma kontroller matar ditt trust center svarar arbetet du gör för en revisor också på de säkerhetsgranskningar som avgör dina affärer.

Kom igång

Du behöver inte en perfekt SSDLC dag ett. En realistisk första omgång ser ut så här:

1. Skriv policyerna. Dokumentera dina regler för designgranskning, kodgranskning, skanning och releasegodkännande, och ge var och en ett datum.
2. Utse ägare. Varje kontroll behöver en namngiven person som är ansvarig för den.
3. Bestäm dina bevis. Välj vad som visar att varje kontroll kördes, och sätt kadensen för att samla in det.
4. Koppla till dina ramverk. Knyt varje kontroll till de ramverk den uppfyller, så att en process täcker många krav.

En säker utvecklingslivscykel belönar samma vana som resten av efterlevnaden: bygg processen en gång, håll bevisen aktuella, och ge revisorer och köpare samma tydliga svar.

Redo att göra din SSDLC till ett kontrollområde du kan bevisa? Boka en demo och se hur OptiTech kopplar ihop dina policyer, kontroller och bevis.