Tilbake til innsikt
5. oktober 2026 · Analyse
Av Kenneth Bæver Bjerke, Diggs.no

Én leverandør, fire avhengigheter

Jeg kartla avhengighetene i to av mine egne systemer. I det ene fant jeg 24 der jeg ville gjettet på ti. I det andre viste én leverandør seg å være fire avhengigheter.

Doktrinen krever at en avhengighet er dokumentert før den kan aksepteres. Det er det første av fem vilkår i pragmatisk patriotisme. I oktober 2026 prøvde jeg å oppfylle det vilkåret for to systemer jeg selv har bygget. Denne teksten handler om hva jeg fant, og om hva jeg ikke kunne finne.

Et lite nettsted med 24 avhengigheter

Det første systemet er diggs.no. Det er et innholdsnettsted med et kontaktskjema og en prototype som er satt på pause. Kartleggingen ga 24 oppføringer:

  • åtte som må virke for at nettstedet skal svare: server, webtjener, database, domene, DNS, sertifikat, utrulling og kodelager
  • seks tredjeparter som brukes mens nettstedet kjører, blant annet e-post, besøksstatistikk, samtykkebanner og en språkmodell
  • seks som bare trengs når nettstedet bygges: pakkeregister, skrifter, rammeverk og verktøy
  • fire rester i koden som ikke var i bruk

Tjenestene er samlet i en tabell på metodesiden.

To av funnene er verdt å nevne. Fire ubrukte pakker hadde ligget i prosjektet siden det ble opprettet. Da de ble fjernet, gikk antallet pakker nettstedet hentet ved bygging, fra 1240 til 618. Én av de fire sto for nesten hele fallet. Og tjenesten som sender e-post fra skjemaene, er et amerikansk selskap eid av et svensk. Hvilken jurisdiksjon som gjelder, kan da ikke leses av eierskapet alene.

Én leverandør, fire funksjoner

Det andre systemet er et prosjekt jeg bygger ved siden av, som ikke er lansert. Der hadde jeg valgt europeiske leverandører for servere, lagring, e-post og DNS, og jeg regnet med én amerikansk avhengighet: GitHub, der koden ligger.

Da jeg gikk gjennom dokumentasjonen, viste GitHub seg å dekke fire funksjoner:

  1. Koden, og bygging og utrulling av den.
  2. Registeret der de ferdige programpakkene ligger, og som serverne henter fra.
  3. Hemmelighetene utrullingen trenger. De står aldri i koden. De ligger kryptert i GitHubs eget lager for hemmeligheter, og utrullingen henter dem derfra.
  4. Varslingen. Kontrollen av at sikkerhetskopien er tatt, kjører der, og det er derfra jeg får beskjed hvis den feiler.

Jeg fant også en femte avhengighet som ikke sto på listen min i det hele tatt: sertifikatene for HTTPS, som utstedes av en amerikansk organisasjon.

Kontrollen før publisering fant to til, begge i laget som bare trengs ved bygging: registrene som grunnbildene og programbibliotekene hentes fra. Begge er amerikanske. Kartleggingen av dette systemet er altså ikke gjort like dypt som for diggs.no.

Hva som ikke lot seg se

Kartleggingen av diggs.no gjorde jeg med Claude Code, en språkmodell som leste koden og slo opp det som kan ses utenfra. Likevel sto det igjen 18 spørsmål som ikke kunne besvares derfra. Blant dem:

  • hvordan sertifikatet fornyes
  • hvor sikkerhetskopiene ligger, og hos hvem
  • om noe overvåker nettstedet, og hvem som varsler
  • hvor hemmelighetene oppbevares, og hvem som har tilgang

Svarene finnes bare hos meg, og noen av dem måtte jeg selv slå opp.

Fra utsiden ser man enda mindre. Modellen kunne fastslå hvor serveren står, hvem som har utstedt sertifikatet, og hvor e-posten går, fordi det kan leses av DNS og av svarene fra serveren. Resten er usynlig for den som bare har offentlig dokumentasjon.

Tre lag

Dokumentert

De 24 oppføringene, de fire funksjonene og de 18 åpne spørsmålene. For hver oppføring er det oppgitt om den er sett i koden, sett utenfra eller en slutning.

Slutning

To små systemer er tynt belegg, og begge er bygget av samme person. Jeg slutter likevel dette: en liste over leverandører undervurderer avhengigheten, fordi én leverandør kan dekke flere funksjoner, og fordi det som ligger rundt systemet, ikke står i koden.

Begge systemene er enkle. Det ene er et nettsted med under hundre sider, det andre et prosjekt med én utvikler. Norske kommuner og fylkeskommuner kan ha flere hundre digitale løsninger hver, ifølge en rapport Oslo Economics og Capto laget for KS i februar 2026 (Leverandørmarkedet for digitale løsninger til kommunal sektor). Rapportens definisjon av digitale løsninger omfatter blant annet læringsplattformer. Rapporten beskriver et beslektet mønster i stor skala: avhengigheten av de store internasjonale leverandørene oppstår også indirekte, gjennom løsninger fra norske leverandører som bygger på dem, og kommunene opplever at de mangler innsikt i sentrale forhold ved løsningene.

For sykehusene har jeg ikke funnet et tilsvarende tall, og jeg har ikke kartlagt en slik virksomhet selv. Jeg antar at spørsmålet om hvem som kan stenge hva, er langt vanskeligere å svare på der enn i to systemer jeg har bygget selv. Det er noe prosjektet skal undersøke.

Doktrinens vurdering

Kill switch-testen spør om en ekstern aktør kan stoppe eller begrense systemet. Svaret avhenger av funksjonen. Mister jeg tilgangen til kodelageret, kjører tjenesten videre. Jeg kan bare ikke rulle ut noe nytt, serverne kan ikke hente programpakker, og ingen varsler meg om en sikkerhetskopi som feiler. Det er fire svar på ett spørsmål.

Sertifikatene viser det motsatte. Utstederen er amerikansk, men protokollen er en åpen standard, og et bytte til en europeisk utsteder er en endring i oppsettet. Der har doktrinen rett i at åpne standarder gjør jurisdiksjon til et valg.

Hva det betyr for kartleggingen

Jeg foreslår tre endringer i hvordan en avhengighet kartlegges:

  1. Tell funksjoner, ikke leverandører. Én rad per ting som slutter å virke.
  2. Kartlegg fire lag: det som må virke for at systemet svarer, det som brukes mens det kjører, det som trengs for å bygge det, og det som ligger rundt (hemmeligheter, sikkerhetskopi, overvåking, sertifikater, navnetjenester).
  3. Skill mellom tjenester og programvare. En tjeneste kan stenges utenfra. Åpen kildekode jeg drifter selv, kan ikke det, selv om selskapet bak er amerikansk.

Det er også et svar på et av forskningsspørsmålene i prosjektet: hvor dypt må man kartlegge før en vurdering er gyldig, og kan det gjøres fra offentlig dokumentasjon? For disse to systemene er svaret at koden ikke var nok, og at offentlig dokumentasjon ville gitt enda mindre. Om det finnes en dybde som er god nok, vet jeg ikke ennå.

Bindinger

Jeg er produktleder i Akari, som selger Google Workspace. diggs.no kjører på Hetzner og bruker e-post via Google Workspace. Koden ligger på GitHub. Ingen av avhengighetene på diggs.no har i dag en exit-plan med frist, og nettstedet skal bygges om. Det andre prosjektet er mitt eget.

Slik ble teksten til

Registeret for diggs.no ble laget av Claude Code, som leste koden og slo opp DNS, sertifikat og svarhoder. Teksten er skrevet sammen med Claude. Claude Code har kontrollert tallene om diggs.no mot registeret og git-historikken. Claude Code kontrollerte også beskrivelsen av det andre systemet mot koden, og påstandene om KS-rapporten mot rapporten. KS-rapporten ble funnet av Claude, som har lest sammendraget og de tre første kapitlene. Jeg har ikke lest hele rapporten.