The vulnerability lifecycle

Every unified vulnerability carries a lifecycle state on each affected asset. The state answers "where does this stand?" — untouched, claimed as fixed, exempted, mitigated, or closed — and it lives in JupiterOne rather than in any single scanner console. You no longer reconcile status across five tools, and you no longer lose a risk acceptance because a scanner ran again.

Two ideas explain almost everything about how the lifecycle behaves. Read the next two sections once and the rest of the model follows.

Evidence and decisions are tracked separately

For every vulnerability on every asset, JupiterOne records two independent things:

• What scanners observe — is at least one configured scanner currently reporting this vulnerability on this asset? This is evidence. It updates automatically as your integrations run, and nobody can edit it.
• What your team has decided — the lifecycle state. This is a decision. It changes only through an explicit action by a person, a translated Jira ticket closure, or one of a small set of automatic rules described below.

Keeping the two apart is what makes the lifecycle trustworthy in both directions. A scanner that keeps reporting a vulnerability you marked as a false positive does not overturn your decision — the evidence is still recorded and visible, but the decision stands. Equally, a decision never erases evidence: the raw findings remain in the Source tab, exactly as reported.

When a state change surprises you, ask which of the two records moved. Almost every "why did this happen?" question about the lifecycle is answered by that distinction.

State is per asset

The lifecycle state belongs to a (vulnerability, asset) pair, not to the CVE. The same CVE can be Fixed on one host, an accepted risk on a second, and still Open on a third — the state of one never bleeds into another. Bulk actions exist so that deciding per asset does not mean clicking per asset.

The eight lifecycle states

The vocabulary is small, and it has a shape: one working state, one verification gate, one attention state, and five closed states that each answer "why is this closed?" differently.

Role	State	Meaning
Working	Open	A scanner reports it and no decision has been made yet. Every vulnerability starts here — and returns here if a decision is revoked or contradicted by evidence.
Verification gate	Awaiting verification	Someone claimed a fix, and JupiterOne is waiting for scanners to confirm it. Confirmed fixed when the scanner stops seeing it. Not closed yet.
Attention	Review required	An exemption expired. A person must re-affirm it, revoke it, or close the vulnerability another way. Never counted as closed.
Closed	Fixed	The vulnerability is gone from the asset.
Closed	Mitigated	The vulnerability is still present, but a compensating control contains it.
Closed	Accepted risk	The vulnerability is real, and the business accepts it for a defined period.
Closed	Non-exploitable	The vulnerability is present but cannot be exploited in this environment, for a defined period.
Closed	False positive	The scanner was wrong.

Who moves it:

Action someone takes Happens automatically

Select any state to see what it asserts, its ways in and out, and what happens when a scanner detects it again.

Solid transitions are actions someone takes — you in JupiterOne, or a translated ticket closure. Dashed transitions happen automatically, and each one stays visible: automatic reopens are recorded as system actions on the vulnerability's lifecycle timeline, and expired exemptions wait in Review required rather than changing silently.

Claim a fix, then let the scanner verify it

JupiterOne does not take anyone's word that a vulnerability is gone — including yours. Remediation is a claim, and scanner evidence is the verification:

1. Apply the fix, then select Mark remediated. The state moves to Awaiting verification. This is a claim, not a close.
2. Your scanners keep running on their normal schedule. As long as any scanner still reports the vulnerability, it stays in Awaiting verification.
3. When every scanner has stopped reporting it for 14 days and the asset itself is still reporting in, the vulnerability appears in the Inbox under No longer observed. Confirming it there closes the vulnerability as Fixed with fix confidence confirmed — a claim that evidence validated.
4. If scanners still report the vulnerability 14 days after the claim, it appears in the Inbox under Claimed, still observed, so you can reopen it or investigate the failed fix instead of believing a fix that did not work.

You can also select Mark fixed to close a vulnerability immediately. JupiterOne records fix confidence with every close: confirmed when a claim was standing (the vulnerability was Awaiting verification when it closed), assumed when nobody had claimed a fix. Either way, a fixed vulnerability that resurfaces after it had genuinely disappeared reopens automatically. The executive dashboard reports reopens split by fix confidence, so verified remediation and optimistic closing never blur together.

tip

Mark remediated and Awaiting verification are about the fix, not the work. Claim a fix after you apply it — not when you pick up the task. Work-in-progress tracking belongs in the linked Jira ticket; JupiterOne reflects the ticket on the case.

When a scanner detects a closed vulnerability again

Each closed state is a different kind of claim, and each answers to the referee that can actually test it:

• Fixed claims the vulnerability is gone. A scanner can prove that wrong, so Fixed — and only Fixed — reopens on re-detection.
• Mitigated claims a control contains it. Scanners are expected to keep seeing a mitigated vulnerability (the control limits exploitability; it does not remove the finding), so re-detection means nothing here. The health of the linked control is the referee instead.
• Accepted risk, Non-exploitable, and False positive are human judgments. No scan result can prove a judgment wrong, so scanners never touch these states. Time and people are the referees: exemptions expire into review.

Closed as	Scanner detects it again	Linked control fails	Exemption expires
Fixed	Reopens automatically	—	—
Mitigated	Stays mitigated (expected)	Reopens automatically	—
Accepted risk	Stays accepted	—	Moves to Review required
Non-exploitable	Stays non-exploitable	—	Moves to Review required
False positive	Stays false positive	—	—

The automatic reopen is deliberately narrow: it fires only for Fixed, and only when the vulnerability had genuinely disappeared (quiet for at least 14 days) and then came back — a regression, not scanner noise. Reopens are evaluated several times a day and record a system-attributed entry, with a justification, on the vulnerability's lifecycle timeline.

Exemptions expire to review, never to silence

Two states are exemptions, and both carry an expiry date:

• Accepted risk — requires a justification; JupiterOne records the acting user as the approver. Default expiry: 90 days.
• Non-exploitable — requires a justification. Default expiry: 90 days, with 180 days as a one-click preset. Non-exploitable closures arriving from a Jira ticket default to 180 days.

When an exemption expires, the vulnerability moves to Review required. It does not silently reopen, and it does not quietly stay closed — it waits, visibly, for a person. The lapsed exemption is preserved so the reviewer can see exactly what was approved, by whom, and why. From Review required you can:

• Re-affirm — renew the same exemption with a fresh expiry date, defaulting to the original exemption's duration
• Re-open — return the vulnerability to Open
• Close it another way — Fixed, a different exemption, or False positive

Exemptions approaching expiry appear in the Inbox under Expiring soon before they lapse.

Mitigations follow their control

Mark mitigated requires linking a Continuous Control Monitoring control that is currently passing — you cannot mitigate against a control that is already failing. From then on, the vulnerability answers to that control:

• If the control starts failing, is retired, or is deleted, the vulnerability reopens automatically, and the lifecycle timeline shows which control lapsed.
• If the control recovers, the vulnerability does not re-mitigate automatically — a person re-asserts the mitigation.
• Switch control relinks an existing mitigation to a different passing control without reopening it.

Because a mitigated vulnerability is still present by definition, scanner re-detection has no effect on it.

Who changes state, and who wins

Three actors can change a lifecycle state, in strict order of authority — person, then ticket, then automation:

• People in JupiterOne hold the highest authority. State transitions require graph-write permission and are recorded with the acting user. No ticket or automatic rule ever overrides a decision a person made in JupiterOne.
• Linked Jira tickets propose transitions through the resolution mapping. A ticket closure that conflicts with a person's decision is refused and surfaces in the Inbox as a Ticket disagreement, where you choose Adopt ticket or Keep J1.
• Automation — exemption expiry, control regression, and the re-detection reopen — acts only in the narrow cases described above and never overrides a person.

Every transition, from any actor, is recorded on the vulnerability's lifecycle timeline: who, when, from and to which state, and the justification. Bulk actions record one entry per vulnerability under a shared batch, so audits reconstruct exactly what happened. There is no undo for bulk actions — each one shows a confirmation with the exact count — and, for Mark fixed, the per-row confidence — before it applies, and every applied change can be reversed through a normal transition.

Common questions

I marked a vulnerability as a false positive, and the scanner still reports it. Why does JupiterOne still show my decision? Because that is the design. Judgments answer to people, not scanners. The finding remains visible in the Source tab, and the observation is recorded on the pair, but your decision stands until a person changes it. If the scanner keeps reporting it, fix the detection at the scanner — JupiterOne will not churn your triage.

Why did a Fixed vulnerability reopen on its own? A scanner observed it again after it had been gone for at least 14 days. Fixed is the only state that reopens on re-detection, the reopen is recorded as a system action with a justification on the lifecycle timeline. If it reopens repeatedly, the fix is not holding — check the reopen history on the lifecycle timeline.

My Jira ticket is Done, but the vulnerability shows Awaiting verification. Is the sync broken? No — this is verification working. Ticket closures resolved as Patched or Done are treated as claims, exactly like Mark remediated, and once scanners stop seeing the vulnerability, the Inbox proposes the confirmed close. A closed ticket whose vulnerability keeps being detected appears under Claimed, still observed in the Inbox.

Why can I not accept risk on a vulnerability that is Awaiting verification? A pair either awaits fix verification or carries an exemption — never both. Select Re-open to withdraw the claim first, then raise the exemption from Open.

A vulnerability disappeared from my scanners, but its state never changed. Why? JupiterOne proposes; you decide. Vulnerabilities your team has acted on move to the Inbox under No longer observed for a bulk Mark fixed — they are not closed behind your back. Vulnerabilities nobody ever acted on simply leave the views when their findings disappear, because there was no decision to preserve.

Two scanners report the same CVE on one asset. One of them stopped seeing it. Will the vulnerability verify as fixed? No. Evidence is the union of all sources — a vulnerability counts as observed while any scanner still reports it. One source going quiet (or being removed) never closes anything on its own.

Query lifecycle states with J1QL

Lifecycle states are graph entities, so everything above is queryable. For example, to list every accepted risk:

FIND VulnerabilityState WITH resolution = 'RISK_ACCEPTED'

Internal values are uppercase (OPEN, IN_PROGRESS, RESOLVED, REVIEW_REQUIRED for status; FIXED, MITIGATED, RISK_ACCEPTED, NOT_EXPLOITABLE, FALSE_POSITIVE for resolution), while the UI shows the display labels described above — IN_PROGRESS displays as Awaiting verification. A vulnerability nobody has acted on has no state entity yet and is treated as Open.

The Inbox

The Inbox is the decision queue for the vulnerability lifecycle. Scanner signals, expiring exemptions, and ticket conflicts all land here as proposals for a person to confirm — in bulk, with full context — rather than as silent state changes.

Section	What lands here	The action
Needs decision today	Exemptions at or past their expiry date	Re-affirm per row, or open the vulnerability to re-open it or close it another way
Expiring soon	Exemptions approaching expiry	Re-affirm early, or let them come due
Ticket disagreements	Jira closures that conflicted with a decision made in JupiterOne	Adopt ticket or Keep J1
No longer observed	Vulnerabilities your team has acted on that no scanner has reported for 14 days, on assets that are still reporting in	Bulk Mark fixed — each row shows whether the close will be confirmed or assumed
Claimed, still observed	Fixes claimed more than 14 days ago that scanners still detect	Bulk Reopen, or investigate the failed fix
Asset not reporting	Quiet vulnerabilities — open or claimed — whose asset has not been inventoried by any source for 7 days	Informational — verification cannot proceed until the asset reports again

Bulk actions are atomic per batch and capped at 100 vulnerabilities per action, and every row records its own lifecycle timeline entry. The bulk Mark fixed button shows the confidence split before you commit — for example, "Mark fixed (4) — 1 confirmed · 3 assumed".