Application Security

Hvad er CVE (Common Vulnerabilities and Exposures)?

CVE står for Common Vulnerabilities and Exposures. Det er et system, der holder styr på cybersikkerhedssårbarheder, der allerede er kendt for offentligheden.

Hvad er CVE (Common Vulnerabilities and Exposures)?

CVE står for Common Vulnerabilities and Exposures. Det er et system, der holder styr på cybersikkerhedssårbarheder, der allerede er kendt for offentligheden.

Hver CVE-post har sin egen ID, som CVE-2024-492881, og forklarer en specifik svaghed i software, hardware eller firmware, som angribere kunne bruge til at udnytte systemet.

CVE-programmet blev lanceret af MITRE Corporation, en amerikansk føderalt finansieret nonprofitorganisation fokuseret på cybersikkerhed og teknologi. I dag fortsætter MITRE med at administrere CVE-systemet med tilsyn fra CVE Board—en gruppe, der inkluderer sikkerhedseksperter, leverandører og globale interessenter. Organisationer, leverandører, sikkerhedsværktøjer og forskere verden over bruger CVE til at spore sårbarheder og administrere patches.

Hvorfor CVE er vigtigt i cybersikkerhed

Før CVE var forskere og organisationer afhængige af separate navngivningsskemaer, hvilket gjorde det vanskeligt at spore sårbarheder på tværs af forskellige værktøjer og rapporter.

CVE hjælper med at løse dette problem ved at tilbyde:

  • Konsistente identifikatorer for hver sårbarhed
  • Centraliseret synlighed i den globale sikkerhedsdatabase
  • Nem samarbejde blandt leverandører, forskere og organisationer involveret i cybersikkerhed.

CVE danner grundlaget for sikkerhedsværktøjer som sårbarhedsscannere, SCA, ASPM og patch management-systemer, der er afhængige af CVE ID’er for at opdage og prioritere risici.

Hvordan fungerer CVE?

Hver CVE-post i sårbarhedsdatabase inkluderer

  • En CVE ID - en unik identifikator for en sårbarhed
  • En Beskrivelse - forklaring af sårbarheden
  • Referencer - betroede eksterne kilder, der giver detaljeret information om sårbarheden
  • En CVSS Score - alvorlighedsvurdering, en vurdering der fortæller dig, hvor alvorlig eller påvirkning af en sårbarhed er, hvis den udnyttes.

Alle CVE’er er offentligt lagret på cve.org, og også spejlet i National Vulnerability Database (NVD) vedligeholdt af NIST (National Institute of Standards and Technology), som er et ikke-regulerende agentur under USA’s Handelsministerium.

Kendte vs. Ukendte Sårbarheder

Kendte Sårbarheder

Sårbarheder, som sikkerhedsorganisationer og forskere er opmærksomme på og kan levere patches til at adressere sårbarhederne.

De kendte sårbarheder er ofte allerede offentliggjort i databaser som CVE eller NVD.

Eksempel:

CVE-2017-5638 — Apache Struts sårbarheden udnyttet i Equifax-bruddet (2017).

Ukendte (Zero-Day) Sårbarheder

Disse er uopdagede eller uoplyste fejl; de eksisterer i software, men er endnu ikke dokumenteret i CVE-databaser.

Angribere kan udnytte dem, før leverandøren udgiver en patch. Dette er en fejl, der er meget farlig.

Eksempel:

En browser sårbarhed bruges af angribere, før Google eller Microsoft udgiver en rettelse.

Relaterede Termer

  • NVD (National Vulnerability Database)
  • CVSS (Common Vulnerability Scoring System)
  • Zero-Day Vulnerability
  • Exploit
  • Patch Management
  • Vulnerability Management
  • Common Weakness Enumeration (CWE)

FAQ: CVE

Hvad er et CVE ID?

Et CVE ID er en unik identifikator tildelt en offentligt afsløret sårbarhed (f.eks. CVE-2025-01234).

Hvem vedligeholder CVE-systemet?

CVE-programmet administreres af MITRE Corporation, med tilsyn fra CVE Board og finansiering fra amerikanske regeringsagenturer som Department of Homeland Security (DHS) og CISA.

Er alle sårbarheder opført i CVE?

Nej. Kun offentligt kendte sårbarheder får CVE IDs. Ukendte sårbarheder eller Zero-day sårbarheder er endnu ikke registreret.

Hvordan relaterer CVE og CVSS sig til hinanden?

CVE identificerer sårbarheden; CVSS (Common Vulnerability Scoring System) måler dens alvorlighed.

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)