Frequently asked questions

What is this site?

CVEManager lists the known vulnerabilities (CVE, GHSA…) of the third-party components embedded in each BlueMind version, with the analysis made by the BlueMind security team: is BlueMind affected, has it been fixed, is there a workaround? The Report page gives this status vulnerability by vulnerability; the Components page lists every component of a version, its licenses and its known vulnerabilities.

Which BlueMind versions are listed?

The versions still maintained. Versions that are no longer maintained (“outdated”) are hidden by default: tick Show outdated versions to display them. This choice is remembered on all pages.

How often is it updated?

Once a day: the vulnerabilities of each version are imported every morning, then the EUVD data (see below) is refreshed. A new vulnerability therefore appears within a day of its publication in the vulnerability databases; it stays In triage until the BlueMind security team has analysed it.

Where do the vulnerabilities come from?

Each BlueMind version is described by its SBOM (Software Bill of Materials), the list of all the components it embeds. This SBOM is analysed by OWASP Dependency-Track, which matches every component against public vulnerability databases, such as the NVD (CVE identifiers) and the GitHub Advisory Database (GHSA identifiers). CVEManager imports the result and adds the BlueMind analysis.

Which APIs are used?

• Dependency-Track REST API (BlueMind's own instance): the list of BlueMind projects, then, for each version, the CycloneDX BOM with its vulnerabilities (imported into CVEManager) and the BOM without vulnerabilities (the SBOM offered for download).
• ENISA EUVD API (euvdservices.enisa.europa.eu, public): the records of the European Vulnerability Database updated during the last days, used to link CVE and GHSA identifiers.

The links to other sites shown by CVEManager (EUVD records, NVD, cve.org, OpenCVE, GitHub advisories, CVSS calculators) simply open these public sites; no data is sent to them.

What is the EUVD?

The European Vulnerability Database is run by ENISA, the European Union Agency for Cybersecurity, under the NIS2 directive. Each EUVD record (EUVD-YYYY-NNNNN) describes one vulnerability and lists its aliases: the identifiers under which the same vulnerability is known elsewhere, such as a CVE and a GHSA. CVEManager uses these aliases to recognise that two identifiers designate the same vulnerability.

Which data sources are used, and under which terms?

These data may be incomplete, delayed, or inaccurate. This site is not affiliated with, endorsed by, or sponsored by any of these organisations. The notices about CVE, NVD, CVSS, GHSA and EUVD data also appear at the bottom of every page.

What are CVE and GHSA identifiers?

• CVE (CVE-2025-12345): the identifier assigned by the CVE Program, the most widely used reference.
• GHSA (GHSA-xxxx-xxxx-xxxx): the identifier of a GitHub security advisory. GitHub often publishes an advisory before a CVE is assigned, or for vulnerabilities that never get one.

Why can the same vulnerability be listed twice?

Because Dependency-Track queries several databases: the same flaw can be reported once as a CVE (by the NVD) and once as a GHSA (by GitHub). Both entries are kept, since each database may give different details or scores, but they are linked together and counted once (see “5 (10)”).

How are CVE and GHSA linked together?

When an EUVD record lists both identifiers in its aliases, CVEManager links them. The report then shows, under the vulnerability, Same vulnerability as GHSA-… — according to EUVD-…, with a link to the other card when it is in the same report, and to the EUVD record. Links are rebuilt each time the EUVD record changes; as the EUVD data is refreshed after the daily import, a link may appear up to a day after the vulnerability.

Do linked vulnerabilities share the same analysis?

Yes. When a link is made, a vulnerability still In triage takes the analysis already made on its linked vulnerabilities (status, recommendation, workaround), unless they disagree. When the security team changes the analysis of a vulnerability, the change is applied to all its linked vulnerabilities.

What do the statuses mean?

• Exploitable BlueMind is affected: apply the recommendation or the workaround given on the card, or upgrade to a version where it is resolved.
• In triage the analysis is in progress.
• Resolved the vulnerability has been fixed.
• Not affected the component is present, but BlueMind does not use it in a way that exposes the vulnerability (code not reachable, configuration required…).
• False positive the vulnerability was wrongly reported for this component.

The first two are counted in To address, the last three in Resolved or not affected.

Which score is displayed?

A vulnerability often has several scores, from several sources and CVSS versions. The report displays the score of the most recent CVSS version (4.0, then 3.1, 3.0, 2.0), the highest one if several sources use that version, and states the version next to it (for instance CVSS 3.1). The severity follows this score: Critical from 9, High from 7, Medium from 4, Low below (including vulnerabilities without a score).

What does a number like “5 (10)” mean? new

Linked vulnerabilities (the same flaw under several identifiers, see above) are now counted once. When this changes a number, the report shows both: first the number of distinct vulnerabilities, then, in brackets, the number of identifiers (CVE and GHSA) as before. When both are equal, a single number is shown.

Example: a version has 10 identifiers; 3 of them designate one same vulnerability, and 4 others another one. That makes 1 + 1 + 3 = 5 distinct vulnerabilities: 5 (10).

A group of linked vulnerabilities is counted in the most unfavourable status and severity of its members: it counts as Exploitable if one of them is, and as resolved only if all of them are. The boxes therefore always add up to the total number of distinct vulnerabilities. The cards themselves are unchanged: each identifier keeps its own card, in the part matching its own status.

How do the filters work?

Above the list, type an identifier or a word to search the cards, and untick statuses or severities to hide them. The counters of the two parts are updated with the visible cards. The filters also apply when printing.

What does the Components page show?

The Components page lists every third-party component embedded in the selected BlueMind version (the version menu works as on the report), as described by its SBOM:

• at the top, the number of components, the number of components with known vulnerabilities and the number of distinct licenses;
• for each component: its name and group, its version, its ecosystem (Maven, npm…, taken from its package URL), its license(s), its known vulnerabilities, its CPE / PURL identifiers and its description.

A red mark on the left of a line means that the component has at least one vulnerability still to address; a green mark, that all its vulnerabilities are resolved or do not affect BlueMind. The SBOM and VEX of the version can be downloaded from this page too.

These numbers count components, not vulnerabilities: the “5 (10)” rule does not apply here. A component affected by a vulnerability known under several identifiers lists each of them.

How do I find the components affected by a vulnerability?

• Type a CVE or GHSA identifier, or a component name, in the Filter components… box: the search covers all the columns.
• Tick Only components with known vulnerabilities, or click the number of components with known vulnerabilities, to hide the others; choose an Ecosystem to narrow the list further.
• Click a column header to sort, for instance on the Vulnerabilities column to see the most affected components first.

In the Vulnerabilities column, each identifier is coloured by severity (see score); a tick and lighter colours mean it is resolved or does not affect BlueMind. Hover over it to see its score and status, and click it to open its card in the report of the same version.

How do I search for a vulnerability?

The Search page looks for vulnerabilities across all the BlueMind versions at once (the active ones, unless Show outdated versions is ticked):

• type part of an identifier (CVE-2025-, GHSA-…) or words of the description, then press Search; an empty search lists every vulnerability;
• untick a status or a severity to hide those vulnerabilities; the number next to each filter counts the matching vulnerabilities, one per CVE or GHSA identifier;
• the results are sorted by score, the most severe first, 50 per page; click the Score, ID, Status or Published header to sort by that column, and click it again to reverse the order;
• click an identifier to open the page of the vulnerability: affected versions and fixes, scores, description, linked vulnerabilities and BlueMind's analysis (read only).

Why can't I find my CVE or GHSA in the search?

The search only lists the vulnerabilities detected in at least one BlueMind version (an active one, unless Show outdated versions is ticked), with the status and severity filters you ticked. If a vulnerability is still missing, there can be several reasons:

• it has not been imported yet: it is recent and Dependency-Track has not received it from its data sources yet, or this site has not imported it from Dependency-Track yet (see how often the site is updated);
• the vulnerability record is not precise enough: its CPE (Common Platform Enumeration) or its package URL (PURL) does not describe the affected component or its versions accurately, so it cannot be matched to the component embedded in BlueMind;
• the component has not been identified when BlueMind was built, despite all our efforts, so it is missing from the SBOM of the version.

To check it yourself:

1. open the Components page of the BlueMind version you use and search for the component: check that it is listed, and in which version (see what the Components page shows);
2. look up the vulnerability on the NVD (or on the GitHub Advisory Database for a GHSA identifier) and check whether the affected versions it mentions (its CPE configurations, or affected package versions) really include the version of the component embedded in BlueMind.

What are the SBOM and VEX files?

Both are CycloneDX JSON files, readable by most security tools, offered on the Report and Components pages for the selected version:

• SBOM: the list of the components of the version, as produced by Dependency-Track, without vulnerabilities.
• VEX (Vulnerability Exploitability eXchange): the vulnerabilities of the version with the BlueMind analysis of each of them (status, justification, recommendation, workaround), the affected components and the linked identifiers. It is generated from CVEManager when you download it, so it is always up to date; its component references match those of the SBOM.

How can I follow changes or share the report?

Subscribe to the RSS feed: one article per maintained version, updated whenever one of its vulnerabilities changes. The Print / PDF button of the report produces a compact document, which can be saved as PDF from the print dialog.