Pentestrapport

Scanning og pentest i samme spørgsmål: hold dem adskilt i svaret

Scanning og pentest i samme spørgsmål: hold dem adskilt i svaret

Et spørgsmål som “Udfører I sårbarhedsscanning eller penetrationstest af jeres løsning?” ser venligt ud, fordi det åbner for at svare ja på baggrund af det ene af de to. Et ærligt svar hviler på, at I beskriver hver aktivitet for sig: hvad der bliver gjort, hvor ofte, og hvad det dækker. Så kan kunden selv vurdere, om kravet er opfyldt.

Svaret på titlens spørgsmål er altså: svar på begge dele hver for sig, også når spørgsmålet slår dem sammen. Forskellen mellem de to aktiviteter er forklaret for køberen på penetrationtest.dk. Her handler det om, hvordan I formulerer svaret som leverandør.

Hvorfor kunderne blander de to

Mange skemaer er skrevet af personer, der skal dække mange typer leverandører. Formuleringen “scanning eller test” kan være bevidst, fordi kunden accepterer begge dele for mindre kritiske leverandører. Den kan også være en upræcis formulering af et krav, der i virkeligheden handler om en manuel test.

I kan sjældent vide, hvilken af de to der er tilfældet. Derfor er det tryggest at svare, så kunden kan læse præcist, hvad I gør. Hvis kunden faktisk forventede en pentest, opdager kunden det i jeres svar og ikke først, når rapporten bliver bedt om.

Hvad der adskiller dem i et svar

I et skema behøver I ikke forklare forskellen i detaljer. Det er nok at beskrive hver aktivitet med de oplysninger, kunden har brug for:

  • Hvem udfører den · et automatisk værktøj, jeres eget team eller en ekstern tester.
  • Hvor ofte · løbende, ved hver udrulning, månedligt eller med faste mellemrum.
  • Hvad den dækker · produktets offentlige adresser, kode, afhængigheder eller hele applikationen med login.
  • Hvad den giver · en liste over kendte svagheder eller en vurdering af, hvad en angriber kan opnå.
  • Hvad I kan vise · en rapport, en erklæring eller en intern oversigt.

UK’s National Cyber Security Centre beskriver i sin vejledning penetrationstest som en måde at efterprøve, at organisationens egen håndtering af sårbarheder virker, og ikke som den primære måde at finde sårbarheder på. Den tanke kan bruges direkte i svaret: scanningen er en del af den løbende håndtering, og pentesten er en uafhængig kontrol af, om håndteringen holder. → Pipelinen og den manuelle pentest

Et svar, der holder dem adskilt

Spørgsmålet lyder: “Foretages der regelmæssig sårbarhedsscanning eller penetrationstest af løsningen?” Et svar, der holder tingene adskilt, kan se sådan ud:

“Ja, begge dele. Afhængigheder og kode scannes automatisk ved hver udrulning, og produktets offentlige adresser scannes ugentligt. Fund følges op i udviklingsteamets backlog. Desuden udføres en manuel penetrationstest af applikationen af en ekstern tester én gang om året, senest i juni. Erklæring fra testeren kan udleveres.”

Tallene i eksemplet er tænkte. Det vigtige er, at kunden kan se to aktiviteter med hver deres hyppighed og dokumentation. Hvis I kun scanner, så sig det, og svar nej eller delvist til pentest-delen. → Ja, nej eller delvist

Når I kun har den ene

Har I en scanning, men ingen pentest, er fristelsen stor at svare ja på et spørgsmål, der nævner begge. Det kan være formelt korrekt, men kunden kan senere bede om en pentestrapport, og så står svaret svagt. Skriv hellere, hvad I gør, og om en test er planlagt. → Et ærligt svar uden test

Har I en pentest, men ingen løbende scanning, er det også værd at sige det. En pentest ser på produktet på ét tidspunkt. NCSC påpeger, at en test kun kan bekræfte forholdene på den dag, testen blev udført. Kunden kan derfor spørge, hvad I gør i perioden mellem to test, og hvordan I opdager nye sårbarheder i de komponenter, produktet bygger på, og det spørgsmål er bedre at have et svar på, før det bliver stillet. → Hvor ofte tester I?

Hvem skal skrive svaret

Spørgsmålet ser enkelt ud, og derfor lander det tit hos den, der udfylder resten af skemaet. Men de oplysninger, svaret bygger på, ligger forskellige steder. Scanningen ejes typisk af udviklingsteamet eller driften, som kender værktøjerne og ved, hvor ofte de kører. Pentesten ejes af den, der har bestilt den og har rapporten. Lad begge parter læse svaret, før det sendes, så hyppigheder og omfang passer med virkeligheden.

Det er også her, uoverensstemmelser plejer at dukke op. Udviklerne kan have slået en ugentlig scanning fra for et halvt år siden, fordi den gav for mange falske fund, uden at nogen har rettet svarbiblioteket. Eller pentesten kan have dækket en ældre version af produktet end den, sælgeren tror. En kort gennemgang med de to ejere fanger den slags, før kunden gør det.

Ord, der skaber forvirring

Nogle ord bliver brugt forskelligt af leverandører, kunder og testere. Vær opmærksom på dem i jeres svar:

  • Sikkerhedstest · kan betyde både scanning og manuel test. Brug det ikke alene.
  • Automatisk pentest · bruges om værktøjer, men nogle kunder vil ikke regne det som en pentest. Beskriv, hvad værktøjet gør, i stedet for at kalde det en test.
  • Løbende test · kan lyde som manuel test hele året. Hvis det er scanning, så skriv scanning.
  • Ekstern scanning · kan betyde scanning udefra eller scanning udført af en ekstern part. Skriv, hvilken af de to I mener.

Brug de samme ord i alle skemaer, og læg formuleringerne i jeres svarbibliotek, så sælgere og udviklere ikke beskriver aktiviteterne forskelligt. → Et svarbibliotek

Det skal I lade være med

  • Svare ja til begge, når I kun har den ene · Kunden læser ja som dækkende for hele spørgsmålet.
  • Kalde en scanningsrapport for en pentestrapport · Kundens sikkerhedsfolk ser forskellen med det samme.
  • Udelade hyppigheden · Uden den kan kunden ikke vurdere, om aktiviteten er regelmæssig.
  • Glemme hvad scanningen dækker · En scanning af hjemmesiden er ikke en scanning af produktet.
  • Bruge vage ord som sikkerhedstest · De skaber spørgsmål i stedet for at besvare dem.

Hvad kan og ikke kan konkluderes

Et svar, der beskriver scanning og pentest hver for sig, viser kunden, hvilke kontroller I har, og hvor ofte de bruges. Det siger ikke, om kontrollerne er tilstrækkelige for netop denne kunde; det afgør kunden ud fra sin egen vurdering. En scanning kan ikke dokumentere det samme som en pentest, og en pentest kan ikke dokumentere den løbende opfølgning mellem to test.

Tjekliste til spørgsmålet

  • ☐ Er scanning og pentest beskrevet hver for sig?
  • ☐ Står hyppigheden ved hver aktivitet?
  • ☐ Er det klart, hvad hver aktivitet dækker?
  • ☐ Er det angivet, hvad I kan udlevere for hver?
  • ☐ Er svaret nej eller delvist for den del, I ikke har?
  • ☐ Er ordvalget det samme som i jeres andre skemaer?

Kilder

  • NCSC (UK): Penetration testing: penetrationstest som efterprøvning af den egen håndtering af sårbarheder, ikke som primær måde at finde dem på; en test kan kun bekræfte forholdene på testdagen.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om pentestrapporten

Læs også: Ekstern sikkerhedsrating af jeres domæner · Kunden accepterer ikke jeres egen interne test

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Kræver kunden en pentestrapport?

Skriv kort, hvilket krav kunden har stillet, og hvornår dokumentationen skal ligge klar. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.