En utvikler åpner IDE-en, beskriver hva de ønsker på lettfattelig språk, og ser en AI-agent skrive funksjonen i løpet av tiden det tar å få kaffe. Den kompileres. Den passerer det manuelle klikk-gjennomgangen. Den sendes. Ingen spurte om den var sikker, fordi ingen spurte om mye av noe. Ledeteksten erstattet pull request, og «det fungerer» erstattet «jeg har anmeldt det». Det er vibe-koding, og det er ikke lenger en uvane. Det er slik en økende andel av produksjonskoden skrives, av profesjonelle team, ikke bare hobbyister som eksperimenterer med en helgeapp. Og det er nettopp derfor vibe-kodingssikkerhet har blitt samtalen alle ingeniør- og sikkerhetsledere har, enten de har gitt det navnet ennå eller ikke.
Hva «vibe-koding» egentlig betyr
Vibe-koding er programvareutvikling der en person beskriver det ønskede resultatet i naturlig språk, og en AI-modell, eller en agent bygget på en, genererer arbeidskoden. Personen styrer etter resultatet («bygge en login flow, «legg til en CSV-eksport») i stedet for å skrive eller linje for linje gjennomgå implementeringen. Begrepet ble populært fordi det fanger opp noe reelt: utvikleren går ut fra at resultatet er riktig, ikke på en lesing av selve koden.
Det skiftet er hele historien. Kodegjennomgang pleide å være et kontrollpunkt innebygd i hvordan programvare ble skrevet. Vibe-koding ruter rundt det med design. Hastigheten går opp. Vanen med å spørre «hva gjør dette egentlig» forsvinner.
Hvorfor «det fungerer» er feil indikator
«Det fungerer» betyr at koden gjorde det som ble spurt om i scenarioet som ble testet. Det sier ingenting om hva koden gjør i scenarioer ingen spurte om: feilformet input, en autentisert bruker som undersøker et endepunkt som stolte for mye på dem, en avhengighet som aldri ble sjekket, en hardkodet hemmelighet som ligger åpent synlig. Det er her vibe-kodingssikkerheten bryter sammen før noen i det hele tatt legger merke til at det er et problem.
AI-kodingsmodeller er trent til å produsere funksjonell utdata som samsvarer med intensjonen til en ledetekst. Sikkerhet er ikke den objektive funksjonen. En modell som optimaliserer for «dette tilfredsstiller forespørselen» vil gjerne generere en spørring bygget med strengsammenkobling i stedet for parametere, et endepunkt uten tilgangskontroll fordi ledeteksten aldri nevnte hvem som ikke skulle ha tilgang, eller et API-kall som stoler på et svar den skal validere. Den kompilerer. Den fungerer. Den introduserer også de samme sårbarhetsklassene som AppSec-team har brukt et tiår på å lære utviklere opp, generert i et tempo ingen manuell gjennomgangsprosess ble bygget for å matche.
Intern forskning på AI-generert kode setter reelle tall bak intuisjonen: en betydelig andel av det agentiske kodeverktøy produserer inneholder en utnyttbar sikkerhetsfeil ved første gjennomgang, før noen gjennomgang i det hele tatt skjer. Det er ikke en feil i én modell. Det er det forventede resultatet av å optimalisere for «det kjører», ikke «det holder mål», og det er det nøyaktige gapet kodingsikkerhet må tette.
Risikoflaten er bredere enn selve koden
Vibe-koding sikkerhet blir ofte innrammet som en problem med kodekvalitet, men eksponeringen går gjennom hele arbeidsflyten agent berører, ikke bare funksjonen den skriver:
Hvorfor tradisjonelle AppSec-verktøy henger etter her
De fleste verktøy for applikasjonssikkerhet ble bygget rundt en rytme: kode skrives, deretter skannes den, i CI eller på PR. Denne rytmen forutsetter at det finnes en stabil, menneskeskapt artefakt å peke en skanner mot, og at volumet av endringen er noe en pipeline kan gjennomgå bevisst.
Vibe-koding bryter timingen, og dette tidsgapet er kjernen i sikkerhetsproblemet med vibe-koding. Kode endres inne i IDE-en på sekunder, ofte før den i det hele tatt når et punkt. pull requestEn skanner som bare kjører i CI fanger opp problemet i etterkant, når det usikre mønsteret allerede er slått sammen, allerede en del av den neste funksjonen noen andre bygger videre på. Og en skanner som behandler AI-generert kode på samme måte som all annen kode, går glipp av de delene av risikoen som er spesifikke for hvordan den ble skrevet: pakken agenten valgte uten å bli bedt om å begrunne den, instruksjonsfilen som fortalte agenten hva den skulle gjøre før et menneske i det hele tatt så en diff.
Hva som egentlig tetter gapet
Organisasjonene som ligger foran dette, bremser ikke ned vibe-kodingen. De bygger inn ekte vibe-kodingssikkerhet i arbeidsflyten: De flytter kontrollpunktet tilbake til der koden faktisk er skrevet, og behandler AI-generert kode som upålitelig input inntil det motsatte er bevist:
- Skann inne i IDE-en, ikke bare i CI. Å fange opp et usikkert mønster mens agenten fortsatt genererer funksjonen er et annet problem enn å fange det opp etter at tre funksjoner til er avhengige av det.
- Valider alle avhengigheter en agent introduserer, på samme måte som du ville validert en som en utvikler skrev inn manuelt, før den installeres.
- Behandle konfigurasjonsfiler som en agent leser som kode, ikke dokumentasjon. Regelfiler, ferdighetsfiler og MCP-serverkonfigurasjoner kan inneholde instruksjoner som endrer hva en agent gjør, og de fortjener samme gransking som koden agenten produserer.
- Hold et menneske oppdatert for å fikse det, ikke bare flagget. En utvikler som kan se hvorfor noe kan utnyttes, ikke bare at det utløste en regel, lærer faktisk å utstede spørsmål og gjennomgå annerledes neste gang.
- Anta at «det fungerer» aldri var sikkerhetsbaren, og gjør den faktiske linjen synlig i arbeidsflyten i stedet for å la den være lagret i minnet.
Der Xygeni passer inn
Dette er akkurat sømmen Xygenis DevAI ble bygget for å lukkes. DevAI kjører som et kontinuerlig sikkerhetslag inne i IDE-en, og ser på menneskeskrevet og AI-generert kode mens den produseres, ikke etter at den havner i en pull requestDen venter ikke på en melding: den flagger utnyttbare mønstre, forklarer den virkelige angrepsveien i et enkelt språk og foreslår en løsning som utvikleren kan gjennomgå og implementere uten å forlate flyten sin. På forsyningskjedesiden, MEW (tidlig advarsel om skadelig programvare) fanger opp ondsinnede pakker før en signatur finnes, noe som er direkte viktig her, siden en agent som velger en avhengighet på dine vegne er akkurat det øyeblikket en uautorisert eller kompromittert pakke slipper inn.
Under begge korrelerer CoreAI det som finnes på tvers av kodebasen, avhengigheter og pipeline inn i én prioritert risikovisning, og den visningen er ikke begrenset til Xygenis egne skanninger. Det gjelder det samme AI-triage, forklaring, og utbedring til funn fra andre skannere som allerede er på plass, så å sikre vibe-koding betyr ikke å rive ut en stabel som allerede fungerer. Det betyr å legge et lag over den som til slutt beveger seg i den hastigheten koden nå skrives.
FAQ
Er vibe-koding iboende usikker?
Nei. Vibe-koding er en utviklingsmetode, ikke en sårbarhet. Risikoen kommer fra å hoppe over gjennomgangstrinnet som pleide å fange opp usikre mønstre, ikke fra å bruke AI til å skrive kode i utgangspunktet. Det er derfor Vibe-kodingssikkerhet er en arbeidsflytdisiplin, ikke en grunn til å unngå praksisen.
Kan eksisterende SAST or SCA Verktøy fanger opp sikkerhetsrisikoer for vibe-koding?
De fanger opp noe av det, men vanligvis etter at koden allerede har blitt slått sammen, siden de fleste kjører i CI i stedet for inne i IDE-en der koden genereres. De evaluerer vanligvis heller ikke AI-agentens egen oppførsel, for eksempel pakkene den velger eller konfigurasjonsfilene den leser.
Hva er den mest effektive løsningen for sikkerhet ved vibe-koding?
Flytt sikkerhetskontroller inn i IDE-en, på genereringstidspunktet, i stedet for å bare stole på en senere pipeline skanning. Å oppdage et problem før det er en del av de neste tre funksjonene som er bygget oppå det, er et annet problem enn å oppdage det etterpå.
Betyr det å sikre vibe-koding at utviklere går saktere?
Ikke hvis sjekken skjer innebygd, i IDE-en, med en forklaring og en klar løsning. Målet er å beholde hastighetsviben som koding tilbyr, samtidig som man gjenoppretter vurderingsevnen som manuell gjennomgang pleide å gi.
