Sikkerhetsfunn trenger mer enn en gjeldsmerkelapp

Det merkelappen ikke forteller

I backloggen ligger de side om side: «Refaktorere ordremodulen» og «Manglende inputvalidering i kunde-API-et». Begge merket teknisk gjeld. Begge nedprioritert, sprint etter sprint, av de samme gode grunnene.

Men merkelappen sier ingenting om hvem som kan nå kunde-API-et, hva manglende validering gjør mulig, eller hvilke data som står på spill. Når begge sakene behandles som vanlig vedlikehold, kan den vurderingen utebli.

Hva gjeldsmetaforen sier – og hva den ikke sier

Metaforen «teknisk gjeld» hjelper oss å snakke om kostnaden ved å utsette arbeid. Rotete kode kan gjøre hver endring dyrere, og teamet må vurdere når opprydding lønner seg. Det er en avveining vi kan gjøre synlig, slik jeg skrev i Teknisk gjeld som et teamfenomen.

Ward Cunningham brukte metaforen i en erfaringsrapport fra 1992. Han beskrev hvordan litt gjeld kan gjøre utviklingen raskere hvis den betales tilbake raskt, og hvordan arbeidet med kode som ikke er helt riktig, koster renter. Han advarte også om at ubetalt gjeld kan stoppe en hel utviklingsorganisasjon. Metaforen lover altså ikke at utsettelse er ufarlig.

For sikkerhetshull kommer en annen usikkerhet i tillegg: noen utenfor teamet kan velge å utnytte dem.

En sårbarhet kan bli stående uten synlige hendelser, eller bli utnyttet før neste planlagte oppgradering. Konsekvensen avhenger av hva angriperen kan nå og gjøre. Fravær av en alarm forteller oss ikke at det er trygt å vente.

En svakhet kan være både teknisk gjeld og sikkerhetsrisiko. Poenget er at gjeldsmerkelappen ikke må erstatte risikovurderingen. Vi bestemmer når vi gjør arbeidet. Vi bestemmer ikke når noen forsøker å utnytte svakheten.

Språket styrer prioriteringen

Tenk på hvordan saken kan bli presentert i et prioriteringsmøte:

«Vi har teknisk gjeld i autentiseringen» sier lite om hva som står på spill. Det er lett å behandle det som vedlikehold som kan vente.

«Vi har en kjent sårbarhet i autentiseringen, og vi vet ikke om den er utnyttet» gir et annet spørsmål: hvilke systemer er berørt, hva kan en angriper gjøre, og hva må vi undersøke eller begrense nå?

Som med gjeld som må gjøres synlig for beslutningstakere, er oversettelsen en del av tech leadens jobb. Beskriv eksponering og konsekvens så konkret dere kan. Hvis fem års kundedata kan være tilgjengelige, si det, og forklar hva vurderingen bygger på. Hvis dere ikke vet om svakheten kan nås, må noen få ansvar for å avklare det.

Et eget regelsett for sikkerhetsfunn

Den praktiske konsekvensen:

Gi sikkerhetsfunn et eget regelsett. En egen liste eller en tydelig visning i samme backlog kan gjøre jobben. Funn som vurderes som kritiske hos dere, får en ansvarlig og en frist for retting eller risikoreduserende tiltak. Hvis fristen ikke kan holdes, må det eskaleres til den som har mandat til å akseptere risikoen. Et nytt feature-ønske kan ikke stille og rolig skyve saken én sprint til. Det er en ramme teamet bør kjenne på forhånd, slik jeg skrev i Standarder i praksis.

La vurderingen avgjøre hva som kan planlegges. Sikkerhetsfunn med lavere vurdert risiko kan tas sammen med vanlig vedlikehold. Skriv ned hvorfor det er forsvarlig å vente, hvem som følger opp, og når vurderingen skal gjøres på nytt. Refaktoreringer og modernisering trenger fortsatt bevisste avveininger; ikke alle saker blir hastesaker fordi de ligger ved siden av et sikkerhetsfunn.

En vurdering som tåler neste sprint

Neste gang dere prioriterer, plukk ett sikkerhetsfunn som har blitt flyttet flere ganger. Vet dere hva som er eksponert, og hvorfor det kan vente?

Det er lov å planlegge arbeidet. Begrunnelsen for å vente må være synlig.

Avslutt vurderingen med en ansvarlig, en frist og en avtale om hvordan dere skal sjekke at risikoen faktisk er redusert.