Sikkerhetsanalyse av kode og løsninger

De fleste sikkerhetshull oppstår ikke fordi noen gjorde en dårlig jobb den gangen løsningen ble bygget. De oppstår fordi tiden går. Et bibliotek som var trygt for tre år siden, har fått en kjent sårbarhet. En innloggingsside som tidligere sto i fred, får nå automatiserte påloggingsforsøk hver uke. Plattformen løsningen kjører på, nærmer seg slutten av levetiden sin.

Samtidig er angrepene i stor grad automatiserte. Botnett leter kontinuerlig etter kjente svakheter, og de skiller ikke mellom store og små virksomheter. En liten fagløsning med femti brukere blir skannet på samme måte som en nettbank.

Gjennomgang av løsninger vi har levert

Vi mener ansvaret for en løsning ikke slutter den dagen den settes i produksjon. Derfor går vi systematisk gjennom løsningene vi har levert – uavhengig av hvor lenge siden det er, og av om vi har en løpende avtale i dag.

Vi leser koden, ser etter kjente svakheter, og gir en konkret og prioritert oversikt over hva som bør gjøres. Det du får er en vurdering og en anbefaling – ikke en salgspresentasjon. Gjennomgangen er uten kostnad og helt uforpliktende, og mindre ting retter vi opp uten kostnad. Krever noe et større arbeid, legger vi fram et tilbud før vi gjør noe som helst.

Overflateanalyse – for alle andre

Gjennomgangen over forutsetter at vi har koden og kjenner løsningen. Men problemet er det samme uansett hvem som har bygget systemet, og de færreste har et oppdatert bilde av hvordan det står til.

Derfor tilbyr vi en overflateanalyse til alle som ønsker det. Da ser vi på løsningen slik den fremstår utenfra, uten tilgang til koden. En overflateanalyse fanger ikke alt, men den fanger overraskende mye:

• om security headers er på plass
• om innloggingen er eksponert for automatiserte påloggingsforsøk
• om løsningen røper komponenter og versjoner med kjente sårbarheter
• om plattformen den kjører på, fortsatt får sikkerhetsoppdateringer

Du får en kort og konkret oppsummering av det vi ser. Den er uten kostnad og uforpliktende.

Dette ser vi etter

• Bot-beskyttelse på innlogging. Automatiserte påloggingsforsøk kan stoppes effektivt, uten at det går ut over vanlige brukere.
• Security headers. Innstillinger som forteller nettleseren hvordan den skal beskytte brukerne mot vanlige nettangrep. De er raske å sette opp – og mangler overraskende ofte.
• Komponenter med kjente sårbarheter. Rammeverk og biblioteker som bør oppdateres fordi svakheter er blitt offentlig kjent etter at løsningen ble bygget.
• Innlogging og tilgangsstyring. Hvordan brukere autentiseres, hvordan roller og rettigheter håndheves, og om noen har mer tilgang enn de trenger.
• Plattform og levetid. Om løsningen fortsatt får sikkerhetsoppdateringer – eller om den bør flyttes til noe nyere.

AI skanner, mennesker vurderer

Vi bruker de nyeste AI-modellene til å gå gjennom kodebasen. En AI leser gjennom hele kodebasen langt raskere enn et menneske rekker, og fanger opp mønstre som er lette å overse når man leter manuelt.

Men en skanning er ikke en vurdering. Funn må settes i sammenheng: hva betyr dette i akkurat denne løsningen, hvem har tilgang, hva er realistisk å utnytte, og hva bør prioriteres først? Den vurderingen gjør utviklerne våre – de samme som kjenner løsningen. Agenten gjør forarbeidet, mennesket har siste ord.

Løpende analyse i utviklingsprosessen

For utviklingsteam som vil ha sikkerhetsanalyse som en fast del av arbeidsflyten, setter vi opp automatisert analyse i byggeprosessen. Da fanges sårbarheter opp tidlig, med tilbakemelding direkte til utviklerne i stedet for i en rapport i etterkant. Det bidrar samtidig til etterlevelse av ISO 27001.

Vi mener en leverandør bør kunne svare på hva som står i koden de skrev for fem år siden – og gjøre noe med det. Ta kontakt hvis du vil ha en overflateanalyse, eller rett og slett vil vite hvordan det står til med løsningen du har i dag.