I vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til Code Review, eller kodegjennomgang.

Hovedmålet for praksisen “Kodegjennomgang” er kvalitetskontroll. De som utfører kodegjennomgang må sørge for at sikkerhetsfeil oppdages og korrigeres. SSG må sørge for at standarder blir fulgt og at godkjente sikkerhetsmekanismer gjenbrukes.

CR Nivå 1: Bruk manuell og automatisert kodegjennomgang med sentralisert rapportering.

Programvaresikkerhetsgruppen (SSG) må gjøre seg tilgjengelig ovenfor andre for å øke bevisstheten om og etterspørsel etter kodegjennomgang. SSG må utføre kodegjennomgang på høyrisiko-applikasjoner når den kan bli involvert i prosessen, og må bruke kunnskapen som tilegnes til å informere virksomheten om typen feil som oppdages. Ledelsen må gjøre kodegjennomgang obligatorisk for alle programvareprosjekter. SSG må tvinge gjennom bruk av sentraliserte rapporteringsverktøy for å samle inn kunnskap om tilbakevendende feil, og kanalisere denne informasjonen inn i strategi og opplæring.

• CR1.1: Lag en “topp N” feil-liste (virkelige data foretrukket)
  SSG vedlikeholder en liste av de viktigste feilene som må elimineres fra virksomhetens kode, og bruker den til å drive frem endringer. Listen bidrar til å fokusere virksomhetens oppmerksomhet mot de feilene som betyr mest. En generisk liste kan lastes ned fra offentlige kilder, men en liste er mye mer verdifull dersom den er spesifikk for virksomheten, og basert på virkelige data hentet fra kodegjennomgang, testing, og virkelige hendelser. SSG kan oppdatere listen regelmessig, og publisere en “mest ettersøkt” rapport. Noen virksomheter bruker flere verktøy og data fra virkelige kodebaser for å bygge opp topp N lister, uten å begrense seg til en bestemt tjeneste eller verktøy. En potensiell fallgrube med en topp N liste er problemet med å “lete etter nøklene kun under gatelyset”. F.eks. vil “OWASP top ten” sjelden reflektere en virksomhets feilprioriteter. Ved kun å rangere dagens feildata etter antall tilfeller per feil vil ikke resultere i en tilfredsstillende topp N liste, ettersom disse dataene endrer seg så ofte.
• CR1.2: La SSG utføre ad hoc gjennomgang
  SSG utfører ad hoc kodegjennomgang for høyrisiko-applikasjoner på en opportunistisk måte. F.eks. kunne SSG følge opp designgjennomgangen for høyrisiko-applikasjoner med en kodegjennomgang. Erstatt ad hoc gjennomgang med en systematisk tilnærming på høyere modenhetsnivåer. SSGs gjennomgang kan involvere bruk av spesifikke verktøy og tjenester, eller den kan være manuell.
• CR1.4: Bruk automatiserte verktøy sammen med manuell gjennomgang
  Integrer statisk analyse i kodegjennomgangs-prosessen for å gjøre kodegjennomgang mer effektiv og mer konsistent. Automatiseringen erstatter ikke menneskelige vurderinger, men hjelper til med å definere prosessen og bidrar med sikkerhetsekspertise til evaluatorer som ikke er sikkerhetseksperter. En virksomhet kan bruke en ekstern tjenesteleverandør som en del av en formell kodegjennomgangs-prosess for programvaresikkerhet. Denne tjenesten burde eksplisitt kobles til en større “sikker programvareutviklings-livssyklus” (SSDL) som anvendes som en del av programvareutviklingen, og ikke bare en “huk av sikkerhetsboksen” på veien til utrulling.
• CR1.5: Gjør kodegjennomgang obligatorisk for alle prosjekter
  Kodegjennomgang er et obligatorisk sjekkpunkt for alle prosjekter som hører inn under SSG. Manglende kodegjennomgang eller uakseptable resultater vil føre til stopp i utrullingsprosessen. Mens alle prosjekter på utsettes for kodegjennomgang, kan prosessen variere mellom forskjellige typer prosjekter. Gjennomgangen for lavrisiko-prosjekter kan basere seg tungt på automasjon, mens kodegjennomgang for høyrisiko-prosjekter kanskje ikke har noen øvre grense for hvor mye tid som kan brukes. I de fleste tilfeller vil et kodegjennomgang-sjekkpunkt med en minimum akseptabel standard tvinge prosjekter som ikke består til å bli reparert og re-evaluert før de kan leveres.
• CR1.6: Bruk sentralisert rapportering til å lukke kunnskaps-sirkelen og drive opplæring
  Feilene som finnes gjennom kodegjennomgang spores i et sentralt arkiv. Dette arkivet gjør det mulig å lage oppsummerende rapporter og trend-rapporter for virksomheten. SSG kan bruke rapportene for å demonstrere framgang og som en pådriver for opplæringspensumet. Informasjon fra kodegjennomgang kan inkluderes i et sikkerhetssjef-nivå instrumentpanel som omfatter informasjon fra andre deler av sikkerhetsorganisasjonen. På samme måte kan informasjon fra kodegjennomgang mates inn i et prosjektsporingssystem på tvers av utviklingsorganisasjonen som samler sammen et antall forskjellige programvaresikkerhetsresultater (f.eks. penetreringstester, sikkerhetstester, svart-boks tester, hvit-boks tester, etc.). Ikke glem at individuelle feil utgjør glirende opplæringseksempler.

CR Nivå 2: Følg opp standarder via kodegjennomgangsprosessen.

SSG må lede utvikler-oppførsel ved å følge opp kodestandarder vha. automatiserte verktøy og verktøy-mentorer. SSG må kombinere automatiserte evalueringsteknikker med skreddersydde regler for å effektivt finne problemer.

• CR2.2: Tving gjennom og følg opp kodestandarder
  Et brudd på virksomhetens sikre kodestandarder er tilstrekkelig grunn til å forkaste et stykke kode. Kodegjennomgang er objektiv – den kan ikke reduseres til en diskusjon om hvorvidt dårlig kode kan utnyttes av angripere. Den delen av standarden som følges opp kan starte med noe så enkelt som en liste med forbudte funksjoner. I noen tilfeller publiseres kodestandarder som utvikler-retningslinjer spesifikke til teknologistakker (f.eks. retningslinjer for C++ eller Spring) som så følges opp i kodegjennomgangsprosessen eller direkte i det integrerte programmeringsmiljøet (IDE). Bemerk at retningslinjer kan være positive (“gjør det på denne måten”) men også negative (“ikke bruk dette APIet).
• CR2.5: Tilordn verktøymentorer
  Mentorer er tilgjengelige for å vise utviklere hvordan de skal få det meste ut av kodegjennomgangsverktøyer. Hvis SSG har mest erfaring med verktøyene, kan den bruke kontortid til å hjelpe utviklere etablere den riktige konfigurasjonen eller komme igang med tolkning av resultater. Alternativt kan noen fra SSG jobbe med en utviklergruppe gjennom hele gjennomgangen de utfører. Sentralisert bruk av et verktøy kan distribueres utover i utviklingsorganisasjonen over tid gjennom bruk av verktøymentorer.
• CR2.6: Bruk automatiserte verktøy med skreddersydde regler
  Tilpass statisk analyse for å forbedre effektivitet og redusere falske positiver. Bruk spesialtilpassede regler for å finne feil som er spesifikke for organisasjonens kodestandarder eller spesiell mellomvare. Skru av tester som ikke er relevante. Den samme gruppen som tilbyr verktøymentoring vil sannsynligvis lede tilpasningen. Skreddersydde regler kan eksplisitt knyttes til korrekt bruk av teknologistakker  (positiv korrelasjon), og unngåelse av feil som ellers ofte oppdages i virksomhetens kodebase (negativ korrelasjon).

CR Nivå 3: Bygg en automatisert kodegjennomgangsfabrikk med skreddersydde regler.

SSG må bygge opp en evne til å finne og luke ut spesifikke feil i hele kodebasen.

• CR3.2: Bygg en fabrikk
  Kombiner evalueringsresultater slik at resultater fra flere analyseteknikker mates inn i en enhetlig rapportertings- og forbedringsprosess. SSG kan f.eks. skrive kommandofiler som kaller flere deteksjonsprogrammer automatisk, og kombinerer resultatene til et format som kan konsumeres av en enkelt nedstrøms gjennomgang og rapporteringsløsning, Analysemotorer kan kombinere statisk og dynamisk analyse. Den kinkige biten av denne aktiviteten er å normalisere sårbarhetsinformasjon fra forskjellige kilder som bruker forskjellig terminologi. I noen tilfeller kan en CWE-lik tilnærming bidra med nomenklatur. Kombinasjon av flere kilder kan bidra til bedre informasjonsgrunnlag for risikohåndteringsavgjørelser.
• CR3.3: Bygg en evne til å utrydde spesifikke feil fra hele kodebasen
  Når en ny type feil oppdages skriver SSG regler for å finne den, og bruker reglene til å identifisere alle tilfeller av den nyoppdagede feilen i hele kodebasen. Det er mulig å utrydde feilen fullstendig uten å vente på at hvert prosjekt skal nå kodegjennomgangsfasen i livssyklusen. En virksomhet med kun en håndfull programvareapplikasjoner vil kunne håndtere denne aktiviteten enklere enn virksomheter som utvikler et stort antall applikasjoner.
• CR3.4: Automatiser deteksjon av ondartet kode
  Automatisert kodegjennomgang brukes for å identifisere farlig kode som er skrevet av ondsinnede interne utviklere eller konsulenter. Eksempler på ondartet kode som man kan se etter inkluderer: bakdører, logiske bomber, tidsinstilte bomber, skjulte kommunikasjonskanaler, obfuskert programlogikk og dynamisk kodeinjeksjon. Selv om automatiserte verktøy med “fabrikkinnstillinger” kan finne noen generelle konstruksjoner som ser ondartede ut, vil det fort bli nødvendig med skreddersydde regler for statiske analyseverktøy for å kodifisere godkjente og uakseptable kodemønstre i virksomhetens kodebase. Manuell kodegjennomgang for ondartet kode er en god start, men er ikke tilstrekkelig for å gjennomføre denne aktiviteten.

Illustrasjon ved Fraser Speirs, CC-BY-2.0