Threat library: actors, malware, and vulnerabilities.

The threat library is the canonical catalog: one deduplicated entry per threat actor, malware family and vulnerability, shared across the platform. A single actor tracked under six different vendor names is one entry with six aliases, which is what makes name resolution possible at all.

Requires the threats.read scope. Some sub-resources need a second scope as well, following what each actually returns: the IOC endpoints also require iocs.read, while threat-events/ and stix/ also require threat-events.read, since the STIX bundle carries an occurrence layer, not indicators.

List entries

GET /api/v1/threat-library/{entity_type}/ where entity_type is one of threat-actors, malware, vulnerabilities or clusters.

curl "https://api.liberty91.com/api/v1/threat-library/threat-actors/?q=spider" \
  -H "X-API-Key: $LIBERTY91_API_KEY"

By default the list hides catalog entries that have nothing behind them yet: no description, no aliases, no ATT&CK identity, no linked reporting. Pass include_empty=true if you are mirroring the whole catalog rather than browsing it.

Entry detail

GET /api/v1/threat-library/{entity_type}/{id}/

{
  "id": "3e2d1c0b-...",
  "name": "Scattered Spider",
  "aliases": ["Muddled Libra", "Octo Tempest", "UNC3944"],
  "description": "...",
  "latest_development": "...",
  "actor_kind": "intrusion-set",
  "origin": "US/UK",
  "attack_id": "G1015",
  "target_sectors": ["telecommunications", "hospitality"],
  "target_countries": ["us", "gb"],
  "created_at": "2026-01-19T10:00:00Z",
  "tracking": {"tracked": true, "criticality": "high", "active": true}
}

tracking is the only per-account part of the response; the catalog entry itself is identical for every customer. It tells you whether your account tracks this entry and at what criticality; an entry you do not track reports {"tracked": false, "criticality": null, "active": false}.

Vulnerabilities carry severity intelligence

{
  "id": "...",
  "name": "CVE-2026-1234",
  "cve_id": "CVE-2026-1234",
  "cvss_score": 9.8,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/...",
  "cvss_version": "3.1",
  "epss_score": 0.97,
  "epss_percentile": 0.999,
  "kev_listed": true,
  "kev_date_added": "2026-07-02",
  "cwe_ids": ["CWE-502"],
  "last_enriched_at": "2026-07-28T02:00:00Z"
}

CVSS is severity, EPSS is the probability of exploitation in the next 30 days, and kev_listed means CISA has observed it exploited in the wild. Together they are a far better prioritisation signal than severity alone, since a 9.8 nobody exploits usually matters less than a 7.5 in KEV.

Sub-resources

GET /threat-library/{type}/{id}/techniques/     # dated ATT&CK observations
GET /threat-library/{type}/{id}/threat-events/  # occurrences it was named in
GET /threat-library/{type}/{id}/related/        # entities it co-occurs with
GET /threat-library/{type}/{id}/iocs/           # associated indicators
GET /threat-library/{type}/{id}/iocs/export/    # parented STIX bundle of those
GET /threat-library/{type}/{id}/stix/           # the entity as STIX

Techniques are dated, not scored

{"results": [
  {"technique_id": "T1566", "name": "Phishing",
   "first_observed": "2026-02-11T00:00:00Z",
   "last_observed": "2026-07-20T00:00:00Z"}
]}

Each technique is grounded in specific public reporting that described this actor using it, and carries when it was first and last seen. That is a different and more defensible claim than a co-occurrence score, and it lets you ask "what are they doing now" rather than "what have they ever done".

An actor may return few or no techniques. That means no public reporting has attributed techniques to them yet, not that they have none.

Linked occurrences are masked

threat-events/ returns the occurrences this entity has been named in, subject to the same entitlement rules as Threat Events: an occurrence reachable only through reporting you do not hold does not appear.

Clusters are account-local

clusters are your own groupings, not catalog entries. They are scoped to your account, carry no aliases or catalog identity, and have no canonical record, so the sub-resources above return 400 for them rather than an empty list you might read as "no techniques".

Frequently asked questions

How do I resolve a threat actor name another vendor uses?

Use the alias filter. One actor is known by many names across vendors, and the catalog maps them all to a single canonical entry, so ?alias=UNC3944 resolves to the same record as ?name=Scattered Spider.

Is the threat library shared across customers?

The catalog itself is global and identical for everyone. Your account's own view of an entry, whether you track it and at what criticality, travels in the tracking object on each record.

Why do the technique lists carry dates?

Techniques are derived from actual reporting, so each one carries when it was first and last observed for that actor rather than a static score.