Hvis du tror at AI skriver feilfri kode fordi den er «smart», tar du en stor sjanse. Vibe coding - der vi bruker AI-assistenter til å generere kode via samtale - har revolusjonert utviklingshastigheten, men det har også åpnet et nytt frontlinje for sikkerhetsrisikoer. AI-modeller kan hallusinere pakker som ikke finnes, glemme autentisering eller introdusere sårbare mønstre som tradisjonell kodegjennomgang lett overser. I 2026 er løsningen ikke å slutte å bruke AI, men å bygge robuste branch protection-regler som fungerer som automatiske portvoktere før koden når produksjon.
Vibe coding er praksisen med å bruke store språkmodeller (LLM) for å skrive programkode gjennom naturlige språkinnstillinger. Selv om dette øker produktiviteten, introduserer det unike risikoer som hallusinerte avhengigheter, manglende sikkerhetskontroller og inkonsekvent kodekvalitet. Sikre disse repositoryene krever mer enn bare manuell gjennomgang; det krever infrastruktur-nivå beskyttelse integrert direkte i arbeidsflyten din.
Hvorfor tradisjonell kodegjennomgang svikter ved AI-generert kode
Menneskelige koderevysere er gode på logikk og arkitektur, men de er dårlige på å oppdage subtille sikkerhetsfeil i store mengder AI-generert tekst. En studie fra Kusari i 2026 viste at det er betydelig billigere å fange opp sårbarheter før kode slås sammen (merge) enn etterpå. Problemet med vibe coding er at AI ofte antar «standard» konfigurasjoner som er for løse. For eksempel vil en AI nesten alltid legge til overflødige tillatelser i databasekonfigurasjonen eller glemme viktige sikkerhetshoder i webapplikasjoner. Hvis du ikke håndhever regler automatisk, vil disse feilene smette gjennom. Branch protection tvinger frem kontrollpunkter som verken kan ignoreres eller hoppes over, selv om utvikleren er i hastverk.
Kjernekomponentene i en sikker branch protection-strategi
For å beskytte repoet ditt må du implementere flere lag med automatisert skanning på pull request-nivå. Her er de fire søylene du ikke kan unnvære:
- SAST (Static Application Security Testing): Verktøy som Semgrep eller CodeQL skanner koden for kjente sårbarhetsmønstre som SQL-injeksjon og XSS. Dette bør kjøres både pre-commit og i CI-pipelinen.
- SCA (Software Composition Analysis): AI elsker å foreslå biblioteker. Noen ganger hallucinerer den navn som ikke eksisterer, og angripere oppretter reelle pakker med disse navnene (typosquatting). Verktøy som Snyk eller Trivy sjekker hver avhengighet mot kjente CVE-er.
- Secrets Scanning: Gitleaks eller GitGuardian må blokkere alle commits som inneholder API-nøkler, passord eller tokens. AI har en tendens til å hardkode prøvenøkler i eksempler, noe som er en klassisk sikkerhetsbrudd.
- DAST (Dynamic Application Security Testing): Etter deploy til staging, bruk verktøy som OWASP ZAP for å teste applikasjonen mens den kjører, for å fange opp feil i autentisering eller CORS-konfigurasjon.
Håndtering av «Hallucinerte Bypass» og avhengighetsrisiko
En av de mest spesifikke farene ved vibe coding er at AI tilfeldigvis kan slette sikkerhetskontrollord eller endre autorisasjonslogikk under refactoring. Vi kaller dette «hallucinert bypass». Løsningen er ikke å stole på at AI-en selv-revierer koden sin (selv om to-trinns prompting hjelper), men å isolere applikasjonen på infrastruktur-nivå. Bruk verktøy som Cloudflare Zero Trust eller NGINX-regler som nekter trafikk hvis visse hoder mangler, uavhengig av hva koden sier.
Videre må du håndtere avhengigheter strengt. AI foreslår ofte nyeste versjon av et npm-pakke uten å låse versjonen. Hvis en leverandør blir kompromittert, arver du problemet umiddelbart. Implementer «cooldown policies» som blokkerer installasjon av helt nye pakkeversjoner i et bestemt tidsrom. Dette ga kunder hos StepSecurity beskyttelse mot Shai-Hulud-angrepene i 2025 lenge før offentlige advisories ble publisert.Praktiske regler for database og nettverkssikkerhet
AI-genererte databaselag er notorisk dårlige på tilgangskontroll. Husk «Lovable and Tea disaster»? AI konfigurerte databaser uten riktige access controls, og data lekket ut. Branch protection-reglene dine må verifisere at:
- All databaseadgang bruker parameteriserte spørringer (aldri strengkonkatenering).
- Row Level Security (RLS) er aktivert på alle tabeller, slik at brukere kun ser sine egne data.
- Tjenestenøkler (service role keys) aldri sendes til klienten.
helmet.js eller manuelle hoder som X-Content-Type-Options: nosniff og Strict-Transport-Security. Lag en linter-regel eller en custom check i CI som feiler PR-en hvis disse hodene mangler i responsene.
Sammenligning av skanningsnivåer
| Skanningstype | Fanger opp | Når bør den kjøres? | Anbefalt verktøy |
|---|---|---|---|
| SAST | Insecure patterns, Injection flaws | Pre-commit & PR | Semgrep, CodeQL |
| SCA | Vulnerable dependencies, Typosquatting | PR | Snyk, Trivy |
| Secrets | Hardcoded keys, Tokens | Pre-commit | Gitleaks |
| DAST | Runtime errors, Auth bypass | Staging Deploy | OWASP ZAP |
Balansen mellom fart og sikkerhet
Utviklere hater ventetid. Hvis branch protection blokkerer alt, begynner folk å omgå prosessen. Nøkkelen er å sette opp «pass/fail gates» som er presise. Ikke blokker PR-en for kosmetiske lint-feil, men vær kompromissløs på kritiske sikkerhetsfunn fra SAST og Secrets scanning. Bruk verktøy som viser nøyaktig hvor feilen er og hvordan fikse den, slik at AI-assistenten din kan foreslå en patch automatisk. Dette skaper en loop hvor AI skriver, AI reviserer basert på sikkerhetsfeedback, og mennesket godkjenner.
Husk at branch protection ikke bare handler om kode, men også om tillatelser. Sørg for at IAM-rollene som tildeles tjenestene er minimalt privilegerte. AI ber ofte om*:* eller AdministratorAccess fordi det «fungerer». Tving frem prinsipper om minste privilegium via policy-as-code (f.eks. OPA Gatekeeper) i pipeline.
Er AI-generert kode mindre sikker enn menneskeskrevet kode?
Ikke nødvendigvis mindre sikker i seg selv, men den har andre feilmønster. Mennesker lager logiske feil; AI lager ofte feil knyttet til kontekst, som å glemme autentisering eller velge usikre standardbiblioteker. Med riktig branch protection kan AI-kode faktisk være sikrere fordi den er konsistent og lett å skanne automatisk.
Hva er typosquatting i sammenheng med vibe coding?
Typosquatting skjer når AI hallucinerer et pakke-navn som ikke finnes (f.eks. react-helptext). Angripere registrerer denne pakkernavnet på npm/pypi med samme navn, men inneholder ondsinnet kode. Når utvikleren installerer pakkene AI foreslo, får de malware. Branch protection med SCA-verktøy som sjekker mot registrene kan stoppe dette.
Hvilke verktøy anbefales for secrets scanning i GitHub Actions?
Gitleaks er standardvalget for mange på grunn av ytelsen og enkel integrasjon. GitGuardian gir mer kontekst og historikk, men kan være dyrere. Det viktigste er at skannen blokkerer merge hvis et hemmelig funnes, ikke bare advarer.
Kan jeg stole på at AI-en selv finner sikkerhetsfeilene sine?
Nei, ikke alene. AI kan brukes i en «self-reflection»-fase for å forbedre koden, men den har blindsoner. Den kan ikke vite om bedriftens spesifikke compliance-krav eller nye null-dagers sårbarheter i avhengigheter. Automatisk skanning (SAST/SCA) er nødvendig som en ekstern kilde til sannhet.
Hva betyr «cooldown policy» for npm-pakker?
Det er en regel som forbyr installasjon av versjoner som er publisert innenfor de siste X timene/dagene. De fleste supply chain-angrep skjer rett etter publisering før samfunnet har rukket å inspisere koden. Ved å vente, reduserer du risikoen betraktelig.