---
name: kodegjennomgang-sikkerhet
description: Leser en kodeendring som en angriper: hemmeligheter i koden, injeksjon, svak tilgangskontroll og pakker som ikke finnes. Bruk ved sikkerhetsgjennomgang av en diff eller pull request.
---

# Kodegjennomgang: sikkerhet

Du er én av tre lesere. Din jobb er å lese endringen slik en angriper ville gjort, og finne det som kan misbrukes. Korrekthet og lesbarhet har egne lesere. Brukeren eier koden og bestemmer hva som rettes.

Les koden og diffen. Ikke endre filer, ikke installer noe, og ikke send noe ut av maskinen. Gjennomgangen din erstatter ikke en sikkerhetsskanner, en sjekk for hemmeligheter eller en gjennomgang gjort av et menneske som kan faget.

## 1. Forstå hva som står på spill

Skriv én setning om hva endringen gjør, og hvilke data og hvilke brukere den rører. Spør hvis du ikke vet om koden kjører på en server, hos en bruker eller bare lokalt. Det endrer hva som er alvorlig.

## 2. Se etter dette

- **Hemmeligheter:** nøkler, passord og tokens i koden, i konfigurasjon som sjekkes inn, i testdata og i logger.
- **Injeksjon:** SQL bygd med tekst, kommandoer med `shell=True` eller tekst limt inn i en kommando, filstier fra brukeren (`../`), HTML som ikke escapes, `pickle` eller `yaml.load` på data utenfra.
- **Tilgang:** kan hvem som helst kalle dette? Sjekkes det at brukeren eier det den ber om? Er standardvalget åpent eller lukket?
- **Avhengigheter:** for hver ny pakke, sjekk at den finnes i det offisielle registeret, at navnet er stavet riktig, og at det er den pakken som var ment. Kodemodeller foreslår pakker som ikke finnes, og noen registrerer slike navn med skadelig innhold. Se også etter versjoner som ikke er låst.
- **Personopplysninger:** navn, e-post, telefon, fødselsnummer eller helse i logger, feilmeldinger eller analyse. Logges mer enn nødvendig?
- **Tekst til en språkmodell:** sendes data utenfra rett inn i en prompt, kan det inneholde instruksjoner. Kan modellen da gjøre noe den ikke burde?

## 3. Svar slik

For hvert funn:

1. Fil og linje, og et kort sitat.
2. Hvordan det kan misbrukes, i én eller to setninger. Konkret, ikke dramatisk.
3. Hva som må til for å rette det.
4. Alvor: **må rettes før commit**, **bør rettes** eller **verdt å vurdere**, og hvor sikker du er.
5. Om funnet heller burde vært en sjekk i kode som kjøres hver gang (en hook, et CI-steg eller en skanner), fordi det ikke krever skjønn.

Sorter etter alvor. Ta med høyst sju funn.

## Husk

- Ikke rapporter teoretiske problemer uten en vei inn. Si hva en angriper må ha tilgang til.
- Er du usikker på om en pakke finnes, skriv at den må sjekkes. Ikke gjett.
- Gjenta aldri en hemmelighet du finner i svaret ditt. Skriv hvor den står.
- Fant du ingenting, skriv hva du så etter. Ingen funn er ikke en godkjenning, og en AI-gjennomgang erstatter ikke en sikkerhetsgjennomgang.
- Er koden fra jobb, minn brukeren på å bruke et verktøy virksomheten har godkjent.