added vex explanation page

src/pages/explanations/vulnerability-management/_meta.ts

@@ -17,6 +17,9 @@ export default {
     'mitigation-strategies': {
         title: 'Mitigation Strategies & VEX Rules',
     },
+    'what-is-vex': {
+        title: 'What is VEX',
+    },
     'false-positive-detection': {
         title: 'False Positives',
     },

src/pages/explanations/vulnerability-management/vulnerability-management-overview.mdx

@@ -142,6 +142,7 @@ The result is that vulnerability management — and the evidence required to pro
 - [Risk Assessment Methodology](/explanations/vulnerability-management/risk-assessment-methodology/) — how DevGuard combines CVSS, EPSS, and context
 - [Vulnerability Matching](/explanations/vulnerability-management/vulnerability-matching/) — how findings are mapped to CVEs
 - [Mitigation Strategies](/explanations/vulnerability-management/mitigation-strategies/) — patching, dependency upgrades, VEX, and compensating controls
+- [What is VEX](/explanations/vulnerability-management/what-is-vex/) — exchanging exploitability information for vulnerabilities
 - [False Positives](/explanations/vulnerability-management/false-positive-detection/) — handling noise without losing real risks
 - [DevGuard & Compliance Frameworks](/explanations/compliance/why-compliance-matters/) — mapping vulnerability management to CRA, NIS2, ISO 27001
 - [CRA Compliance with DevGuard](https://devguard.org/cra_compliance) — how DevGuard maps to Cyber Resilience Act requirements

src/pages/explanations/vulnerability-management/what-is-vex.mdx

@@ -0,0 +1,24 @@
+---
+title: What is VEX
+description: "A description of the VEX standard"
+seo:
+  robots: index,follow
+  og:
+    image: /og-image.png
+    type: article
+  schema:
+    type: TechArticle
+  keyword_primary: vulnerabilities vex
+lang: en-US
+ignoreChecks: null
+---
+
+# What is VEX
+
+VEX stands for Vulnerability Exploitability eXchange. In other words, VEX is about exchanging exploitability information for vulnerabilities found in a product. Common security advisory formats answer the question of *what* vulnerabilities are present in a product. VEX complements this by answering whether the product is *actually affected* by a given vulnerability.
+
+In today's vulnerability landscape, many findings reported by scanners turn out not to be exploitable in practice. This can have different causes, for example the vulnerable code may not be present, or it exists but is never reached during execution. VEX gives vendors a way to share exactly this kind of information with their customers (status: `not_affected`, plus a justification such as "vulnerable code not in execution path"), cutting down on noise and alert fatigue.
+
+But VEX isn't limited to "not affected" statuses. If a vulnerability does affect a product, this can be communicated as well (status: `affected`), together with mitigation steps such as upgrading to a patched version. Similarly, if a vulnerability has already been fixed (`fixed`) or is still being analyzed (`under_investigation`), this can also be expressed via VEX.
+
+Being machine-readable, VEX documents can be integrated into existing tooling and pipelines and consumed automatically by customers, for example alongside an SBOM: the SBOM tells you what's in a product, VEX tells you whether any of it is actually a problem.