> For the complete documentation index, see [llms.txt](https://intuitem.gitbook.io/ciso-assistant/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://intuitem.gitbook.io/ciso-assistant/concepts/risk/vulnerabilities.md).

# Vulnerabilities

Catalogued weaknesses tracked through detection, triage, and remediation

A **vulnerability** is a weakness in a system, process, or product that could be exploited to compromise confidentiality, integrity, or availability. CISO Assistant tracks vulnerabilities as first-class objects, separately from the **incidents** they may cause and the **risk scenarios** they feed into.

The vulnerability surface answers two operational questions: *what's exposed* and *are we treating it fast enough?*

## Mental model

```mermaid
graph LR
  D[Domain] -->|scopes| V[Vulnerability]
  V -->|affects| A[Asset]
  V -->|mitigated by| AC[Applied control]
  V -.->|advised by| SA[Security advisory]
  V -.->|tagged with| CWE[CWE]
  SLA[SLA policy] -.->|sets due date| V
```

A vulnerability sits inside a domain and points outward at what it affects (assets) and what's treating it (applied controls). Threat-intel feeds enrich it asynchronously — KEV/NVD/EUVD feeds attach security advisories, NVD enrichment tags it with CWEs. The vulnerability SLA policy is a single platform-wide setting that maps severity to a deadline: when severity changes and no explicit due date has been set, the platform recomputes the due date from the policy.

| User-facing       | Internal                              | Notes                          |
| ----------------- | ------------------------------------- | ------------------------------ |
| Vulnerability     | `Vulnerability`                       | First-class object             |
| Security advisory | `sec_intel.SecurityAdvisory`          | Ingested from KEV / NVD / EUVD |
| CWE               | `sec_intel.CWE`                       | Common Weakness Enumeration    |
| SLA policy        | `GlobalSettings("vulnerability-sla")` | Severity → days mapping        |

## What a vulnerability captures

* **Identification** — a name, an optional reference ID (typically a CVE), a description.
* **Severity** — the shared scale (undefined / info / low / medium / high / critical).
* **Status** — undefined, potential, exploitable, mitigated, fixed, not exploitable, unaffected.
* **Affected scope** — the assets exposed, and the entities (third parties) involved when relevant.
* **Treatment** — linked applied controls (the remediations), security exceptions (formal deviations), CWE entries, and one or more security advisories.
* **Timing** — detection date, publication date, ETA, and the SLA due date computed from the severity-driven policy.

## SLA-driven due dates

Vulnerabilities are unusual in that the platform sets a **due date** automatically based on severity, via the [Vulnerability SLA policy](/ciso-assistant/configuration/settings/vulnerability-sla.md). The flow:

1. A vulnerability is created (or its severity changes).
2. If no explicit due date is set, the SLA policy is applied — high severity gets a tighter deadline than medium, and so on.
3. The bulk "refresh due dates" action re-applies the policy across existing rows when the SLA configuration changes.

Explicit due dates the user (or an import) sets are preserved — the policy only fills in the blank.

## Threat-intelligence enrichment

Vulnerabilities don't live in isolation. CISO Assistant can pull from external feeds to enrich them automatically — see [Security intelligence feeds](/ciso-assistant/configuration/settings/sec-intel-feeds.md):

* **KEV feed** flags vulnerabilities confirmed exploited in the wild.
* **EPSS feed** attaches a probabilistic exploitation score.
* **NVD enrichment** pulls CWE mappings, affected configurations, and references.

These enrichments link a vulnerability to its **security advisory** and **CWE** entries, making severity triage less guesswork.

## Lifecycle

```
detected → triaged → treated (mitigated / fixed / exception / accepted) → closed
```

The status field captures where each vulnerability sits in that flow; the linked applied controls and security exceptions explain *how* it's being treated.

## Related

* [Applied controls](/ciso-assistant/concepts/operations/applied-controls.md)
* [Incidents](/ciso-assistant/concepts/operations/incidents.md)
* [Risk assessments](/ciso-assistant/concepts/risk/risk-assessments.md)
* [Vulnerability SLA policy](/ciso-assistant/configuration/settings/vulnerability-sla.md)
* [Security intelligence feeds](/ciso-assistant/configuration/settings/sec-intel-feeds.md)
* [Vocabulary → Vulnerability / Security advisory / CWE / Severity](/ciso-assistant/introduction/vocabulary.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://intuitem.gitbook.io/ciso-assistant/concepts/risk/vulnerabilities.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.