# Glossary — every technical term, in plain language

Each entry: what the term means, and what it means **inside euvd-watch**. Sorted by theme, so related terms sit together. If a term you meet in the docs is missing here, that's a documentation bug — please open an issue.

---

## 1. Software inventories

**SBOM (Software Bill of Materials)**
A machine-readable list of every software component ("ingredient") inside a program: names, versions, and identifiers. Exactly like the ingredient list on food packaging, but for software.
*In euvd-watch:* the input to everything. You bring an SBOM (generated by a tool like Syft); euvd-watch reads it.

**CycloneDX**
One of the two major SBOM file formats, maintained by OWASP. Usually a JSON file.
*In euvd-watch:* supported input format (versions 1.4–1.6, JSON).

**SPDX**
The other major SBOM format, maintained by the Linux Foundation and standardized as ISO/IEC 5962.
*In euvd-watch:* supported input format (2.3, JSON) — e.g., GitHub's built-in SBOM export.

**Component**
One entry in an SBOM: a library, application, OS package, or container image, with its version and identifiers.
*In euvd-watch:* the normalized internal model everything else operates on, regardless of which SBOM format it came from.

**PURL (Package URL)**
A compact, standardized identifier for a software package, e.g. `pkg:pypi/pillow@10.1.0` — it encodes the ecosystem (pypi), the name (pillow) and the version. Precise and unambiguous.
*In euvd-watch:* the preferred component identifier from SBOMs. Note: EUVD records do **not** use purls, which is why a matching engine is needed at all.

**CPE (Common Platform Enumeration)**
An older, NVD-style identifier for software products in the form `cpe:2.3:a:vendor:product:version:...`. Widely used in vulnerability databases, but messier than purl (vendor/product names are inconsistent).
*In euvd-watch:* the best bridge between SBOM components and vulnerability records, when the SBOM includes it.

**Syft / cdxgen**
Popular open-source tools that *generate* SBOMs by inspecting your code, containers, or filesystems.
*In euvd-watch:* recommended companions. euvd-watch deliberately does **not** generate SBOMs — it consumes what these tools produce.

---

## 2. Vulnerabilities, databases and scores

**Vulnerability**
A flaw in software that an attacker could exploit — the "spoiled ingredient."

**CVE (Common Vulnerabilities and Exposures)**
The global naming system for vulnerabilities. Each gets an ID like `CVE-2026-12345` so everyone worldwide talks about the same flaw.
*In euvd-watch:* EUVD records carry CVE IDs as aliases; euvd-watch uses them to cross-reference EPSS and KEV.

**EUVD (European Union Vulnerability Database)**
Europe's own vulnerability database, operated by ENISA, created under the NIS2 directive. Records have their own IDs, alias CVE IDs, affected-product data, and — crucially — a flag for vulnerabilities that are being **actively exploited**.
*In euvd-watch:* the primary data source. The project exists because nothing open was built around the EUVD.

**ENISA**
The European Union Agency for Cybersecurity — the EU body that operates the EUVD and receives CRA notifications (together with national CSIRTs).

**NVD (National Vulnerability Database)**
The long-standing US government vulnerability database. Most existing scanners are built around it.
*In euvd-watch:* not used directly — euvd-watch is deliberately EUVD-first, reducing dependence on a single non-EU source.

**OSV (Open Source Vulnerabilities)**
A Google-initiated open database focused on open-source package vulnerabilities, with excellent ecosystem/version precision.
*In euvd-watch:* a potential supplementary source; not primary.

**CISA KEV (Known Exploited Vulnerabilities)**
A catalog maintained by the US cybersecurity agency (CISA) listing only vulnerabilities **confirmed to be exploited in the wild**. Small, high-signal.
*In euvd-watch:* an enrichment source and one of the configurable CRA trigger conditions.

**"Actively exploited"**
A vulnerability that attackers are *currently using* in real attacks — not just a theoretical flaw. The difference between "this lock model can be picked" and "burglars on your street are picking this lock tonight."
*In euvd-watch:* the highest-priority signal, and the condition that starts CRA reporting duties.

**EPSS (Exploit Prediction Scoring System)**
A daily-updated probability score (0–1) estimating how likely a vulnerability is to be exploited in the next 30 days. Produced by FIRST.org.
*In euvd-watch:* enrichment on every finding, and an optional CRA trigger condition (`epss >= threshold`).

**CVSS (Common Vulnerability Scoring System)**
The classic 0–10 *severity* score of a vulnerability. Measures how bad exploitation *would be* — not how likely it is (that's EPSS).
*In euvd-watch:* displayed for context; not a trigger by default.

**Finding**
euvd-watch's own term: one (component, vulnerability record) pair that the matcher believes are related, with a confidence level and a human-readable explanation of *why*.

**Confidence score (high / medium / low)**
euvd-watch's honesty label on every finding. `high` = structured identifiers and version provably in the affected range; `medium` = good but incomplete evidence; `low` = a name-similarity hint that exists only for human review. Automated decisions are never built on `low`.

**False positive**
An alert about a problem that doesn't actually apply to you (e.g., the vulnerable function exists in the library, but only in a version you don't use). The #1 reason security tooling gets ignored.
*In euvd-watch:* the enemy that VEX statements (below) exist to fight.

---

## 3. Decisions and documents

**VEX (Vulnerability Exploitability eXchange)**
A machine-readable statement answering: "vulnerability X was reported against your product — does it *actually* affect it?" Possible answers: affected / not affected / fixed / under investigation. VEX is how you silence false positives *with a documented reason* instead of just ignoring alerts.

**OpenVEX**
A minimal, open specification for writing VEX documents (there are competing formats; OpenVEX is the simplest and tool-friendly).
*In euvd-watch:* the output format of `vex generate`. Downstream scanners can consume it and stop re-alerting on documented non-issues.

**Justification**
In a VEX `not_affected` statement, the standardized machine-readable *reason* (e.g., `vulnerable_code_not_present`). OpenVEX requires one — you can't just say "not affected, trust me."
*In euvd-watch:* mandatory, plus a plain-language explanation on top.

**Conservative VEX**
euvd-watch's design rule: the tool auto-writes `not_affected` **only** when it can machine-prove it (e.g., your version is provably outside the affected range, with high confidence). Everything uncertain stays `under_investigation` for a human. The tool must never hide real risk to look tidy.

**Decisions file (`vex-decisions.yaml`)**
The human side of the loop: a YAML file where a person records judgments ("we don't ship that code path"), which euvd-watch merges with its automated drafts. Human decisions always win — loudly, and on the record.

---

## 4. European law

**CRA (Cyber Resilience Act)**
The EU regulation imposing cybersecurity obligations on manufacturers of "products with digital elements" (i.e., nearly all software and connected hardware sold in the EU) — secure development, vulnerability handling, and incident/vulnerability reporting.
*In euvd-watch:* the regulatory reason the M4 workflow exists.

**Article 14 (of the CRA)**
The CRA article obliging manufacturers to notify authorities about **actively exploited vulnerabilities** in their products, on strict deadlines: an early warning within **24 hours** of becoming aware, a fuller notification within **72 hours**, and a final report later. (euvd-watch treats the exact stages as configurable and verifies them against the current legal text.)
*In euvd-watch:* the trigger→clock→draft→audit workflow of milestone M4.

**Early warning**
The first, minimal CRA notification — "we've become aware of an actively exploited vulnerability" — due within 24 hours of awareness.
*In euvd-watch:* the document that `cra draft` pre-fills. A human always reviews and submits it; the tool never files anything itself.

**CSIRT (Computer Security Incident Response Team)**
A national cybersecurity response team. CRA notifications go to the designated CSIRT and ENISA through official channels.

**NIS2**
The EU directive on cybersecurity of critical/important entities. Relevant here because it mandated the creation of the EUVD, and because NIS2-regulated organizations are natural users of this tool.

**Manufacturer**
In CRA language: whoever develops/sells a product with digital elements in the EU — including many software vendors who don't think of themselves as "manufacturers."

---

## 5. Engineering terms used in this project

**CI/CD (Continuous Integration / Continuous Delivery)**
The automated pipelines that build and test software on every change (e.g., GitHub Actions, GitLab CI).
*In euvd-watch:* both where euvd-watch itself is tested, and where users run it (via the provided action/template) to gate builds on new findings.

**Exit code**
The number a command returns to its caller. Convention here: `0` = clean, `1` = findings above your policy, `2` = execution error. This is how a CI pipeline "reads" euvd-watch's verdict.

**Cache / TTL (Time To Live)**
Storing API responses locally (cache) and how long they stay valid (TTL). Protects ENISA's beta API from being hammered and lets euvd-watch keep working during outages — with an explicit data-freshness warning.

**Watch mode**
Running the match on a schedule against a *stored* SBOM, because new vulnerabilities appear long after you shipped. Only *new or changed* findings are reported.

**Audit log**
An append-only diary of everything that happened: triggers fired, clocks started, drafts rendered, human confirmations.

**Tamper-evident / hash chain**
Each audit-log entry includes a cryptographic hash of the previous entry, forming a chain. You can't secretly alter or delete a page without every later hash breaking — `cra verify-log` detects the exact broken point. It doesn't *prevent* tampering (nothing local can); it makes tampering **detectable**.

**Human-in-the-loop**
The design rule that automation drafts and a human decides. In euvd-watch nothing is ever submitted, filed, or suppressed without a person confirming.

**Deterministic output**
The same inputs always produce byte-identical outputs (stable ordering, no random elements). Matters for reproducible audits and reliable diffs in git and CI.

**Self-hostable**
You can run the whole thing — pipeline and dashboard — on your own infrastructure. No SaaS dependency; your SBOMs and findings never leave your systems.

**WCAG (Web Content Accessibility Guidelines)**
The standard for making web interfaces usable by people with disabilities (keyboard navigation, screen readers, contrast). Level AA is the common compliance target.
*In euvd-watch:* an explicit commitment for the M6 dashboard.

**EUPL (European Union Public Licence)**
An open-source license created by the European Commission, compatible with major copyleft licenses.
*In euvd-watch:* the project license (EUPL-1.2) — a deliberately European choice for a deliberately European tool.

**Grype / Trivy**
Popular open-source vulnerability scanners built mainly around NVD/OSV data.
*In euvd-watch:* complementary, not competitors — they cover the US-centric databases; euvd-watch covers the EUVD and the CRA workflow, and its VEX output can quiet their false positives.
