Skip to content
Sikkerhetssjekk av AI-kode

Appen din virker. Er den trygg å lansere?

En utvikler leser koden AI-verktøyene skrev, og tjenestene bak den: nøkler, innlogging, tilgang til databasen og pakker. Du får en skriftlig rapport rangert etter risiko og en plan for utbedring, før ekte brukere og ekte data kommer inn.

  • Funn rangert etter risiko, med løsning for hvert enkelt
  • Skriftlig rapport og gjennomgangssamtale
  • Vi leser og rapporterer. Vi endrer ingenting uten din godkjenning
OWASP 2025 Sjekklisten vi måler mot
Menneske Hvert funn kontrollert av en utvikler
Rangert Fiks det farligste først
Din Du beholder rapporten og koden

Først det ærlige: AI-skrevet kode er ikke problemet. Ukontrollert kode er det.

Mange apper bygget med Cursor, Lovable, Bolt eller Claude Code er helt greie. Verktøyene lager kode som kjører, og det er nettopp derfor feilene blir værende: en manglende tilgangsregel merkes ikke så lenge du er eneste bruker. En sikkerhetssjekk er verdt pengene når ekte kunder, ekte betalinger eller personopplysninger snart skal inn i appen. Er det en prototype ingen andre skal bruke, trenger du oss ikke ennå. Det sier vi i det første svaret.

Seks steder AI-bygde apper oftest svikter

Målt mot OWASP Top 10:2025, den vanlige listen over risikoer i webapplikasjoner, og mot det plattformen du bygde på selv sier om trygg bruk.

Lekkede nøkler og hemmeligheter

API-nøkler, databasepassord og tjenestetokens i frontend-kode, i historikken til repoet eller i en fil som havner på serveren. Noen nøkler skal være offentlige, andre aldri. Vi finner ut hva som er hva i din løsning.

Tilgangskontroll og databaseregler

Kan en bruker lese eller endre en annen brukers data? På Supabase betyr det row level security på hver tabell. I en egen backend betyr det en tilgangssjekk på hver rute. Brutt tilgangskontroll er nummer én på OWASP-listen.

Injeksjon og utrygg inndata

SQL bygget av brukerinndata, uescapet utdata, filopplasting som tar imot hva som helst. Vi leser koden som håndterer inndata, der generatorer oftest gjør små, farlige feil.

Avhengigheter og pakker

Utdaterte biblioteker, pakker ingen vedlikeholder og pakker som ikke finnes. Forskning har vist at kodegenererende modeller finner på pakkenavn, og at angripere kan registrere de navnene. Vi sjekker at hver pakke er ekte, oppdatert og nødvendig.

Feilmeldinger, logging og oppsett

Feilsøkingsmodus på i produksjon, feilsider som viser interne detaljer, ingen logg over hvem som gjorde hva. Små innstillinger med store følger.

Tester og vedlikeholdbarhet

Finnes det en test som fanger en ødelagt innlogging? Kan en utvikler som ikke brukte AI-verktøyet forstå strukturen? Kode du ikke kan endre trygt er en risiko i seg selv.

Prisen følger størrelsen på koden

Eksakt pris kommer etter en kort titt på repoet. Alle priser er eks. mva.

Sikkerhetssjekk

En mindre app eller én tjeneste
Fra 5 990 kr
  • Gjennomgang av hemmeligheter, tilgangskontroll, injeksjon og pakker
  • Funn rangert etter risiko og innsats
  • Skriftlig rapport
  • Gjennomgangssamtale
  • Utbedringsplan du kan gi til en hvilken som helst utvikler

Større løsninger

Betaling, personopplysninger eller flere tjenester
Pris etter omfang
  • Alt i Sikkerhetssjekk, pluss:
  • Dypere gjennomgang av innlogging og betalingsflyt
  • Gjennomgang av databaseregler og hosting
  • Vurdering av tester og vedlikeholdbarhet
  • Flere repoer eller tjenester i én gjennomgang
  • Omfanget avklares før du får en pris

Alle priser er eks. mva. Trenger du heller en gjennomgang av en nettbutikk? Se WooCommerce-analyse. Trenger du utbedringene bygget? Se fikse PHP-feil.

Ærlige funn, ingenting konstruert

Er koden din i god stand sier vi det i stedet for å finne på feil. En sikkerhetssjekk kan ikke ødelegge appen din: vi leser den, vi endrer den ikke. Omfang og pris avtales skriftlig før vi starter.

Hva forskningen sier, og hva den ikke sier

Tall om AI-kode siteres slurvete. Her er hva kildene faktisk sier.

Veracode testet over 100 språkmodeller på 80 kodefullføringsoppgaver bygget rundt kjente svakheter, og meldte at modellene innførte sikkerhetsfeil i 45 prosent av tilfellene. Java feilet i over 70 prosent, og Python, C# og JavaScript mellom 38 og 45 prosent. To forbehold. Veracode selger sikkerhetsverktøy, og oppgavene var laget for å være risikable, så dette er ikke feilraten i din app. Tallet viser likevel at en modell som får velge mellom en trygg og en utrygg løsning ofte velger den utrygge, så gjennomgang er ikke valgfritt.
Mange AI-appbyggere setter en Supabase-database bak en frontend i nettleseren. Supabase skriver selv i dokumentasjonen at en tabell i et eksponert skjema uten row level security kan leses og skrives av enhver rolle som har tilgang til den, og at du bør slå det på for hver tabell. Den offentlige nøkkelen er laget for å være synlig, men bare trygg når reglene finnes. Den hemmelige nøkkelen er det motsatte: den omgår alle regler og skal aldri ligge i nettleseren, i en publisert app eller i kildekoden. En sikkerhetssjekk ser på begge, for en app kan se ferdig ut uten at noen av delene er på plass.
En studie på USENIX Security 2025 genererte 576 000 kodeeksempler med 16 modeller og fant oppdiktede pakkenavn i minst 5,2 prosent av eksemplene fra kommersielle modeller og 21,7 prosent fra åpne modeller i gjennomsnitt, med over 200 000 unike oppdiktede navn. Den som registrerer et slikt navn kan levere skadelig kode til alle som installerer det modellen foreslo. Dette er nå en egen kategori på OWASP-listen: svikt i programvarens forsyningskjede.
Rammeverkene er tydelige. Laravel skriver at feilsøkingsinnstillingen alltid skal være false i produksjon, fordi true kan avsløre sensitive oppsettsverdier for sluttbrukerne. Et prosjekt som gikk fint på en bærbar kommer ofte ut med den på. Det er en rettelse på én linje som lett blir glemt.
PHP-manualen sier at hvis en applikasjon bare bruker forberedte spørringer, kan man være sikker på at SQL-injeksjon ikke skjer, og legger til forbeholdet: bygges andre deler av spørringen av uescapet inndata, er injeksjon fortsatt mulig. Generert kode blander ofte begge stilene i samme fil. Å lese koden er den eneste pålitelige måten å finne unntaket på.
Lagrer appen personopplysninger, stiller personvernforordningen i artikkel 32 krav til tekniske og organisatoriske tiltak som gir et sikkerhetsnivå tilpasset risikoen, og en prosess for regelmessig testing og vurdering av tiltakene. Datatilsynet beskriver det som å behandle personopplysninger lovlig, sikkert og forsvarlig. En skriftlig sikkerhetssjekk er ikke et samsvarsbevis, men den er et konkret ledd i å teste og vurdere sikkerheten.
Den er en vurdering på ett tidspunkt. Den beviser ikke at en app er sikker, og den er verken en penetrasjonstest eller et sertifikat. Den reduserer risikoen ved å finne de vanlige, rettbare feilene og gi deg en plan. Kode som endres i morgen må gjennomgås på nytt.

Når en sikkerhetssjekk er verdt pengene

Fire tegn, og ett tegn på at du kan vente.

Når andres data eller penger er involvert, slutter en feil å være ditt eget problem. Sjekk før lansering, ikke etter første hendelse.
Det er normalt med generert kode, og det er det tydeligste signalet. Kan ingen på teamet si hvem som får lese hvilke poster, bør noen finne ut av det.
En skriftlig rapport med rangerte funn og hva som ble rettet er et bedre svar enn «AI-en skrev den».
Et utgangspunkt før du bygger videre sparer deg for å bygge om senere.
Det er en prototype for deg selv eller en demo med falske data og uten innlogging. Hold ekte nøkler utenfor, og kom tilbake før ekte brukere kommer.

Hvilke teknologier vi gjennomgår, og hvilke vi ikke gjør

Vi jobber i PHP (Laravel, Symfony og ren PHP), WordPress og WooCommerce, med noe Vue.js og React i frontend, og vi kjenner mønsteret med en nettleserapp som snakker med en hostet database som Supabase. Rene mobilapper, eller backend i språk utenfor dette, sier vi heller fra om og viser deg videre enn å gjette. Skriv teknologivalget i skjemaet under, så sier vi om vi er riktig folk.

Fra tilgang til repoet til en utbedringsplan

Lesetilgang er nok. Vi trenger ikke passord til produksjon.

1

Kort avklaringssamtale

Du forteller hva appen gjør, hvem som skal bruke den og hvilke data den har. Vi bekrefter at teknologivalget er noe vi kan gjennomgå, og avtaler omfang og pris skriftlig.

2

Lesetilgang

Tilgang til repoet, pluss en beskrivelse av hosting og eventuelle databaseregler. Vi trenger aldri hemmelighetene dine fra produksjon.

3

Gjennomgang

Automatiske skannere for kjente feil og pakkeproblemer, deretter leser en utvikler koden som håndterer innlogging, datatilgang, inndata, betaling og oppsett. Skannere finner kjente mønstre. Lesingen finner logikkfeilene.

4

Rapport og gjennomgang

Funn rangert etter risiko og innsats, hvert med løsning. En samtale der vi går gjennom dem og svarer på spørsmål.

5

Utbedring, hvis du vil

Du kan gi planen til din egen utvikler, eller be oss gjøre endringene under en egen, avtalt avgrensning.

Hva kundene sier

Ekte ord fra PHP- og WordPress-prosjekter

"
Jeg var i den uheldige posisjonen å stå med et kodeproblem jeg ikke fikk løst selv, og som trengte umiddelbar løsning. Nordic Digi Solutions hadde full kontroll. De visste nøyaktig hva som måtte gjøres (selv når jeg slet med å forklare nøyaktig hva som var galt), og de fikk siden min opp og gå igjen på meget kort tid og med et enda strammere budsjett. Jeg kan ikke anbefale dem nok!
BK
Bruce Kassover
Repairs Unlimited
"
Hasan var lynkjapp og pålitelig med å løse et Elementor-problem jeg hadde med en kundes nettside. Vi er oppe og går igjen.
PC
Philippa Channer
Grunnlegger, Channer Consulting
"
Det er en glede å jobbe med dette selskapet. Hasan er utrolig responsiv og kunnskapsrik. De hjelper oss virkelig med å løse alle problemer med webutvikling som oppstår, og gjør det raskt. Jeg anbefaler dette selskapet til alle som trenger digitale forretningsløsninger.
M
Mona
Web Manager, VMT Enterprises

Hva gründere spør om før en sikkerhetssjekk av AI-kode

En gjennomgang av kode skrevet med AI-verktøy, utført av et menneske, som leter etter feilene som betyr noe før lansering: lekkede hemmeligheter, manglende tilgangskontroll, injeksjon, risikable pakker og utrygt oppsett. Resultatet er en rangert rapport og en utbedringsplan.
Det kan hjelpe med noe, og vi bruker selv skannere. Men en modell som gjennomgår kode den eller en søskenmodell skrev har ofte de samme blindsonene, og logikkfeil som «bruker A kan åpne bruker Bs faktura» krever noen som forstår hva appen skal tillate.
Ja, når resultatet er en kodebase i en teknologi vi jobber i. Verktøyet betyr mindre enn det det laget. Si fra om teknologivalget og hvor det er hostet.
Nei. Lesetilgang til koden er nok. Hvis et funn må sjekkes mot det som kjører, ber vi deg se etter eller sende et skjermbilde, ikke levere fra deg hemmeligheter.
Anse den som kompromittert: bytt den hos leverandøren først, fjern den deretter fra koden og fra historikken i repoet. Vi lister hver slik nøkkel i rapporten med trinnene. Å fjerne den fra koden alene gjør den ikke trygg igjen.
Nei. En penetrasjonstest angriper et system som kjører. En sikkerhetssjekk av kode leser kildekode og oppsett. De finner ulike ting, og noen prosjekter trenger begge.
Det avhenger av hvor stor kodebasen er, og bekreftes skriftlig etter avklaringssamtalen. Du får en dato før du betaler.
Ja, som en egen avtale. Se fikse PHP-feil. Er du et byrå som trenger utviklerkapasitet, se underleverandør for byråer.
Start med appen

Fortell oss hva du har bygget og hvordan

Noen linjer om hva appen gjør, hvilke AI-verktøy som skrev den, teknologivalget og hvor den er hostet er nok til å begynne. Alt du deler behandles konfidensielt.

  • Personlig svar fra en utvikler, ikke et auto-svar
  • Vi sier fra hvis vi ikke passer for teknologivalget ditt
  • Omfang og pris skriftlig før arbeidet starter
  • Lesetilgang er nok

Beskriv appen

Ta med verktøyene du brukte, teknologivalget, hvor den er hostet og når du vil lansere.





    Chat på WhatsApp