Automatisert sikkerhetsscanning: slik finner vi sårbarhetene før angriperne

Hvorfor automatisert scanning er blitt en nødvendighet

De fleste vellykkede angrep utnytter kjente sårbarheter som allerede har en tilgjengelig patch. Problemet er sjelden at patchen ikke finnes — det er at ingen har oppdaget at den trengs. Mellom offentlig disclosure og faktisk utnyttelse kan det gå så lite som timer. Manuell gjennomgang holder rett og slett ikke tritt.

For oss ble det tidlig klart at vi trengte et system som jobber døgnet rundt — ikke bare når noen husker å sjekke. Vi bygget derfor en automatisert skanningspipeline som dekker alt fra egenutviklede SaaS-plattformer til WordPress- og WooCommerce-installasjoner.

Hva vi skanner og hvorfor

Vi deler skanningen i tre hovedkategorier, tilpasset ulike risikoprofiler og teknologistacker.

SaaS-plattformer og egenutviklet programvare

For kunders SaaS-løsninger og skreddersydde systemer kjører vi flere lag med skanning:

• Dynamisk applikasjonsskanning (DAST) — vi crawler hele applikasjonen automatisk, inkludert autentiserte områder bak innlogging, og tester hvert endepunkt for OWASP Top 10-sårbarheter: SQL injection, XSS, SSRF, broken access control, insecure deserialization og mer. Skanneren sender faktiske forespørsler mot applikasjonen og analyserer responsene — det er den mest realistiske måten å teste på, fordi den oppfører seg som en angriper ville gjort
• Out-of-band deteksjon (OOB) — noen sårbarheter gir ikke synlig respons i applikasjonen. Vi bruker OOB-teknikker der skanneren injiserer payloads som ringer hjem til en ekstern lyttetjeneste hvis de utløses. Det fanger opp blind SQL injection, blind SSRF og andre sårbarheter som tradisjonelle skannere overser
• Avhengighetsscanning av hele dependency-treet — ikke bare direkte pakker, men også transitive avhengigheter flere nivåer ned
• Containerskanning av Docker-images for kjente CVE-er i basesystem og biblioteker
• Infrastrukturanalyse av sky-konfigurasjoner — åpne porter, feilkonfigurerte tilganger, manglende kryptering
• Statisk kodeanalyse (SAST) som fanger opp vanlige sikkerhetsfeil i kildekoden før den i det hele tatt kjøres

DAST-skanningene er spesielt verdifulle fordi de tester applikasjonen i et reelt kjøremiljø. De finner problemer som statisk analyse aldri kan se — som feilkonfigurerte headere, manglende CSRF-beskyttelse, informasjonslekkasje i feilmeldinger og svakheter i sesjons­håndtering.

Alt dette kjører som del av CI/CD-pipelinen og på faste intervaller mot produksjonslignende miljøer. Hver pull request utløser automatisk en sikkerhetskontroll. Ingenting når produksjon uten at det er skannet.

WordPress og WooCommerce

WordPress driver en stor andel av norske nettsider, og WooCommerce er den vanligste nettbutikkplattformen. Begge har et enormt plugin-økosystem — som også er den største angrepsflaten.

Her kombinerer vi to tilnærminger:

Komponentbasert skanning:

• Kjerne, temaer og plugins mot kjente sårbarhetsdatabaser
• Utdaterte komponenter som ikke lenger vedlikeholdes av utvikleren
• Konfigurasjonsfeil som eksponerte debug-filer, åpne XML-RPC-endepunkter, directory listing og svake filrettigheter
• Brukerkontoer og tilgangskontroll for å fange opp kontoer med svake passord eller unødvendige administratorrettigheter

Dynamisk testing av hele nettstedet:

• Automatisert crawling av alle sider og skjemaer — inkludert WooCommerce-checkout, Min Konto-sider og admin-panelet
• Testing av inputfelter for injeksjonsangrep, XSS og filinkludering
• Analyse av HTTP-headere for manglende sikkerhetsdirektiver (CSP, HSTS, X-Frame-Options)
• Deteksjon av informasjonslekkasje gjennom feilmeldinger, versjons­numre i HTML-kildekoden og eksponerte API-endepunkter

Denne kombinasjonen fanger opp både kjente sårbarheter i tredjepartskode og ukjente svakheter i selve implementasjonen — noe som er spesielt viktig for WooCommerce-butikker med skreddersydde temaer og egenutviklede plugins.

WordPress-skanningene kjører på fast intervall uavhengig av deploy, fordi plugins ofte oppdateres utenfor vår kontroll.

Nettverks- og overflateanalyse

I tillegg til applikasjonsnivået kjører vi regelmessige eksterne skanninger som ser infrastrukturen fra utsiden — slik en angriper ville gjort det:

• Portskanning og tjeneste-fingerprinting for å oppdage uventede eksponerte tjenester
• TLS/SSL-validering for å sikre at sertifikater er gyldige, sterke og korrekt konfigurert
• DNS-kontroll for å fange opp dangling records, subdomain takeover-risiko og manglende SPF/DKIM/DMARC

Dybden i skanningen: ikke bare overflaten

Mange sikkerhetsverktøy tester bare det som er synlig uten innlogging. Det gir et ufullstendig bilde. Våre skanninger går betydelig dypere:

Autentisert skanning. Vi konfigurerer skanneren til å logge inn med gyldige testkontoer og teste alt bak innlogging — dashboards, innstillinger, brukeradministrasjon, betalingsflyter. Det er bak innlogging de mest verdifulle dataene befinner seg, og det er der broken access control og privilege escalation gjemmer seg.

Full JavaScript-rendering. Moderne SaaS-applikasjoner og WooCommerce-temaer laster mye innhold dynamisk via JavaScript. Skanneren vår renderer JavaScript fullstendig, slik at den oppdager endepunkter, skjemaer og API-kall som en enkel HTTP-crawler aldri ville sett.

REST- og GraphQL-API-testing. For SaaS-plattformer med API-grensesnitt importerer vi API-definisjoner (OpenAPI/Swagger) og tester hvert endepunkt systematisk — med gyldige og ugyldige parametere, feilaktige datatyper, overflødige felter og manglende autorisasjon.

Compliance-mapping. Funn mappes automatisk mot relevante standarder — OWASP Top 10, PCI DSS, ISO 27001 og GDPR-relaterte kontroller. Det gjør det enklere for kunder som trenger dokumentasjon mot spesifikke rammeverk.

Slik fungerer skanningspipeline i praksis

Hele flyten er designet for å gå fra deteksjon til handling med minst mulig forsinkelse.

Steg 1 — Automatisert skanning. Skanningene kjører etter fast tidsplan og ved hver kodeendring. Resultater normaliseres til et felles format uavhengig av hvilken skanner som fant funnet.

Steg 2 — Klassifisering og prioritering. Hvert funn scores basert på alvorlighetsgrad (CVSS), eksponeringsgrad og om det finnes kjent utnyttelse i felt. Kritiske funn med aktiv exploit får umiddelbar prioritet.

Steg 3 — Rapportgenerering. Vi genererer en strukturert rapport som inneholder:

• Oversikt over alle funn, sortert etter alvorlighetsgrad
• Teknisk beskrivelse av hver sårbarhet
• Konkret anbefaling for utbedring — ikke bare «oppdater pakken», men hvilken versjon, hva som endres og eventuelle breaking changes å være oppmerksom på
• Historisk trend som viser om sikkerhetsposisjonen forbedres eller forverres over tid

Steg 4 — Varsling og oppfølging. Kritiske funn utløser varsler umiddelbart. Rapporten leveres til kundens team med tydelig handlingsliste. For kunder med driftsavtale håndterer vi utbedringen direkte.

Rapportene: konkrete tiltak, ikke generiske advarsler

Vi har sett mange sikkerhetsrapporter som lister opp hundrevis av funn uten å hjelpe mottakeren med å prioritere. Det er verdiløst for en travel utvikler eller daglig leder.

Våre rapporter er bygget rundt tre prinsipper:

1. Handlingsrettet. Hvert funn har en konkret anbefaling. Ikke «vurder å oppdatere», men «oppdater next fra 14.1.3 til 14.1.4 — lukker CVE-2025-XXXXX, ingen breaking changes i denne patchversjonen».

2. Prioritert. Funnene er rangert etter faktisk risiko, ikke bare CVSS-score. En sårbarhet med CVSS 7.0 som er eksponert mot internett og har kjent exploit, prioriteres over en CVSS 9.0 som bare er tilgjengelig fra internt nettverk.

3. Forståelig. Tekniske detaljer er tilgjengelige for utviklere, men sammendraget er skrevet slik at en CTO eller daglig leder kan forstå hva som haster og hva som kan vente.

Eksempler fra virkeligheten

Utdatert plugin oppdaget i WooCommerce-butikk

En av våre kunder kjørte en populær betalingsplugin som ikke hadde blitt oppdatert på fem måneder. Vår skanning identifiserte at versjonen var rammet av en kjent SQL injection-sårbarhet. Rapporten inneholdt spesifikk oppdateringsinstruksjon og en anbefaling om å sjekke databaselogger for tegn på utnyttelse. Kunden oppdaterte samme dag — tre uker før vi registrerte de første automatiserte skanneforsøkene mot den sårbarheten.

Eksponert staging-miljø for SaaS-plattform

Overflateskanningen vår fanget opp et staging-miljø som var tilgjengelig på et offentlig subdomene uten autentisering. Miljøet inneholdt testdata som inkluderte reelle e-postadresser. Funnet ble klassifisert som kritisk, kunden ble varslet umiddelbart, og miljøet ble sikret innen timen.

Transitive sårbarhet i Node.js-avhengighet

Avhengighetsskanningen avdekket en kritisk sårbarhet fire nivåer ned i dependency-treet — i en pakke som ingen i utviklerteamet visste at de brukte. Rapporten viste hele avhengighetskjeden og hvilken toppnivå-pakke som måtte oppdateres for å løse problemet.

Skanningsfrekvens: hvor ofte er nok?

Riktig frekvens avhenger av risikoprofil og endringstakt:

Plattform	Anbefalt frekvens	Begrunnelse
SaaS med aktiv utvikling	Ved hver PR + daglig fullskanning	Kodeendringer introduserer ny risiko kontinuerlig
WordPress/WooCommerce	Daglig	Plugins oppdateres utenfor egen kontroll
Infrastruktur og nettverk	Ukentlig + ved endringer	Konfigurasjonsendringer skjer sjeldnere
Ekstern overflateanalyse	Ukentlig	Fanger opp DNS-endringer og nye eksponeringer

For kunder med driftsavtale kjører alt dette automatisk. For andre leverer vi skanningsrapporter på avtalt intervall.

Hva dette betyr for deg

Automatisert sikkerhetsscanning erstatter ikke gode utviklingspraksiser — men det fanger opp det som faller mellom stolene. Og i et trusselbilde der tiden mellom disclosure og utnyttelse stadig krymper, er det forskjellen mellom å fikse en sårbarhet proaktivt og å oppdage den i en hendelseslogg etter at skaden er skjedd.

Resultatet er enklere compliance, færre overraskelser og en dokumentert sikkerhetsposisjon som tåler revisjon.