Mye av det som påvirker sikkerheten i et produkt skjer lenge før noen oppdager en konkret sårbarhet. I denne artikkelen ser vi på hvordan sikkerhet formes av produktvalgene man tar, hvor mye vedlikehold man gjør og hvordan team jobber i det daglige gjennom vaner og samarbeid.
Dette er del to i en artikkelserie om sikkerhet for produktledere. Den første delen kan du lese her.
Vi snakker ofte om sikkerhet som om det er noe som kommer i tillegg til produktet. Noe man legger på etterpå, eller håndterer ved siden av. I praksis fungerer det sjelden sånn. Sikkerhet er ikke bare et sett med krav eller kontroller. Det er også et resultat av hvordan produktet er bygget, hvor ryddig det er, hvor godt det tåler feil, og hvor lett det er å forstå, drifte og videreutvikle. Derfor henger sikkerhet tett sammen med generell produktkvalitet.
«Man må sette sikkerhet i sammenheng med generell kvalitet på arbeid»– Hans Kristian Henriksen, sikkerhetsutvikler og oppdragsleder i Bekk
Det er også en av grunnene til at sikkerhet ikke skal behandles som et spesialtema for enkelte fagpersoner. Mange av valgene som påvirker sikkerheten i et produkt tas lenge før noen snakker om en konkret sårbarhet. De tas når man velger arkitektur, prioriterer nye features, lar gammel funksjonalitet bli værende eller utsetter opprydding og vedlikehold. Over tid er det nettopp slike valg som former hvor oversiktlig, robust og endringsdyktig produktet blir, og dermed også hvor lett det er å holde sikkert.
Mer produkt = mer risiko
Hvert produktvalg har en kostnad. En ny feature skal ikke bare bygges. Den skal også forstås, testes, driftes, overvåkes og vedlikeholdes over tid. Den blir en del av produktets kompleksitet, og kompleksitet er sjelden nøytral. Når kompleksiteten øker, blir angrepsflaten større og det blir lettere å gjøre feil. Noen ganger er det riktige å la være å lage noe, eller å fjerne noe som ikke lenger gir nok verdi. “Kill your darlings” handler ikke bare om fokus og enkelhet, men også om mer robuste og sikrere produkter.
Når produkter får vokse uten nok opprydding underveis, blir det gradvis vanskeligere å gjøre gode endringer. Særtilfeller hoper seg opp, gamle avhengigheter blir liggende og integrasjoner blir stående uten tydelig eierskap. Løsningen fungerer kanskje fortsatt, men dersom den er rotete blir det både mer krevende å forstå og lettere å gjøre feil. Da kan selv enkle tiltak bli kostbare, fordi konsekvensene av en endring er vanskelige å forutse. Motsatt er løsninger som er enkle å forstå, godt monitorert, oppdatert og bygget for å tåle feil, ofte også lettere å sikre. Sikkerhet og kvalitet er ikke det samme, men mye av det som gjør et produkt stabilt og robust styrker også sikkerheten.
Sikkerhet skapes i hverdagen
Sikkerhet blir ofte svakere når den først og fremst oppleves som noe som kommer utenfra: regler, prosesser og kontrollpunkter som er laget et annet sted og tredd ned over teamene. Det betyr ikke at rammer og krav er feil, men at de sjelden er nok i seg selv.
Hvis utviklingsprosessen oppleves som unødvendig tung, finner folk som regel måter å omgå den på. Ikke nødvendigvis fordi de ikke bryr seg om sikkerhet, men fordi de prøver å få jobben gjort. En prosess som gjør vondt lenge nok, blir ofte møtt med omveier. Derfor er det heller ikke tilstrekkelig å produsere stadig mer prosess ovenfra og håpe at teamene skal eie den. Sikkerhetsarbeid fungerer bedre når det samskapes med dem som faktisk bygger og forvalter produktet.
De gode spørsmålene
«Sikkerhetskultur er det som gjør at team stiller de riktige spørsmålene før noen ber dem om det»– Henrik Sivertsgård, konsulent i Bekk og produktleder hos Gjensidige Pensjon
God sikkerhetskultur kjennetegnes ikke først og fremst av flere sjekklister, men av at team stiller gode spørsmål før de bygger, mens de bygger og når de gjør endringer. De tenker naturlig på dataminimering, tilgangsstyring og sporbarhet, og vurderer hvem som bør ha tilgang, hva som bør lagres og hva som bør logges. Poenget er ikke at alt må stå i en sjekkliste, men at teamet er vant til å stille gode spørsmål, utfordre egne valg og stoppe opp når noe ikke kjennes trygt nok.
God sikkerhetskultur vises også i at team følger med på sårbarheter, endringer i egne avhengigheter og sikkerhetsnyheter som kan påvirke produktet deres. De vurderer hva som er relevant for egen løsning og tar tak i det som må håndteres. Dette er ikke en sideaktivitet, men en del av det løpende vedlikeholdsarbeidet.
Her ligger det også ofte en form for faglig stolthet. Ikke fordi man tror man kan bygge perfekte systemer, men fordi man ønsker å ha orden i eget hus. De fleste team kommer før eller siden til å gjøre feil. Det avgjørende er derfor ikke å late som noe annet, men å bygge produkter og arbeidsformer som gjør feil lettere å oppdage og konsekvensene mindre når noe først skjer.
Sikkerhet på tvers
Det er også en felle å tenke at alt må løses innenfor sitt eget team. Det gjelder sjelden i produktutvikling generelt, og enda mindre når det kommer til sikkerhet. Sikkerhetsvurderinger blir ofte bedre når man bruker fagmiljøer på tvers av team. Et annet team kan ha løst noe lignende før, og en sikkerhetsressurs kan se risikoer man selv er blitt blind for. Samtidig betyr ikke dette at ansvar skal pulveriseres. Poenget er heller at gode team vet når de bør hente inn flere perspektiver.
Sikkerhetskultur vises i praksis gjennom hva team velger å ta tak i, og hva de lar skli. Den vises i om det er rom for å si at noe er for skjørt. Om folk ber om hjelp tidlig nok. Om opprydding og vedlikehold faktisk får plass i planene. Og om kvalitet behandles som en del av leveransen, ikke som noe man håper å få tid til senere. Sikkerhet er derfor ikke bare noe et produkt må ha. Det er også noe som vokser fram gjennom hvordan produktet bygges, hvordan teamene samarbeider og hvilke vaner man bygger over tid.
