Vulnerability Disclosure Policy: 12 Steg mot CERT-SE [2026]

En etisk hackare hittar en allvarlig brist i ert kundportal en fredag kväll. Hen vill rapportera den, men hittar ingen säkerhetsadress, ingen policy och inget svar inom rimlig tid. Resultatet blir antingen tystnad, ett offentligt Twitter-inlägg, eller i värsta fall att bristen säljs vidare. Det scenariot går att undvika med en publicerad vulnerability disclosure policy (VDP), en security.txt-fil enligt RFC 9116 och en tydlig koppling till CERT-SE, Sveriges nationella CSIRT. I den här guiden bygger du hela kedjan från policy till triage-skript i tolv steg, med kodexempel du kan använda direkt.

Sedan cybersäkerhetslagen trädde i kraft den 15 januari 2026 har fler svenska organisationer också fått formella skyldigheter kring incidenthantering, vilket gör gränsdragningen mellan en inkommen sårbarhetsrapport och en rapporteringspliktig incident viktigare än tidigare. Den här artikeln visar hur du bygger processen så att båda spåren hanteras korrekt.

Guiden riktar sig till säkerhetsansvariga, IT-chefer och utvecklare som antingen ska bygga sin första disclosure-process eller modernisera en gammal säkerhetssida som bara innehåller ett kontaktformulär. Du behöver inga specialverktyg för att följa den, bara skrivbehörighet till er webbplats, ett terminalfönster och en vilja att faktiskt svara när rapporterna börjar komma in.

Vad är en vulnerability disclosure policy och varför behöver ni en?

En vulnerability disclosure policy är ett dokument som beskriver hur externa säkerhetsforskare får testa era system, vad som räknas som godkänd testning, och hur ni tar emot och hanterar rapporter. Den skiljer sig från ett bug bounty-program genom att den inte nödvändigtvis innebär betalning, utan snarare ett löfte om att inte vidta rättsliga åtgärder mot forskare som agerar i god tro (så kallad safe harbor). Många organisationer startar med en VDP och lägger till ersättning senare, om alls.

Termen sårbarhetsrapportering (vulnerability disclosure) skiljer sig också från incidentrapportering. Den förra handlar om att ta emot information om en brist innan den utnyttjats, den senare handlar om att anmäla en faktisk händelse till en tillsynsmyndighet. En väl fungerande VDP minskar antalet incidenter genom att fånga upp brister tidigt, men den ersätter inte skyldigheten att anmäla en incident om en sårbarhet redan hunnit utnyttjas innan den rapporterades.

Skillnaden mellan de tre vanligaste modellerna sammanfattas nedan.

Egenskap	Vulnerability Disclosure Policy (VDP)	Bug bounty-program	Koordinerad disclosure via CERT-SE
Ersättning till forskare	Vanligtvis ingen	Ja, per fynd	Ingen, CERT-SE agerar mellanhand
Vem driver processen	Organisationen själv	Organisationen eller en plattform	CERT-SE koordinerar mellan parter
Passar bäst för	De flesta organisationer som vill börja	Mogna säkerhetsteam med budget	Fall där leverantör saknar egen kanal
Juridiskt behov	Safe harbor-text i policyn	Avtal med plattform/forskare	Följer CERT-SE:s RFC 2350-ramverk
Teknisk startpunkt	security.txt + policy	security.txt + plattformskonto	Kontakt via [email protected]

För de flesta svenska små och medelstora företag är en publicerad VDP den mest realistiska startpunkten. Den kräver varken budget för utbetalningar eller ett upphandlat plattformsavtal, bara en tydlig text, en teknisk ingång och ett internt triage-flöde.

Värdet sträcker sig längre än att bara ta emot rapporter artigt. En publicerad policy fungerar som ett filter, den styr forskare mot rätt kanal i stället för att de gissar sig fram via en supportinkorg eller ett allmänt kontaktformulär som aldrig läses av någon med säkerhetsmandat. Utan den kanalen hamnar allvarliga fynd ofta hos personer som varken kan bedöma tekniskt allvar eller agera snabbt, vilket förlänger tiden en sårbarhet står öppen. Det är precis den typen av glapp som cybersäkerhetslagen försöker minska genom att kräva strukturerad hantering av både sårbarheter och incidenter hos berörda verksamheter.

Förutsättningar innan du börjar

Du behöver inte mycket infrastruktur för att komma igång, men följande bör finnas på plats innan du påbörjar steg 1. Räkna med att grundarbetet, från första utkast till publicerad security.txt, tar en till två veckors deltid för ett litet team, mest beroende på hur snabbt juridik hinner godkänna safe harbor-texten.

• Skrivbehörighet till webbservern eller CDN:n som styr /.well-known/-sökvägen på er huvuddomän
• GnuPG (GPG) version 2.4 eller senare för att generera ett PGP-nyckelpar för krypterad kommunikation
• En dedikerad e-postadress, till exempel [email protected], som faktiskt läses av någon
• Python 3.11+ eller Node.js 22 LTS om ni vill köra triage-skriptet i steg 10
• Ett git-repo eller ett wiki-utrymme för att versionshantera policytexten
• Mandat från ledningen att faktiskt agera på inkomna rapporter, annars blir policyn en tom gest
• Kännedom om vilka system som är kritiska nog att omfattas av cybersäkerhetslagens anmälningsplikt

Punkten om ledningsmandat är lätt att underskatta. En policy som publiceras utan att chefer för de berörda produktteamen känner till den riskerar att bli ett tomt löfte första gången en kritisk rapport landar mitt i en pågående release. Se till att det finns en tydlig eskaleringsväg som går förbi vanlig backlogg-prioritering för kritiska fynd, annars konkurrerar sårbarhetsfixar med vanliga funktionsönskemål om samma utvecklarkapacitet, och förlorar.

Steg 1: Definiera scope och vad som är undantaget

Börja med att lista exakt vilka domäner, applikationer och API:er som omfattas. Var lika tydlig med vad som inte ingår, till exempel tredjepartstjänster ni bara integrerar med, eller miljöer som redan är under aktiv sanering. En vag scope-definition är den vanligaste anledningen till att forskare rapporterar fel saker eller drar sig för att rapportera alls.

Ange också vilka testmetoder som är tillåtna. De flesta VDP:er förbjuder överbelastningstester (DoS), social manipulation mot anställda, och fysiskt intrång, medan de tillåter statisk analys, autentiserad testning med egna testkonton och begränsad automatiserad skanning. Skriv ner detta explicit i stället för att anta att det är underförstått.

Involvera systemägarna tidigt, inte efter att scopet redan är publicerat. Ett vanligt misstag är att säkerhetsteamet skriver scope utifrån vad de själva känner till, medan en avdelning som driver en fristående e-handelsplattform eller ett äldre API aldrig tillfrågas. Resultatet blir antingen att viktiga system saknas i policyn, eller att forskare testar mot system ingen i organisationen längre äger eller känner till detaljerna kring.

Ett praktiskt sätt att bygga listan är att utgå från er befintliga tillgångsinventering eller CMDB, om ni har en, och gå igenom varje extern yta manuellt tillsammans med respektive systemägare. Markera osäkra fall, som system som drivs av en underleverantör men syns på er egen domän, med en separat notering om att de kräver godkännande från tredje part, i stället för att gissa. Publicera hellre ett något snävare scope till att börja med och utöka det senare, än att lova mer än ni kan hantera från start.

VDP och GDPR: hantera personuppgifter i inkomna rapporter

En sårbarhetsrapport innehåller ofta personuppgifter, till exempel skärmdumpar av en dataläcka, testkonton med riktiga namn, eller loggutdrag med IP-adresser. Behandla varje inkommen rapport som om den kan innehålla känsligt material tills motsatsen är bevisad, och begränsa åtkomsten till triage-systemet till de som faktiskt behöver den.

Sätt en tydlig gallringsrutin för rapporter som visar sig vara falska eller irrelevanta, samt en rutin för att radera exempeldata forskaren skickat in som bevis, så snart felet är bekräftat och åtgärdat. Om er organisation är en myndighet gäller dessutom offentlighetsprincipen, vilket innebär att inkomna handlingar i vissa fall kan bli allmänna. Rådgör med er registrator eller juridiska funktion om hur sårbarhetsrapporter ska diarieföras innan ni publicerar policyn, annars riskerar ni att lova konfidentialitet ni juridiskt inte kan hålla.

Ha också en plan för hur ni hanterar rapporter som rör tredje part, till exempel om en forskare av misstag kommer åt en annan kunds data medan de testar er miljö. Den typen av fynd kan i sig utlösa separata anmälningsplikter mot den drabbade kunden, oavsett vad er egen VDP säger, så bygg in en eskaleringspunkt till dataskyddsombudet redan i triage-flödet snarare än att upptäcka behovet efteråt.

Steg 2: Skriv själva policytexten

Policyn bör vara kort nog att läsas på fem minuter men innehålla fem obligatoriska delar: scope, tillåtna testmetoder, rapporteringsformat, förväntad svarstid, och safe harbor-villkoren. Undvik juridisk floskeltext som skrämmer bort forskare, en policy som läses som ett hot mot forskaren i stället för en inbjudan gör mer skada än nytta.

En rimlig svarstid att sätta som mål är bekräftelse inom två arbetsdagar, en första bedömning inom en vecka, och löpande uppdateringar därefter tills ärendet är stängt. Sätt separata mål för allvarliga fynd, en kritisk sårbarhet bör inte vänta i kö bakom lågriskrapporter.

Safe harbor-texten är den del forskare läser först, ofta innan de ens tittar på scopet. Formuleringen behöver vara juridiskt hållbar men samtidigt läsbar för någon som inte är jurist. Ett minimalt exempel att utgå från:

Safe harbor:
Vi kommer inte att inleda juridisk process mot dig om du:
1. Håller dig inom det scope som anges i denna policy
2. Inte avsiktligt förstör data, stör drift eller bryter mot
   sekretess utöver vad som krävs för att bekräfta sårbarheten
3. Rapporterar fyndet till oss innan du offentliggör det
4. Ger oss rimlig tid att åtgärda innan publik disclosure
   (normalt 90 dagar, förlängningsbart efter dialog)

Anpassa tidsramen efter er egen kapacitet, men var konsekvent. En policy som lovar 90 dagar men sedan kräver förlängning på varje enskilt ärende signalerar att organisationen inte är redo för processen.

Steg 3: Bygg en security.txt-fil enligt RFC 9116

RFC 9116 definierar ett maskinläsbart format som gör det möjligt för forskare och automatiserade verktyg att hitta er säkerhetskontakt utan att leta manuellt. Filen ska ligga på den välkända sökvägen /.well-known/security.txt på er HTTPS-domän. Fältet Contact kan upprepas flera gånger, Policy pekar till er fullständiga VDP-text, och Expires talar om när filen senast måste förnyas. Standarden underhålls som en öppen specifikation, och securitytxt.org är en bra referens när ni vill dubbelkolla fältnamn eller se exempel från andra organisationer.

Contact: mailto:[email protected]
Contact: https://erdoman.se/security/report
Policy: https://erdoman.se/security/policy
Encryption: https://erdoman.se/.well-known/pgp-key.txt
Canonical: https://erdoman.se/.well-known/security.txt
Preferred-Languages: sv, en
Expires: 2027-03-31T00:00:00.000Z

Glöm inte Expires-fältet. En förfallen security.txt signalerar till både forskare och automatiska skannrar att filen inte underhålls, vilket sänker förtroendet lika mycket som att inte ha någon fil alls. Sätt ett kalenderpåminnelse minst 30 dagar innan datumet passeras.

Steg 4: Publicera och validera filen

När filen är publicerad, verifiera att den serveras med rätt content-type och utan omdirigeringar som bryter sökvägen. Kör följande från en terminal för att bekräfta att allt fungerar som väntat.

curl -sI https://erdoman.se/.well-known/security.txt | grep -i "content-type\|HTTP"
curl -s https://erdoman.se/.well-known/security.txt

# Förväntat resultat:
# HTTP/2 200
# content-type: text/plain; charset=utf-8
# Contact: mailto:[email protected]
# ...

Om domänen har flera subdomäner räcker det oftast att publicera filen på huvuddomänen, men RFC 9116 tillåter även att varje subdomän pekar tillbaka till en central fil via Canonical. Testa alltid från en extern nätverksanslutning, en fil som bara syns internt hjälper ingen extern forskare. Ett vanligt driftsmisstag är att CDN:n cachar filen aggressivt, vilket gör att en uppdatering av Expires-fältet inte syns förrän cachen tömts manuellt, så lägg gärna en kort cache-tid specifikt för den här sökvägen.

Steg 5: Sätt upp PGP-kryptering för känsliga rapporter

Vissa rapporter innehåller exploateringskod eller åtkomstuppgifter som inte bör skickas i klartext. Generera ett dedikerat nyckelpar för säkerhetsteamet, inte en enskild anställds privata nyckel, så att processen överlever personalbyten.

gpg --full-generate-key
# Välj RSA och RSA, 4096 bitar, giltighetstid 2 år
# Ange [email protected] som e-postadress

gpg --armor --export [email protected] > pgp-key.txt
gpg --list-keys [email protected]

Publicera den publika nyckeln på samma sökväg som ni angav i Encryption-fältet i security.txt. Den privata nyckeln ska ligga i en lösenordshanterare eller HSM, aldrig i samma git-repo som resten av dokumentationen. Rotera nyckeln innan giltighetstiden löper ut, och behåll den gamla publika nyckeln en tid efter bytet så att redan pågående krypterad kommunikation med forskare som ännu inte sett den nya nyckeln fortfarande går att läsa.

Steg 6: Bygg ett triage-flöde med CVSS-bedömning

När en rapport kommer in behöver ni ett sätt att snabbt avgöra allvarlighetsgrad. Den aktuella standarden är CVSS 4.0 från FIRST.org, som ersätter version 3.1 med bättre stöd för miljöspecifika och hotbaserade faktorer. Poängen översätts till fyra grovkorniga nivåer som styr hur snabbt ni behöver agera.

CVSS 4.0-poäng	Allvarlighetsnivå	Rekommenderad åtgärdstid	Exempel
0,1–3,9	Låg	Nästa ordinarie release	Informationsläcka utan praktisk påverkan
4,0–6,9	Medel	Inom 90 dagar	Begränsad autentiserad XSS
7,0–8,9	Hög	Inom 30 dagar	Privilegieeskalering, känslig dataexponering
9,0–10,0	Kritisk	Omedelbart, oftast <72 timmar	Fjärrkörning av kod utan autentisering

En CVSS 4.0-poäng bygger på en vektorsträng som beskriver angreppsvägen, exempelvis om sårbarheten kräver autentisering, går att utnyttja över nätverket, och vilken påverkan den har på konfidentialitet, integritet och tillgänglighet. En typisk vektor för en kritisk, oautentiserad fjärrsårbarhet kan se ut som CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H. Använd FIRST.org:s officiella räknare för att bygga strängen manuellt i stället för att gissa poängen, en felaktig CVSS-bedömning leder lätt till fel prioriteringsordning i er patchkö.

Notera att en hög CVSS-poäng inte automatiskt betyder att ni har en rapporteringspliktig incident enligt cybersäkerhetslagen. En sårbarhet som rapporteras innan den utnyttjats är normalt inte en incident, det är först när den faktiskt missbrukats som NIS2-klockan börjar ticka. Den distinktionen räddar er från att överrapportera varje forskarrapport till tillsynsmyndigheten.

Steg 7: Koppla processen till CERT-SE

CERT-SE är Sveriges nationella CSIRT och fungerar som central kontaktpunkt för säkerhetsincidenter som rör svenska mål. Ni behöver inte kontakta dem för varje enskild sårbarhetsrapport, men de är rätt instans när en sårbarhet redan utnyttjas aktivt, när flera organisationer berörs, eller när ni behöver hjälp att koordinera med en illvillig eller ovillig motpart.

Kontaktvägarna är öppna för alla, oavsett om ni har lagstadgad rapporteringsplikt eller inte. CERT-SE:s RFC 2350-profil, senast uppdaterad 2026-06-01, beskriver formellt ansvarsområde, tjänster och kommunikationsvägar enligt samma internationella standard som de flesta nationella CERT-organisationer följer. Det gör det möjligt att jämföra CERT-SE:s process mot motsvarande dokument hos utländska CERT-team när ett ärende har gränsöverskridande koppling.

De konkreta kontaktuppgifterna:

• E-post: [email protected] för alla ärenden inom CERT-SE:s ansvarsområde
• Telefon: 010-382 80 00, bemannad måndag–fredag 08.00–16.30 utom röda dagar, med jourfunktion utanför ordinarie tid för akuta ärenden
• Kryptering: CERT-SE:s publika PGP-nyckel finns på cert.se/cert_at_cert.se.asc för den som behöver skicka känsligt material
• Servicebeskrivning: hela ansvarsområdet, kommunikationsformerna och öppettiderna finns dokumenterade i CERT-SE:s RFC 2350-profil

Bygg in en regel i ert triage-flöde: om en inkommen rapport pekar på aktiv exploatering i det vilda, eskalera till CERT-SE:s rapporteringssida samma dag, inte vid nästa veckomöte. Undvik samtidigt att kontakta CERT-SE för varje enskild lågriskrapport, det belastar en gemensam nationell resurs i onödan och gör det svårare för dem att prioritera de ärenden som faktiskt kräver koordinering mellan flera organisationer.

Steg 8: Möt cybersäkerhetslagens tidsfrister

Om er organisation omfattas av cybersäkerhetslagen, som är den svenska implementeringen av NIS2-direktivet, gäller strikta tidsfrister från det att ni blir medvetna om en betydande incident. Skillnaden mellan en sårbarhetsrapport och en incident är avgörande här: det är exploateringen, inte upptäckten av bristen, som utlöser klockan.

Tidpunkt	Rapport	Innehåll	Mottagare
Inom 24 timmar	Tidig varning	Kort beskrivning, misstänkt orsak, ev. gränsöverskridande effekt	MSB / behörig myndighet
Inom 72 timmar	Incidentanmälan	Bedömning av allvarlighetsgrad och konsekvenser	MSB / behörig myndighet
Löpande	Lägesrapport	Uppdatering om incidenten fortfarande pågår	MSB / behörig myndighet
Inom 1 månad	Slutrapport	Grundorsak, åtgärder, lärdomar	MSB / behörig myndighet

Sedan den 1 juli 2026 sker en stor del av den formella rapporteringen via Cyberportalen som nationell kanal, medan CERT-SE och Nationellt cybersäkerhetscenter fortsätter att fungera som central CSIRT-funktion för koordinering och tekniskt stöd. Myndigheten för samhällsskydd och beredskap (MSB) fungerar som nationell kontaktpunkt och beskriver kraven i detalj på MSB:s sida om NIS2 för berörda verksamheter. Kontrollera vilken kanal som gäller för er sektor innan ni bygger integrationer, kraven skiljer sig något mellan sektorsspecifika tillsynsmyndigheter.

Koppla ihop VDP-triagen med er bredare patchprioritering. En sårbarhet som rapporteras via VDP-kanalen kan mycket väl vara samma typ av brist som redan finns listad i CISA:s katalog över aktivt exploaterade sårbarheter, se vår genomgång av CISA KEV-patchhantering i 12 steg för hur ni prioriterar åtgärd när en känd sårbarhetsklass dyker upp i er egen miljö. Läs mer om helhetsprocessen kring incidentanmälan i vår guide om NIS2-incidentplan i 12 steg och om lagens bakgrund i artikeln om cybersäkerhetslagen och de 6 000 företag som omfattas.

Steg 9: Begär ett CVE-ID när det behövs

CVE-ID:n identifierar en sårbarhet unikt, men säger inget om allvarlighetsgrad, det är CVSS-poängen som fyller den rollen. Tilldelningen sköts av CVE Numbering Authorities (CNA), organisationer med behörighet att ge ut CVE-ID inom ett definierat produktområde. Om ni själva är leverantör av mjukvaran som drabbas och saknar egen CNA-status, ska ni inte hitta på ett eget ID, utan gå via en täckande CNA eller MITRE:s centrala CVE-program. Full specifikation för hur poängen räknas fram finns hos FIRST.org:s CVSS-dokumentation, som även innehåller en räknare för att bygga vektorsträngen manuellt.

# Exempel: begär en CVE-ID-reservation via MITRE CVE Services API
# (kräver registrerat konto och API-nyckel hos cveform.mitre.org)

curl -s -X POST "https://cveawg.mitre.org/api/cve-id" \
  -H "Content-Type: application/json" \
  -H "CVE-API-KEY: DIN_API_NYCKEL" \
  -H "CVE-API-ORG: DIN_ORGANISATION" \
  -H "CVE-API-USER: ditt.anvandarnamn" \
  -d '{"amount": 1}'

Dokumentera drabbade versioner, allvarlighetsgrad och en åtgärdstidslinje i den publika advisoryn innan ni publicerar CVE-numret. Ett CVE-ID utan åtföljande advisory hjälper varken era kunder eller andra som scannar er kod. Vår guide om CVSS 4.0 och CVE-bevakning går igenom hur ni sedan följer upp publicerade CVE:er över tid.

Tänk också på synkroniseringen mellan CVE-publicering och er egen disclosure-tidslinje. Publicera helst advisory, patch och CVE-detaljer samtidigt, inte i separata steg utspridda över flera dagar. Ett publikt CVE-nummer utan tillgänglig patch fungerar som en karta för angripare som letar efter oskyddade system, vilket är precis den situationen en väl koordinerad process ska undvika.

Steg 10 och 11: Automatisera mottagning och skriv svarsmallar

Ett manuellt inkorgsflöde fungerar i början men skalar dåligt. Ett litet webhook-skript som tar emot rapporter, taggar dem med tidsstämpel och skickar en automatisk bekräftelse sparar timmar varje månad och säkerställer att ingen rapport glöms bort i en delad inkorg.

from flask import Flask, request, jsonify
from datetime import datetime, timezone

app = Flask(__name__)

@app.route("/api/vdp/report", methods=["POST"])
def ta_emot_rapport():
    data = request.get_json(force=True)
    mottagen = datetime.now(timezone.utc).isoformat()

    arende = {
        "titel": data.get("titel", "Namnlös rapport"),
        "beskrivning": data.get("beskrivning", ""),
        "kontakt": data.get("kontakt", ""),
        "mottagen_tid": mottagen,
        "status": "ny",
    }

    # Spara till databas eller ärendehanteringssystem här
    print(f"Ny rapport mottagen {mottagen}: {arende['titel']}")

    return jsonify({
        "meddelande": "Tack för din rapport. Vi bekräftar mottagandet "
                       "och återkommer inom två arbetsdagar.",
        "arende_id": mottagen,
    }), 201

if __name__ == "__main__":
    app.run(port=5000)

Komplettera skriptet med färdiga svarsmallar för de vanligaste scenarierna: bekräftelse av mottagen rapport, begäran om mer information, meddelande om att felet redan är känt (duplicate), och bekräftelse på åtgärd. Färdiga mallar gör att forskare får konsekvent kommunikation oavsett vem i teamet som svarar, vilket bygger förtroende över tid.

Spara alla inkommande rapporter och tidsstämplar i en logg som går att exportera, även de som avslås som falska eller redan kända. Loggen blir ovärderlig om ni någon gång behöver visa för en tillsynsmyndighet eller revisor att ni faktiskt har ett fungerande mottagningsflöde, och den gör det möjligt att i efterhand se om samma sårbarhetstyp rapporteras upprepade gånger, vilket ofta pekar på ett systemiskt problem snarare än en enskild bugg.

Steg 12: Publicera, testa och underhåll policyn över tid

Innan ni går live, kör en intern test där någon utanför säkerhetsteamet följer er egen policy från start till slut, hittar security.txt-filen, läser policyn och skickar en testrapport. Om den personen fastnar, kommer externa forskare också göra det.

Sätt en återkommande kalenderpunkt, till exempel kvartalsvis, för att kontrollera att kontaktadresser fortfarande fungerar, att PGP-nyckeln inte har gått ut, och att Expires-fältet i security.txt pekar tillräckligt långt fram i tiden. En policy som inte underhålls är i praktiken en policy som inte finns.

Vanliga fallgropar

• Ingen safe harbor-text. Utan ett tydligt löfte om att inte stämma forskare som agerar i god tro avstår många från att rapportera alls, oavsett hur bra er teknik i övrigt är.
• security.txt pekar på en död länk. Om Policy-fältet leder till en 404-sida eller en gammal PDF som ingen underhåller, ser det sämre ut än att inte ha filen.
• Otydlig gräns mot bug bounty-löften. Om policyn antyder ersättning utan att vara tydlig med belopp och villkor, skapar det konflikter när forskare förväntar sig betalning.
• Ingen intern ägare. En policy som mailas till en generisk brevlåda utan en namngiven ansvarig person blir obesvarad så fort någon är på semester.
• Blanda ihop sårbarhetsrapport med NIS2-incident. Att automatiskt rapportera varje forskarfynd till tillsynsmyndigheten skapar onödigt brus och kan dölja de verkliga incidenterna i mängden.
• Glömt att uppdatera scope efter en omorganisation. När system läggs ned eller byter ägare men policyn inte uppdateras, riskerar forskare att testa system som redan är avvecklade eller flyttade till en annan juridisk enhet.
• Bara ett enda kontaktsätt. En policy som enbart anger ett formulär utan alternativ som e-post eller PGP-skyddad kommunikation gör det svårare för forskare att rapportera känsliga fynd säkert, vilket ökar risken att de väljer att inte rapportera alls.

Felsökning

De flesta problem med en nystartad VDP handlar inte om avancerad teknik utan om småsaker som cache, filsökvägar och interna eskaleringsvägar som aldrig testats i praktiken. Nedan är de vanligaste problemen teams stöter på när de sätter upp och driftar en VDP, med konkreta åtgärder.

Problem	Trolig orsak	Lösning
security.txt ger 404	Filen ligger i fel katalog eller CDN-regel saknas	Verifiera att filen serveras exakt på /.well-known/security.txt, inte roten
Fel content-type i svaret	Webbservern serverar filen som HTML eller octet-stream	Tvinga text/plain; charset=utf-8 via serverkonfiguration
Forskare hittar inte policyn	Policy-fältet saknas eller pekar fel	Kontrollera länken manuellt från en extern anslutning
PGP-kryptering går inte att verifiera	Nyckeln har gått ut eller fingeravtrycket stämmer inte	Generera ny nyckel med giltighetstid, publicera fingeravtrycket på flera ställen
Rapporter kommer aldrig fram	E-postfilter blockerar externa avsändare eller bilagor	Vitlista security@-adressen i spamfiltret, tillåt vanliga bilagetyper
Triage-skriptet svarar inte	Webhooken är inte publikt nåbar eller brandväggen blockerar	Testa med curl utifrån, öppna endast nödvändig port
Osäker på om ni ska kontakta CERT-SE	Otydlig intern eskaleringsregel	Definiera skriftligt: aktiv exploatering eller flera drabbade parter = kontakta CERT-SE samma dag
Osäker på NIS2-tidsfrist	Blandar ihop sårbarhetsrapport med bekräftad incident	Klockan startar vid bekräftad exploatering, inte vid mottagen rapport
CVE-begäran avslås eller dröjer	Fel CNA kontaktad eller ofullständig information	Kontrollera CNA-täckning på cve.org innan ni skickar in begäran

Bygg själva eller använd en hanterad plattform?

Allt i den här guiden går att bygga med egna resurser, men det finns ett läge då en hanterad plattform blir värt kostnaden. Tjänster som HackerOne och Bugcrowd erbjuder färdig infrastruktur för rapportmottagning, forskarverifiering och triage-arbetsflöden, vilket kan vara motiverat för organisationer som redan vet att de vill växla upp till ett betalt bug bounty-program eller som saknar intern kapacitet att bygga och underhålla ett eget system.

Nackdelen är kostnad och att ni lägger en del av kontrollen över kommunikationen hos en tredje part. För en organisation som bara vill uppfylla grundkraven, ha en publicerad kontaktväg och ett rimligt svarsflöde, räcker den egenbyggda modellen i den här guiden gott och väl. Ett vanligt mönster är att börja självbyggt, samla erfarenhet under ett till två år, och sedan utvärdera om volymen av rapporter motiverar en hanterad lösning. Byt inte plattform i onödan när processen redan fungerar, forskare som lärt sig hitta er via en kanal tappar spårbarhet om adressen plötsligt flyttar.

Ett mellanting värt att nämna är att låta en hanterad plattform sköta enbart forskarverifiering och betalningsflöde, medan triage och teknisk bedömning stannar internt hos er själva. Den modellen passar organisationer som vill sänka tröskeln för forskare utan att ge upp den interna kontrollen över hur känsliga fynd hanteras och kommuniceras vidare i organisationen.

Mät och förbättra processen över tid

En VDP som aldrig utvärderas tenderar att långsamt förfalla, ansvarig personal byts ut och rutinerna glöms bort. Sätt upp ett litet antal mätpunkter som är enkla att följa upp kvartalsvis: tid till första bekräftelse, tid till att ett fynd är åtgärdat per allvarlighetsnivå, andel rapporter som var falska eller redan kända, och hur många forskare som återkommer med fler rapporter över tid. Det sista måttet är ofta det mest talande, återkommande forskare är ett tecken på att processen upplevs som rättvis och att kommunikationen fungerar.

Ta med statistiken i samma forum där ni redan rapporterar andra säkerhetsnyckeltal, till exempel patchhanteringstakt eller resultat från penetrationstester. En VDP som lever isolerat från resten av säkerhetsarbetet tenderar att bli en sidoprocess som tappar prioritet så fort något annat brinner.

Boka också in en årlig genomgång av själva policytexten, inte bara av statistiken. Scope förändras när ni lanserar nya produkter, förvärvar bolag eller lägger ned gamla system, och en policy som inte hängt med i den utvecklingen skickar forskare mot fel mål eller missar helt nya system som borde omfattas. En kort genomgång tillsammans med produktägarna en gång per år räcker oftast för att hålla policyn aktuell.

Avancerade tips

När grundprocessen fungerar kan ni skärpa den ytterligare. Koppla triage-skriptet till er befintliga SIEM-lösning så att en kritisk rapport automatiskt öppnar ett incidentärende, inte bara ett mejl i en delad inkorg. Om ni redan kör Wazuh för dataintrångsdetektering, är det naturligt att låta triage-skriptet skicka en varning dit så att inkommande rapporter syns i samma översikt som övriga säkerhetshändelser.

Överväg också att lägga in en enkel hastighetsbegränsning på rapportendpointen för att undvika skräpinlämningar, samt en automatisk duplicate-kontroll som jämför nya rapporter mot redan kända öppna ärenden baserat på nyckelord i titeln. Slutligen, publicera en anonymiserad sammanfattning en gång per år av hur många rapporter ni tagit emot och hur snabbt ni svarat, det bygger förtroende hos forskarcommunityt utan att avslöja känsliga detaljer om enskilda sårbarheter.

Om organisationen är stor nog att ha flera produktteam, utse en säkerhetskontakt per team i stället för att låta ett centralt team äga all teknisk uppföljning. Den centrala funktionen sköter fortfarande mottagning, triage och kommunikation med forskaren, men den tekniska åtgärden går snabbare när rätt team kopplas in direkt i stället för att gå via flera mellansteg. Dokumentera ägarskapet i samma system ni redan använder för att spåra produktionsincidenter, så att ingen behöver hålla reda på två separata eskaleringslistor.

Komplett exempelprojekt

Nedan är hela projektstrukturen samlad, redo att anpassas till er egen domän och kopieras in i ett git-repo. Börja med själva policytexten, som binder ihop scope, safe harbor och svarstider från steg 1 och 2 i ett enda dokument:

# Vulnerability Disclosure Policy – Erdoman AB

## Scope
- *.erdoman.se (produktionsmiljöer)
- API:et api.erdoman.se/v2

## Undantag
- Tredjepartstjänster som bara integreras (t.ex. betalleverantör)
- Miljöer märkta "staging" eller "dev"

## Tillåtna testmetoder
- Autentiserad och oautentiserad testning av webb och API
- Statisk och begränsad automatiserad skanning

## Förbjudet
- Överbelastningstester (DoS/DDoS)
- Social manipulation mot anställda
- Fysiskt intrång

## Rapportering
Skicka rapport till [email protected] eller via
https://erdoman.se/security/report. Kryptera känsligt
material med vår PGP-nyckel (se security.txt).

## Svarstider
- Bekräftelse: inom 2 arbetsdagar
- Första bedömning: inom 7 dagar
- Kritiska fynd: åtgärd inom 72 timmar

## Safe harbor
Se separat avsnitt i denna policy (steg 2).

Komplettera sedan med resten av filträdet:

vdp-projekt/
├── .well-known/
│   ├── security.txt          # RFC 9116-fil från steg 3
│   └── pgp-key.txt           # Publik PGP-nyckel från steg 5
├── policy/
│   └── vdp-policy.md         # Policytexten från steg 2
├── triage/
│   ├── app.py                # Flask-webhook från steg 10
│   ├── requirements.txt      # flask==3.0.3
│   └── mallar/
│       ├── bekraftelse.txt
│       ├── behover_mer_info.txt
│       ├── redan_kand.txt
│       └── atgardad.txt
└── README.md

Starta triage-tjänsten lokalt för test innan ni lägger den bakom en riktig reverse proxy med TLS:

cd vdp-projekt/triage
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python3 app.py

# I en annan terminal, skicka en testrapport:
curl -X POST http://localhost:5000/api/vdp/report \
  -H "Content-Type: application/json" \
  -d '{"titel":"Testrapport","beskrivning":"Detta är ett test","kontakt":"[email protected]"}'

Med filträdet, policytexten, den publicerade security.txt-filen och triage-webhooken på plats har ni en fungerande VDP-process som täcker hela kedjan från att en forskare hittar er kontaktinformation till att ärendet loggas, bedöms med CVSS och vid behov eskaleras till CERT-SE eller rapporteras enligt cybersäkerhetslagens tidsfrister. För mer bakgrund om hur den här typen av processer passar in i ett bredare säkerhetsarbete, se vår samlade bevakning av cybersäkerhet.

Vanliga frågor

Måste alla svenska företag ha en vulnerability disclosure policy?
Nej, det finns inget generellt lagkrav på en VDP för alla företag. Organisationer som omfattas av cybersäkerhetslagen har dock krav på incidenthantering och rapportering, och en fungerande VDP gör det lättare att upptäcka problem innan de blir just incidenter som måste anmälas inom 24-timmarsfristen. Även organisationer utan lagkrav vinner på att ha en, eftersom alternativet ofta är att forskare rapporterar via sociala medier i stället.

Vad är skillnaden mellan security.txt och själva VDP-dokumentet?
security.txt är en maskinläsbar fil enligt RFC 9116 som pekar mot kontaktuppgifter och er fullständiga policy. Den ersätter inte policyn, den fungerar som en upptäckbar ingång till den.

När ska vi kontakta CERT-SE i stället för att hantera en rapport själva?
Kontakta CERT-SE när en sårbarhet redan utnyttjas aktivt, när flera organisationer eller sektorer berörs, eller när ni behöver hjälp att nå en leverantör som inte svarar på er egen kontaktväg.

Kan vi själva tilldela ett CVE-nummer till en sårbarhet vi hittar i vår egen produkt?
Endast om ni har status som CVE Numbering Authority (CNA) för det aktuella produktområdet. Utan CNA-status ska ni gå via er leverantörs CNA eller MITRE:s centrala CVE-program.

Hur snart måste vi rapportera en incident enligt cybersäkerhetslagen?
En tidig varning ska lämnas inom 24 timmar från det att ni blivit medvetna om en betydande incident, en mer fullständig incidentanmälan inom 72 timmar, och en slutrapport inom en månad. Fristen räknas från medvetenhet om incidenten, inte från när den faktiskt inträffade, vilket gör snabb intern eskalering avgörande för att hinna i tid.

Behöver vi betala forskare som rapporterar via vår VDP?
Nej, en VDP kräver ingen ersättning. Om ni vill belöna forskare kan ni komplettera med ett separat bug bounty-program längre fram, men börja gärna med en obetald VDP för att testa processen.

Vilken CVSS-version ska vi använda för att bedöma inkomna rapporter?
CVSS 4.0 är den aktuella versionen från FIRST.org och rekommenderas för nya bedömningar, då den ger bättre stöd för miljö- och hotspecifika justeringar än tidigare versioner.

Vad händer om en forskare bryter mot scopet i vår policy?
Bedöm avsikten innan ni reagerar. Ett mindre misstag, som att testa en glömd subdomän utanför scope utan skadeavsikt, hanteras normalt genom dialog och en påminnelse om gränserna. Safe harbor-löftet gäller bara god tro, så ett uppenbart illvilligt agerande, till exempel dataexfiltrering i stor skala, faller utanför skyddet och kan behöva eskaleras som en säkerhetsincident i stället för en VDP-rapport.