Glossary

Every term used in the portal, explained in plain language. Terms with a dotted underline in the app lead here.

Search the glossary

Actively exploited vulnerability

A vulnerability attackers are really using. It triggers the obligation to notify ENISA within 24 hours.

The sources are the CISA KEV (Known Exploited Vulnerabilities) catalogue and the exploitation flags in the European EUVD database. If such a vulnerability is present in a component your product uses, the obligation under Article 14(1) CRA arises.

In Meldora such matches are marked urgent, a 24-hour deadline runs from the alert, and with automatic routing on they go straight to the consultant.

API token and CI upload

A key with which your pipeline sends the SBOM to Meldora after every release.

You create the token in the settings; it is shown only once. Store it as a CI secret (GitLab: Settings → CI/CD → Variables; GitHub: Settings → Secrets). The token only allows uploading an SBOM to your company's products (the product is given in the address); it cannot read reports or change anything. Revoke it when you change CI or when the person who knew it leaves.

Article 14 CRA: reporting obligation

The manufacturer reports actively exploited vulnerabilities and severe incidents in three stages: 24 h, 72 h, 14 days.

The deadlines run from the moment the manufacturer becomes aware of an actively exploited vulnerability (or of a severe incident affecting the product's security). The manufacturer also informs the product's users about the vulnerability and the remedies.

Non-compliance with Articles 13 and 14 carries administrative fines of up to EUR 15 million or 2.5% of worldwide annual turnover (Article 64 CRA).

Becoming aware

The moment from which the deadlines run. In Meldora it is the time of the alert about an actively exploited vulnerability.

We record it in the order log together with the person who took the decision. If you learned about the vulnerability earlier through another channel (e.g. from a researcher), tell the consultant, because the deadlines then run from that moment.

CE marking and declaration of conformity

From 11 December 2027 products with digital elements must meet the CRA requirements to carry the CE mark.

The EU declaration of conformity also covers the cybersecurity requirements of Annex I CRA, including vulnerability handling. The technical documentation includes the SBOM and a description of the vulnerability-handling process. Meldora supplies part of the evidence: SBOM, monitoring, reports and the log.

Client decision

What you do with a match: send it to the consultant or dismiss it as irrelevant.

“Send to consultant” creates an order for an expert assessment. You see the price before you send it: the assessment is either included in your package or charged per item, as the contract says. “Skip, doesn't affect us” closes the match without a report; you can undo it. In automatic mode every new match goes to the consultant without asking.

Component

A single library or package in the SBOM, e.g. openssl 3.0.13.

Every component has a name and a version. Matches arise from comparing name and version with vulnerability databases. A component without a version cannot be monitored.

Consultant's assessment

Affected, not affected, or under analysis, with a justification.

“Affected”: the vulnerable code is used and the vulnerability impacts the product; it must be removed in an update. “Not affected”: code absent, unreachable or protected; the consultant records the reason in VEX codes. “Under analysis”: the consultant is waiting for information from you.

Coordinated vulnerability disclosure (CVD)

A policy for receiving reports from researchers, required by the CRA.

The manufacturer must have a contact address for vulnerability reports (e.g. security@, a security.txt file) and a procedure for handling them. A researcher's report of an exploited vulnerability in your product also starts the Article 14 deadlines. The consultant helps prepare a CVD policy.

Coordinator CSIRT

The national response team designated by the Member State that receives the notification alongside ENISA; in Poland the national CSIRT role is held by CSIRT NASK among others.

When the SRP is down, the manufacturer contacts the CSIRT by phone and completes the notification on the platform once it is back. Note the time of the attempt and the content of the call in the order log.

CVE

The public identifier of a vulnerability, e.g. CVE-2021-44228.

Common Vulnerabilities and Exposures: a registry run by MITRE. Every publicly known vulnerability receives a number shared by all databases and tools. In the EU the EUVD database runs in parallel with its own identifiers and references to CVE.

CVSS

Severity score from 0 to 10: low (up to 3.9), medium (4–6.9), high (7–8.9), critical (9–10).

The Common Vulnerability Scoring System describes how dangerous a vulnerability is in theory: remote exploitability, authentication needed, impact. It does not say whether it affects your product or whether anyone is exploiting it; the consultant's assessment and the KEV catalogue answer that.

Cyber Resilience Act (CRA)

EU Regulation 2024/2847 on the cybersecurity of products with digital elements.

Regulation (EU) 2024/2847 of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements. It applies directly across the EU, without national transposition.

The reporting obligations (Article 14) apply from 11 September 2026. The remaining requirements (product security, vulnerability handling throughout the support period, CE marking) apply from 11 December 2027.

CycloneDX

An SBOM format maintained by OWASP, the most common one in security tooling.

A JSON or XML format with the component list, product metadata (name, version) and optionally vulnerabilities (VEX). Recommended in Meldora because it carries the product version in its metadata, so a new SBOM lands in the right version by itself.

Early warning (24 h)

The first stage: a short note that the vulnerability is being exploited, within 24 hours of becoming aware.

Only basic data is required: notification type, title, summary, Member States, product name and version, date of becoming aware. It is better to send it quickly with incomplete data than to be late waiting for the analysis.

Emergency contact

The person in your company the consultant calls when a vulnerability is actively exploited.

They should have a phone number they answer in the evening and at weekends too. With a 24-hour deadline an e-mail can be missed, so in an urgent case the consultant calls. Automatic text messages are coming soon.

ENISA

The European Union Agency for Cybersecurity, which runs the reporting platform.

An Article 14 notification reaches ENISA and the coordinator CSIRT of the Member State where the manufacturer has its main establishment at the same time. One platform serves both recipients.

EPSS

The probability that a vulnerability will be exploited within 30 days (0–100%).

The Exploit Prediction Scoring System published by FIRST. It complements CVSS: a vulnerability with a high CVSS but an EPSS of 1% is in practice less urgent than one with an EPSS of 90%. Meldora shows EPSS when the engine has the data.

EUVD

The European vulnerability database run by ENISA.

The European Union Vulnerability Database has been live since 2025. It collects vulnerabilities from CVE and other sources, adds its own identifiers (EUVD-YYYY-NNNNN) and flags the exploited ones. Meldora synchronises it several times a day.

Final report (14 days)

The third stage: a detailed description of the vulnerability, the malicious actor (if known) and the update made available.

The 14 days run from the moment a corrective or mitigating measure, such as a firmware update, is available. When you upload the SBOM of the version marked as the planned fix, Meldora inserts its number and date into the final report by itself.

Manufacturer

The entity placing the product on the EU market under its own name or brand; the CRA obligations rest on it.

An importer or distributor that places a product under its own brand, or substantially modifies it, is treated as a manufacturer. The manufacturer submits the ENISA notification and is responsible for its content.

Match

A pair: a component from your SBOM and a vulnerability affecting its version.

A match does not yet mean the product is vulnerable: the library may be present while the vulnerable function is unused or unreachable from the network. That is why you take a decision on each match and the consultant assesses the impact.

Matching engine

The part of Meldora that compares the SBOM with vulnerability databases (OSV, NVD, GitHub Advisories).

The engine checks every monitored product version. After every database synchronisation it re-checks the components, so a match can appear months after the SBOM was uploaded. The synchronisation state is on the overview page.

MFA, TOTP, passkey

The second sign-in factor: a code from an app (TOTP), a hardware key or a passkey.

Every Meldora account requires MFA. Clients can use an authenticator app (e.g. Microsoft Authenticator, Google Authenticator, Aegis) or a passkey. The consultant signs in only with a hardware key or a passkey. A session expires after 30 minutes of inactivity.

Monitoring report

A monthly summary: new matches, source status, orders. Included in the subscription.

It documents that monitoring was continuous, which is one of the manufacturer's obligations during the support period. Find it under Orders and reports.

NVD, OSV, GitHub Advisories

Public vulnerability databases we compare your components against.

NVD (National Vulnerability Database, NIST) adds CVSS scores and affected-version lists to CVEs. OSV (Google) describes open-source package vulnerabilities with precise version ranges. GitHub Advisories cover npm, PyPI, Maven, NuGet, Go and other ecosystems.

Order log

A chronological record of events: who did what and when. Evidence in case of an inspection.

It holds the moment of detection and of becoming aware, questions and answers, the report's publication and the confirmations of submission to ENISA with notification numbers. It is attached to the downloaded report. Entries cannot be edited or deleted.

Planned release

The number and date of the version in which you will remove the vulnerabilities. It goes into reports and ENISA texts.

When you upload the SBOM of that version, Meldora marks the plan as done and inserts the version with its date into the final report for ENISA. If the date passes without a new SBOM, the consultant gets a reminder.

Product with digital elements

A device or software that connects to a network or another device and is placed on the EU market.

Any hardware or software product whose use involves a direct or indirect logical or physical connection to another device or network. In practice: controllers, gateways, IoT sensors, firmware, applications, libraries delivered to customers.

In Meldora each product has its own SBOM, versions, EU markets and support period. If you sell variants with different software, register them as separate products.

PURL (package URL)

An unambiguous package identifier, e.g. pkg:deb/debian/openssl@3.0.13.

The pkg:ecosystem/name@version notation lets tools match a component to a vulnerability database without mistakes. SBOM generators (Syft, cdxgen) add PURLs automatically; hand-written SBOMs usually lack them.

Report order

Handing matches to the consultant for assessment; it ends with a report.

An order has a number (RAP/YYYY/MM/NNN), a contractual deadline, an event log and a message thread. An assessment is counted per item, that is one vulnerability in one product, also when the item joins an order in progress. Urgent matches create a separate order with a shorter deadline.

Report turnaround (SLA)

The contractual deadline by which the consultant publishes the report: urgent ones in hours, the rest in business days.

Business days exclude Saturdays, Sundays and Polish public holidays. When the consultant asks a question that blocks the assessment, the deadline is paused until you answer; this is visible in the order log.

Routing mode

Manual: you decide on every match. Automatic: everything goes to the consultant.

In manual mode you can turn on automatic routing for urgent vulnerabilities only; we recommend it, because with a 24-hour deadline every hour counts. A mode change applies to new matches; decisions on already-sent ones stand.

SBOM (Software Bill of Materials)

The list of software components in the product, with versions. The basis of monitoring.

An inventory of all libraries, packages and modules (including nested ones) that make up the product's software, with version numbers and, ideally, PURL identifiers. The CRA requires manufacturers to draw up an SBOM covering at least the top-level dependencies.

Meldora accepts SBOMs in CycloneDX and SPDX (JSON). The more complete the SBOM (versions, PURLs), the fewer false and missed matches.

Severe incident

An incident affecting the security of the product; also reportable within 24 h, 72 h and 1 month.

Article 14(3) CRA: for instance a compromised update infrastructure, leaked firmware signing keys, malicious code in a release. Meldora monitors component vulnerabilities; you tell the consultant about an incident yourself and the consultant helps prepare the notification.

Single Reporting Platform (SRP)

ENISA's platform through which the manufacturer submits notifications. Live since 11 September 2026, in English, without an API.

Sign-in through EU Login with MFA. A company appoints a primary representative and up to 20 additional ones (Assigned Representatives). One notification covers one vulnerability. A draft is visible only to the person who created it. After the final report is submitted the notification can no longer be edited.

The platform has no API, so Meldora prepares texts to paste, in the order of the form fields, and never submits anything itself. Mandatory fields are marked with an asterisk.

SPDX

The Linux Foundation SBOM format, ISO/IEC 5962.

Created for licence descriptions, now used for security too. Meldora treats the package described by the document (DESCRIBES relationship) as the product and the remaining packages as components. If the document does not name the product, we ask for the version.

Support period

The time during which the manufacturer provides security updates; the CRA expects at least 5 years unless the product is used for less.

You state the end-of-support date to users at the time of sale and in the ENISA notification (the “support period” field). After it expires the vulnerability-handling obligation ends, but continued sales still require updates. Meldora reminds you 90 days before the end.

Supported and retired versions

We monitor every version your customers use; a version nobody uses any more is marked as retired.

Devices in the field often run older firmware. That is why Meldora keeps the SBOM of every version and checks all of them. The newest version is always monitored. Uploading an SBOM with the same version number replaces the previous one.

VEX

A document telling the product's customers which known vulnerabilities do not affect it, and why.

Vulnerability Exploitability eXchange. Customers who scan your SBOM see the same matches you do. VEX lets them separate real vulnerabilities from apparent ones. Meldora exports VEX in CycloneDX format from the consultant's assessments.

The justification codes come from the CycloneDX standard, e.g. code_not_present, code_not_reachable, protected_by_mitigating_control.

Vulnerability assessment report

The consultant's document: the decision on notifying ENISA, the justification, recommendations and form texts.

After publication the report content is frozen and attached to the order log. You download the report as an HTML file (for printing or PDF). If a notification is required, every ENISA form field has a Copy button.

Vulnerability notification (72 h)

The second stage: general product information, the nature of the exploitation, an initial severity assessment and the measures taken.

The 72 hours run from becoming aware, not from submitting the early warning. The counter shown on the SRP may display a different time; Meldora counts the deadline as the Regulation does and records the moment of awareness in the log.