All offentlig kode bør være åpen

Målet er at all offentlig kode skal være åpent tilgjengelig (coding in the open). Kildekoden publiseres og forvaltes som åpen kildekode, og bruker den tilhørende infrastrukturen og mekanismene. Imidlertid er etablering av et langsiktig bærekraftig nettsamfunn (community) ikke nødvendig i denne sammenhengen. Ansvaret for videreutvikling og forvalting vil uansett ligge hos den offentlige virksomheten. Hvis man i tillegg klarer å etablere et åpent kildekode-nettsamfunn, er det å betrakte som en bonus.

I Storbritannia snakket GOV.UK allerede i 2012 om «Coding in the open», og understreket forskjellen mellom åpen kildekode og åpent tilgjengelig kode.

Code for America startet allerede i 2009 og forvalter flere hundre åpne produkter på GitHub. EU-kommisjonen lanserte nylig sin plan for å forvalte sine produkter som åpen kildekode. Beslutningen lener seg på en undersøkelse som peker på teknologiuavhengighet, konkurransekraft og innovasjon.

Her hjemme har Digdir ingen tydelige føringer på dette området (men flott at Altinn3 er åpen kildekode). Arkitekturprinsipp 5 - Del og gjenbruk løsninger bør komme med en tydelig anbefaling. Arkitekturprinsipp 6: Lag digitale løsninger som støtter samhandling, nevner bruk av åpen kildekode: «6.9Vurder bruk av åpen kildekode fremfor lukkede, kommersielle løsninger». Også i Digitaliseringsrundskrivet –regjeringens sammenstilling av pålegg og anbefalinger om digitalisering i offentlig sektor – glimrer åpen kildekode med sitt fravær.

NAV sørger nesten på egen hånd for at det ikke er helsvart på hjemmebane. Inspirert av GOV.UK har NAV tydelige retningslinjer for å forvalte kode åpent tilgjengelig. Det vises også godt på GitHub, der NAV IKT har over 1000 prosjekter. Skatteetaten ligger litt etter i løypa, men er på gang og lanserte nylig en rekke produkter som åpen kildekode.

Utviklingen av produkter og tjenester i offentlige virksomheter er finansiert med fellesskapets midler. Det er med andre ord bygget med innbyggernes midler, og bør være åpent tilgjengelig for oss.

Store deler av offentlig forvaltning møter ikke konkurranse. Eksempelvis er det ingen konkurrenter innenfor innkreving av skatt, tildeling av studielån eller foreldrepenger. Det er med andre ord ingen forretningshemmeligheter, og kildekoden bør derfor være åpen.

Systemene som lages av offentlige virksomheter speiler lover og regler som virksomhetene forvalter. Selv om abstraksjonsnivået og omfanget er ulik, er kode og regelverk prinsipielt to sider av samme sak. Begge deler bør være åpne.

Både regjeringen og Digdir har initiativer for «Klart og digitaliseringsvennlig lovverk». Noen drømmer attpåtil om å skrive lovene våre som kode.

Offentleglova heter egentlig «Lov om rett til innsyn i dokument i offentleg verksemd». Den er grunnlaget for at alle skal kunne ettergå beslutninger og vedtak i offentlig forvaltning, og brukes mye av journalister. Intensjonen til offentleglova samsvarer veldig godt med åpen offentlig kildekode:

Personopplysningsloven understreker flere steder at behandlingen av personopplysninger må fremstå som åpen og forståelig. Ved å åpne kildekoden ville alle kunne se hvordan data blir behandlet, hvilke grep som er gjort for å sikre systemet og data, og hvordan eksempelvis innebygd personvern er gjennomført i praksis.

Åpen kildekode vil fremme kvaliteten. Når man vet at det man lager er synlig og tilgjengelig for alle, vil man i større grad bry seg om kvaliteter som lesbarhet, forvaltbarhet, sikkerhet og testbarhet.

Anna Shipman i GOV.UK skriver også om denne effekten:

Linus’ lov sier at «given enough eyeballs, all bugs are shallow»: Jo flere som jobber med en kodebase, jo flere feil vil de finne. Påstanden er omstridt, og eksempler som Heartbleed og Log4Shell viser med all tydelighet at det ikke finnes noen garantier. Imidlertid er det indikasjoner på at populære åpen kildekodekomponenter mottar flere feilrettinger enn mindre populære. I alle tilfeller gjør åpent tilgjengelig kode det mulig for alle som er interessert å gjøre kodegjennomganger.

Gjenbruk er ledergruppas våte drøm og teknologenes mareritt. Rett nok brukes og gjenbrukes en rekke plattform- og infrastrukturkomponenter. Når koden blir spesifikk for forretningsdomenet, blir gjenbruk vanskeligere. Det er lettere å bruke NAV sin nais-plattform enn å gjenbruke beregning av sykepenger. Gjenbruk kan betraktes som en bonus, spesielt for domenespesifikk kode.

Dette er også grunnen til å vektlegge åpent tilgjengelig kode framfor åpen kildekode med et levende nettsamfunn. Men gjenbruk kan allikevel forekomme. Det er ikke lenge siden jeg plukket opp at en kollega hadde tatt i bruk en funksjon som Kartverket publiserer åpent. En sekundæreffekt er at andre virksomheter kan la seg inspirere av og bruke løsningsmønstre som er åpent tilgjengelig.

Mange tjenester tilbyr gratis eller redusert pris for åpen kildekode. Noen eksempler er GitHub, Snyk og DataDog. Her er en lengre liste.

Åpent tilgjengelig kode kan bidra til å øke konkurransen. Konsulenttilbydere får mulighet til å sette seg inn i eksisterende kodebaser, og dermed få et vesentlig bedre grunnlag for å levere tilbud og folk. Tilgang til kodebasen kan også bidra til å påvirke hvor attraktiv en arbeidsgiver er, både for innleide og ansatte.

Åpent tilgjengelig kode eksponerer en ny angrepsflate og gjør det lettere å finne sårbarheter. Angripere får kortere vei til svakheter i kode og tredjepartsbiblioteker. Sikkerheten må derfor røktes fra vugge til grav for alle systemer virksomheten har ansvar for.

Dette ikke er unikt for åpen kildekode. Nærmest daglig rapporteres det i nyhetene om innbrudd, lekkasjer og utpressingsangrep, uavhengig av hvordan koden forvaltes. Sikkerhet er obligatorisk i hele livssyklusen for alle systemer i den digitale tidsalderen. Security by obscurity vil aldri være tilstrekkelig.

Her er de viktigste anbefalingene:

• Etabler en sikkerhetskultur. Når alle team-medlemmer tar eierskap til og er observante på sikkerhetsutfordringer i det daglige arbeidet man gjør, da har man en fungerende sikkerhetskultur.
• Hemmeligheter må ligge utenfor kodebasen. Passord, nøkler og sertifikater skal aldri forvaltes sammen med koden.
• Slett eventuelle personopplysninger, eksempelvis test-data. Det er sannsynligvis ikke lov å forvalte personopplysninger i kodebasen uansett, men de må i alle fall ikke gjøres åpent tilgjengelig.
• Gå gjennom og/eller slett historikk når lukkede kodebaser åpnes.
• Bruk av tredjepartskomponenter er en kost/nytte-øvelse. Gjør en reell vurdering av community, modenhet, aktivitet og kvalitet. Foretrekk komponenter som har få avhengigheter; man har ansvaret for dem også. Hold avhengighetene oppdatert til enhver tid.
• Sørg for innebygd avhengighetssjekk i verdikjeden din med hensyn til utdaterte versjoner og eventuelle sårbarheter, som for eksempel verktøyene Dependabot og Snyk.

Ja. Med få unntak:

• Algoritmer som brukes til å detektere svindel og misbruk.
• Kode som implementerer upubliserte endringer i lover og forskrifter. Denne kan åpnes så snart de er behandlet og vedtatt.
• Hemmeligheter – nøkler, passord og sertifikater – må som nevnt ikke ligge åpent tilgjengelig.

Dette er en marginal del av totalen, og bør være lett å holde orden på.

Det er mange fordeler med å forvalte koden åpent. Det finnes flere grunner i tillegg til de 10 i denne artikkelen. EU legger vekt på teknologiuavhengighet, konkurransekraft og innovasjon. GOV.UK peker på bedre samarbeid, læring og deling. Fordelene er mange, og sikkerheten må uansett røktes.

Kjære Digdir, Regjering, Storting og offentlige virksomheter i Norge! Til jul ønsker jeg at vi gjør som GOV.UK og forvalter all offentlig kode åpent tilgjengelig!

P.S. Forfatteren snakket også om dette temaet på JavaZone 2021. Videoen blir tilgjengelig i januar.

Photo by Riku Lu on Unsplash