- Sikkerhetsgjeld er et sett av design eller implementasjoner som hindrer eller har potensialet til å hindre at et system oppnår sikkerhetsmålet, oppsummerer Maren Maritsdatter Kruke, "Security business analyst" i Visma, til kode24 i Lillehammer.
I vår ble hun ferdig med en master i programmering og systemarkitektur ved Universitetet i Oslo. Hun presenterte masteravhandlingen sin "Security Debt in Practice" på Sikkerhetsfestivalen tirsdag.
Kruke mener det er viktig at utviklere lærer seg å skille mellom teknisk- og sikkerhetsgjeld.
Utviklere slutter på grunn av teknisk gjeld
Handler om "suboptimalitet"
I masteroppgaven har Kruke forsøkt å finne en definisjon på sikkerhetsgjeld.
- For i det hele tatt å jobbe med sikkerhetsgjeld må du ha en forståelse av hva det er, hvordan det fungerer og hvilken påvirkning sikkerhetsgjeld har på systemene, sier hun.
Ifølge Kruke er en av likhetene mellom teknisk- og sikkerhetsgjeld at begge snakker om sub-optimale løsninger på hver sin måte, hvor begge negativt påvirker systemene. For teknisk gjeld handler det om design- og "implementasjonskonstrukter".
- Du setter opp en teknisk kontekst som kan gjøre fremtidige endringer dyre eller umulige å få til, som følge av løsninger som er hensiktsmessige på kort sikt. Det samme kan sies om sikkerhetsgjeld: Sub-optimale løsninger som gjør det vanskeligere å nå sikkerhetsmålet for systemet ditt, sier hun.
«Selv om du bruker mye tid på sikkerhetsgjeld må du passe på at du også bruker tiden på teknisk gjeld.»
Prioriterer sikkerhetsgjeld
Kruke forteller at teknisk gjeld i mange tilfeller er noe du skaper med viten og vilje. For eksempel kan ønsket om kort “time-to-market” være en grunn til en økning av teknisk gjeld i systemet.
- Det samme kan du også gjøre med sikkerhetsgjeld: Nemlig at du velger løsninger som kanskje ikke er optimale rent sikkerhetsmessig, som følge av "trade-offs". Systemet oppnår da ikke sikkerhetsmålet sitt, og du blir mer sårbar for angrep, sier hun.
Som en del av masteroppgaven gjorde hun 26 intervjuer med folk i IT-bransjen.
- Det som jeg satt igjen med etter å ha gjort intervjuene, er at sikkerhet og sikkerhetsgjeld er noe de tar seriøst og prioriterer når de jobber. Derimot blir ikke teknisk gjeld i de aller fleste tilfeller prioritert i samme grad, sier Kruke.
- Vi må holde sammen om vedlikehold
God kommunikasjon er viktig
Kruke mener det er viktig at utviklerteamene er bevisst på forskjellene mellom teknisk- og sikkerhetsgjeld. Ellers kan de havne i den situasjonen at de bruker mesteparten av tiden på sikkerhetsgjeld, og glemmer alle de andre formene for teknisk gjeld.
- Selv om du bruker mye tid på sikkerhetsgjeld må du passe på at du også bruker tiden på teknisk gjeld. Ellers kan det skapes en ubalanse i arbeidet, sier hun.
Her mener Kruke at det er tre ting som er viktig: God kommunikasjon, bruk av merkelapper, og å legge til en sikkerhetsskår eller prioritering.
- God kommunikasjon gir bedre oversikt, og gjør at du også kan forstå andres perspektiver, sier Kruke.
Håvard har tre enkle regler for en vedlikeholdbar kode: - Dette er viktig!
Bedre arbeidsbalanse
Kruke legger til at merkelapper som NFR og sikkerhet, gjør det enklere å filtrere elementene som er i backloggen, og du kan blant annet enkelt se forskjellen på sikkerhet og teknisk gjeld.
Hun forteller videre at en alvorlighetsskår eller prioritet sier noe om hvor alvorlig sikkerhetsgjelden og de andre elemente i backloggen er.
- Bruker du dette i arbeidet, blir det enklere å skille ut sikkerhetsgjelden fra den tekniske gjelden, og det kan bli lettere å balansere arbeidet, sier hun.