Det er ikke til å stikke under stol at smidig utvikling og sikkerhet ofte føles som to motsetninger. Der smidig utvikling assosieres med hastighet og fleksibilitet, tenker mange på sikkerhet som noe som er tidkrevende og rigid. Dette kan føre til en følelse av at sikkerhetsaktiviteter ikke passer inn i den smidige tankegangen.

De siste årene har konseptet med “shift left” innenfor sikkerhet blitt høyaktuelt, noe som rett og slett betyr å inkludere sikkerhetsaktiviteter tidligere i utviklingen. Det finnes mange metodikker for å oppnå dette, men en vanlig måte å presentere det på er lange sjekklister over hva som burde tenkes på i hver fase. Dette passer dårlig med den smidige tankegangen og når 80 % av spørsmålene i sjekklisten er irrelevante for oppgaven du skal løse, blir de fort lagt bort og sett på som unyttige.

Allikevel må vi anerkjenne at det er en mye større kostnad knyttet til å fikse sikkerhetsfeil i produksjon, enn å oppdage feilene allerede i utviklingsfasen og dermed unngå å introdusere dem i det hele tatt. Så hvordan går vi frem for å sørge for å inkludere sikkerhet i den smidige utviklingsprosessen? Her er mine tre tips til deg.

Se på sikkerhet som et brukerbehov

Smidig fokuserer på å raskt levere funksjonalitet som dekker kundenes behov. Første steg mot å skape smidig sikkerhet er å anerkjenne at sikkerhet også er et behov. Brukerne våre forventer at tjenestene vi lagrer er sikre. De har behov for at deres personopplysninger er trygge og at det er enkelt for dem å gjøre de sikre valgene i applikasjonen. Vi bør derfor inkludere sikkerhet i brukerhistoriene.

Dette fører til at sikkerhet blir en del av akseptansekriteriene for brukerhistorien, og dermed vil vi også inkludere sikkerhet i verdien som leveres til brukerne.

Få sikkerhet inn i backlogen

Backlogen er et fast innslag i ethvert smidig utviklingsteam, og på samme måte som andre oppgaver så må også sikkerhet prioriteres. Og i forlengelse av det, så vil jeg hevde at sikkerhetsoppgaver ikke burde kunne nedprioriteres. “Vi kan ikke sette av tid til sikkerhet nå”, er en setning som rett og slett ikke høres så bra ut når det blir sagt høyt.

En måte å få sikkerhet inn i backlogen på er å gjøre det til en vane å identifisere risiko og trusler forbundet med alle oppgaver. Risikovurdering og trusselmodellering blir ofte sett på som en tungrodd prosess som resulterer i 2-siders dokumenter, men i denne sammenhengen holder det å svare på noen enkle spørsmål.

I førsteomgang er det viktig å svare overordnet på "introduserer denne oppgaven noen risikoer?". Hvis svaret på det er ja, så kan vi gå ett steg videre med 3 ekstra spørsmål for å finne disse tiltakene:

1. Hva er det vi lager?
2. Hvordan kan det utnyttes eller misbrukes?
3. Hvordan kan vi unngå det?

På denne måten får vi inkludert sikkerhet i prioriteringsarbeidet, og vi får også økt sikkerhetsbevisstheten i hele teamet.

Vær litt lettbent

Mye av poenget med smidig utvikling er fleksibilitet. Derfor må hver oppgave vurderes basert på hvilket sikkerhetsnivå det er nødvendig å legge seg på. Hva som er "god nok" sikkerhet vil variere fra oppgave til oppgave, og noen ganger er det lov å konkludere med at en oppgave ikke har behov for noe særlig sikkerhetsfokus. For eksempel, hvis et utviklingsteam skal oppdatere designet på en komponent så er ikke sikkerhet nødvendigvis så relevant. Hvis de derimot skal implementere en autentiseringsmekanisme så er det svært viktig å identifisere gjeldende sikkerhetskrav. Poenget er at vi må ha en lettbent innstilling til sikkerhet og kunne vurdere hvor det er behov for krav til sikkerhet og hvor det ikke er det.

Oppsummert, så mener jeg at for å kunne jobbe smidig med sikkerhet må vi anerkjenne sikkerhet som et brukerbehov og sørge for at sikkerheten bakes inn i de daglige oppgavene. Da kan vi bevege oss vekk fra at sikkerhet føles som en veisperre og bevege oss mot at sikkerhet er en naturlig del av det å sørge for ny verdi til kundene våre. På den måten kommer vi oss også ett steg nærmere målet om å forhindre feil fremfor å finne feil.