Application Security

Hva er CVE (Common Vulnerabilities and Exposures)?

CVE står for Common Vulnerabilities and Exposures. Det er et system som holder oversikt over cybersikkerhetssårbarheter som allerede er kjent for offentligheten.

Hva er CVE (Common Vulnerabilities and Exposures)?

CVE står for Common Vulnerabilities and Exposures. Det er et system som holder oversikt over cybersikkerhetssårbarheter som allerede er kjent for offentligheten.

Hver CVE-post har sin egen ID, som CVE-2024-492881, og forklarer en spesifikk svakhet i programvare, maskinvare eller fastvare som angripere kan bruke for å utnytte systemet.

CVE-programmet ble lansert av MITRE Corporation, en amerikansk føderalt finansiert ideell organisasjon fokusert på cybersikkerhet og teknologi. I dag fortsetter MITRE å administrere CVE-systemet med tilsyn fra CVE-styret—en gruppe som inkluderer sikkerhetseksperter, leverandører og globale interessenter. Organisasjoner, leverandører, sikkerhetsverktøy og forskere over hele verden bruker CVE for å spore sårbarheter og administrere oppdateringer.

Hvorfor CVE er viktig i cybersikkerhet

Før CVE stolte forskere og organisasjoner på separate navngivningsskjemaer, noe som gjorde det vanskelig å spore sårbarheter på tvers av forskjellige verktøy og rapporter.

CVE hjelper med å løse dette problemet ved å tilby:

  • Konsekvente identifikatorer for hver sårbarhet
  • Sentralisert synlighet i den globale sikkerhetsdatabasen
  • Enklere samarbeid blant leverandører, forskere og organisasjoner involvert i cybersikkerhet.

CVE utgjør grunnlaget for sikkerhetsverktøy som sårbarhetsskannere, SCA, ASPM og oppdateringshåndteringssystemer som er avhengige av CVE-IDer for å oppdage og prioritere risikoer.

Hvordan fungerer CVE?

Hver CVE-post i sårbarhetsdatabasen inkluderer

  • En CVE-ID - en unik identifikator for en sårbarhet
  • En Beskrivelse - forklaring av sårbarheten
  • Referanser - pålitelige eksterne kilder som gir detaljert informasjon om sårbarheten
  • En CVSS-score - alvorlighetsgrad, en vurdering som forteller deg hvor alvorlig eller påvirkning av en sårbarhet er hvis den blir utnyttet.

Alle CVE-er lagres offentlig på cve.org, og speiles også i National Vulnerability Database (NVD) vedlikeholdt av NIST (National Institute of Standards and Technology), som er et ikke-regulerende byrå under USAs handelsdepartement.

Kjente vs. Ukjente Sårbarheter

Kjente Sårbarheter

Sårbarheter som sikkerhetsorganisasjoner og forskere er klar over og kan gi oppdateringer for å adressere sårbarhetene.

De kjente sårbarhetene er ofte allerede publisert i databaser som CVE eller NVD.

Eksempel:

CVE-2017-5638 — Apache Struts-sårbarheten utnyttet i Equifax-bruddet (2017).

Ukjente (Zero-Day) Sårbarheter

Dette er uoppdagede eller ikke avslørte feil; de eksisterer i programvare, men er ennå ikke dokumentert i CVE-databaser.

Angripere kan utnytte dem før leverandøren utgir en oppdatering. Dette er en feil som er svært farlig.

Eksempel:

En nettlesersårbarhet brukes av angripere før Google eller Microsoft utgir en løsning.

Relaterte Termer

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

FAQ: CVE

Hva er en CVE-ID?

En CVE-ID er en unik identifikator tildelt en offentliggjort sårbarhet (f.eks. CVE-2025-01234).

Hvem vedlikeholder CVE-systemet?

CVE-programmet administreres av MITRE Corporation, med tilsyn fra CVE-styret og finansiering fra amerikanske myndighetsorganer som Department of Homeland Security (DHS) og CISA.

Er alle sårbarheter oppført i CVE?

Nei. Bare offentlig kjente sårbarheter får CVE-IDer. Ukjente sårbarheter eller Zero-day sårbarheter er ennå ikke registrert.

Hvordan relaterer CVE og CVSS seg til hverandre?

CVE identifiserer sårbarheten; CVSS (Common Vulnerability Scoring System) måler dens alvorlighetsgrad.

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)