Security advisories

A security advisory is a published security warning from a vendor, a CERT or a standards body. It is catalog content, not your data: the advisory says “this flaw exists in this product”, while a vulnerability record in the Risk section says “we are exposed to it, here is our deadline”. Keeping them apart means the same advisory can back exposures on a dozen assets without being copied.

Where to find it

Catalog → Security advisories in the sidebar.

Key concepts

Sources

Every advisory declares where it came from:

• CVE — the MITRE and NIST CVE Program identifiers, the familiar CVE-YYYY-NNNNN form.
• EUVD — the EU Vulnerability Database, the European equivalent established under NIS2.
• GHSA — GitHub Security Advisories, which often move faster than CVE for open-source packages.
• Other — anything that fits none of the above, including vendor bulletins.

Aliases cross-reference the same flaw under other identifiers, so a GHSA entry and its CVE resolve to one record rather than two.

The fields that drive prioritisation

Severity alone is a poor queue. The catalog carries three signals, and they answer different questions:

Field	Answers
CVSS base score and CVSS vector	How bad is this if exploited?
EPSS score and EPSS percentile	How likely is it to be exploited in the next 30 days?
Actively exploited, with KEV date added	Is it being exploited right now?

A high CVSS with a negligible EPSS is a different problem from a mid-range CVSS that is on the known-exploited list. The Actively exploited flag is the one to sort by first — it is a statement of fact rather than a prediction.

Alongside these, an advisory carries a Reference ID, Name, Description, Published date, external references, its source Library, a Domain and Labels.

Where advisories come from

Advisories are library-backed catalog content, published at the root so every domain can reference them. Two mechanisms keep the catalog current:

• Loading a library brings in a body of advisories in bulk.
• Enrichment feeds keep the scoring fields fresh without manual data entry. Three can be enabled independently in settings: the KEV feed, which flags advisories under active exploitation; the EPSS feed, which attaches exploitation likelihood; and NVD enrichment, which pulls additional metadata including weakness categories. A network timeout is configurable alongside them.

Note

The feeds reach public services on the internet. If your deployment is isolated, expect the enrichment fields to stay empty and prioritise on CVSS and your own knowledge of exposure instead.

Working with advisories

Filter by source, domain and labels; sort by CVSS or EPSS to build a working queue. The columns are chosen so the list can be read as a triage surface rather than a reference work.

The real connection point is the vulnerability record. A vulnerability links to one or more advisories and to one or more CWEs, and inherits their context — which is what lets SLA policy anchor on either the date you detected the exposure or the date the advisory was published, and what lets you answer “how many of our open exposures are known to be exploited”.

Tip

Resist the urge to record every advisory as a vulnerability. The catalog is meant to be broad; your vulnerability list should only contain things you are actually exposed to, or it stops meaning anything.

Related

• CWEs — the weakness classes advisories are categorised under.
• Risk assessments — where exposure is evaluated and treated.
• Libraries — where advisory catalogs are loaded from.