Proaktiv sikring: slik leter vi etter svakheter i løsningen din

Jeg skrev for noen uker siden om hvordan vi håndterte PHP2Shell. Uken etter kom et nytt kritisk varsel, denne gangen for nettbutikker på Drupal Commerce. Slike varsler krever rask handling. Men hvordan finner vi svakhetene som ennå ikke er kjent? Det har vi arbeidet med siden tidlig i 2026. Nå tilbyr vi Proaktiv sikring til kundene våre. Testingen kjører på Frontkoms egen maskinvare.

Hvorfor vi begynte

Når det kommer et sikkerhetsvarsel, må vi undersøke om løsningene vi forvalter er berørt, og rette der det er nødvendig. Det er en viktig del av forvaltningen.

Varslene gjelder gjerne komponenter som brukes av mange. De forteller oss mindre om koden som er skrevet spesielt for én løsning, integrasjonene mot andre systemer og hvordan alt er satt opp. Svakheter her må vi lete etter selv.

KI gjør det mulig å undersøke løsninger raskere og mer systematisk. Det gir oss nye verktøy i sikkerhetsarbeidet, samtidig som vi må regne med at angripere bruker de samme mulighetene.

Vi ønsket derfor å finne en måte å teste oftere på, med tydelige rammer for hva testene får gjøre.

Hva Proaktiv sikring gjør

Testen kombinerer en systematisk gjennomgang med utforskende testing.

I den systematiske delen bruker agentene sikkerhetskrav fra OWASP ASVS 5.0 nivå 1 og 2 og testmetoder fra OWASP WSTG 4.2. ASVS beskriver krav til sikkerhet i applikasjoner, mens WSTG gir veiledning i hvordan sikkerheten kan testes. Agentene sjekker også teknologi og versjoner mot aktuelle varsler fra NSM og CISA.

Rapporten viser hvilke krav som er kontrollert, resultatet av kontrollene og hva testen ikke dekker.

Testen kan gjennomføres med ulik tilgang:

• Uten innlogging (black box) undersøker agentene det som er tilgjengelig fra internett.
• Med innlogging (grey box) undersøker de også hva brukere med ulike roller har tilgang til, og om tilgangsbegrensningene fungerer.
• Med tilgang til kildekoden (white box) kan de i tillegg undersøke hvordan løsningen er bygget, og bruke dette til å målrette testingen.

Tilgangen og omfanget avtales før testen starter.

I den utforskende delen følger agentene spor etter mulige svakheter. De kobler observasjoner og undersøker videre der noe ser sårbart ut. Her leter de også etter feil i funksjoner og integrasjoner som er bygget spesielt for løsningen. Det er her testen skiller seg mest fra en sårbarhetsskanner, som leter etter kjente svakheter i felles komponenter.

Kunden får en overordnet rapport med funn, alvorlighetsgrad og anbefalte tiltak, sammen med en detaljert oversikt over testdekningen. Funnene beskrives slik at en utvikler eller en agent som bruker KI, kan bruke dem som grunnlag for retting.

Etter at feilene er rettet, kan vi teste på nytt for å kontrollere om tiltakene har løst problemet.

Fokus på trygghet

Sikkerhetstesting kan påvirke løsningen som testes. Mye av utviklingsarbeidet har derfor handlet om å begrense risikoen, særlig ved testing i produksjon.

Språkmodellene kjører på Frontkoms egen maskinvare. Informasjon om svakheter i kundenes løsninger deles ikke med noen KI-leverandør.

Hver test kjører i et isolert miljø med sin egen brannmur, som bare slipper trafikk til adressene kunden har godkjent. Avgrensningen er dermed håndhevet utenfor agentenes egne instrukser, og agentene kan ikke slå sperrene av.

Standardtesten er lagt opp til å unngå endringer i kundedata, og passordgjetting inngår ikke. Hvis løsningen viser tegn på belastning, reduserer testen aktiviteten.

Omfanget avtales før vi starter, slik at kunden vet hvilke deler av løsningen som skal undersøkes.

Testing med innlogging bør gjøres mot et testmiljø. Platops, et internt team i Frontkom, følger testen og kan stoppe den.

Vi testet oss selv først

Før vi tilbød tjenesten til andre, testet vi våre egne løsninger, blant annet frontkom.com. Vi testet også løsninger vi forvalter for kunder.

Testene fant svakheter som vi rettet. På frontkom.com holdt ikke den første rettingen. Det oppdaget vi da vi testet på nytt.

Det er en konkret erfaring vi tar med oss videre:

En retting må også kontrolleres.

Derfor tilbyr vi retest som en del av oppfølgingen.

Testene våre har avdekket alvorlige svakheter, både i våre egne løsninger og i løsninger vi forvalter. Det gir oss en konkret grunn til å teste jevnlig, også når det ikke foreligger noe sikkerhetsvarsel.

Tilgjengelig nå

Proaktiv sikring passer før en ny løsning går i produksjon, som en fast del av forvaltningen, og når et varsel gjør at dere vil vite om dere er berørt. Den erstatter ikke oppdateringer, og heller ikke en manuell sikkerhetstest der det kreves. Testen utføres av Platops, som gir funnene direkte til teamet som forvalter løsningen. Det er ingen tredjepart å koble på og ingen overleveringer å fasilitere. Når vi tester løsninger vi selv har laget, er det kvalitetssikring og ikke en uavhengig test. Det står i rapporten.

Vil dere vite hvordan det står til med løsningen deres, ta kontakt på erlend@frontkom.com.

Åpenhetsmerknad: Artikkelen bygger på forfatterens egne erfaringer og vurderinger. KI er brukt som redaksjonelt hjelpemiddel for struktur og språk. Forfatteren har kontrollert innholdet og står ansvarlig for det.