Managing Findings

Watch · 1:25How many of your security findings are actually real?

Record decisions on system-generated findings instead of deleting them.

Overview

Modules generate findings for you automatically:

• Exposures — security weaknesses detected on a component, security boundary, data flow, or data item.
• Countermeasures — defensive controls derived from a control's class.

These are system-generated: the platform re-derives them whenever the element's class or attributes change, and after a module update that changes the class's rules (see After a module update). Often you'll disagree with a specific finding for a specific situation — an exposure that doesn't apply to an internal-only tool, a control you've consciously decided not to implement, a finding the template raised by mistake. Deleting it doesn't help: the next time the model changes, the platform recreates it.

A disposition records your decision on the finding — a kind plus a written reason — so the finding stays visible but clearly marked, the decision survives re-derivation, and your reasoning is captured for the next reviewer.

A disposition does one of two things. Most kinds mute the finding: they record that it doesn't apply, isn't real, or has been waived, and the finding drops out of your live risk. One kind — Affirm — does the opposite: it records that the finding is real and you've confirmed it, and the finding stays live. See Affirming a finding and The finding lifecycle.

System-generated vs. your own findings

To take over a system-generated finding and edit it freely, Customize it (see Customizing a finding).

Disposition kinds

Pick the kind that matches your reasoning. Every disposition requires a reason.

Affirmed is the exception. Every other kind mutes the finding — it stops counting toward your live, residual risk. Affirming a finding keeps it live while still marking it as triaged: it's the difference between "this doesn't apply" (mute) and "yes, this is real, and I've confirmed it" (keep live, now clearly reviewed). See Affirming a finding.

Dispositions carry no severity colour-coding — the kind and the reason carry the meaning, and a disposed row keeps the quiet outlined chip whatever kind it holds. The Affirm action button is info-blue for both finding types. What it produces is colour-coded, and deliberately not the same for both — see Reading the lifecycle badges.

Disposing an exposure

Exposures live on the element they were detected on — a component, a security boundary, a data flow, or a data item.

1. Select the element and open its settings panel, then the Exposures tab. For a data item, open the Data dialog instead; it hosts the same panel.
2. On a system-generated exposure, click the dispose action (the shield icon) in the row.
3. Choose a kind, enter a reason explaining the decision, and Save.

The row now shows a disposition chip under the exposure name and sorts to the bottom of the list. To change the decision, open the dispose dialog again; to remove it, use Remove disposition in the dialog.

Disposing a countermeasure

Countermeasures live on the control they were derived from.

1. Open the Control dialog and select the Countermeasures tab.
2. On a system-generated countermeasure, click the dispose action (the shield icon).
3. Choose a kind (Not Applicable, False Positive, or Waived), enter a reason, and Save.

The countermeasure shows a disposition chip under its name. The Countermeasures tab shows a count badge — Countermeasures (N) — when one or more of its countermeasures need review (see below).

Affirming a finding (confirmed live risk)

Sometimes the right answer isn't to mute a finding — it's to confirm it. You've looked at the exposure, agree it's a real risk for this element, and want that decision on the record without making the finding disappear. Affirm is the one-click action for exactly that.

Affirm appears alongside the other finding actions (in the Exposures tab, the Data panel, and the Control dialog). Click it on a system-generated finding to record it as:

• Confirmed live risk — for an exposure you've reviewed and accept as a genuine, unmitigated risk, or
• Confirmed in place — for a countermeasure you've verified is actually implemented.

An affirmed finding stays live. Unlike the muting kinds, it still counts toward your residual risk — it's just now clearly triaged rather than unreviewed. You'll see a lifecycle cue on the row: a filled Confirmed risk badge on affirmed exposures, or a filled In place badge on affirmed countermeasures. They are toned differently on purpose — see Reading the lifecycle badges.

Add a note or review an affirmation

To revisit an affirmation — to refine the reason you recorded, or simply re-read it — open its Add note / Review action. This opens the affirm-edit dialog, where only the reason is editable. Editing the note never converts the finding into a muting disposition; an affirmed finding stays affirmed and live until you explicitly choose a different kind through the dispose action.

Affirm is not "re-affirm." Affirm is a decision kind that confirms a finding as a live risk. Re-affirm is a separate action that re-stamps an existing disposition of any kind to clear a stale flag. They are different — see When a disposition goes stale.

The finding lifecycle

Every finding sits in one of three lifecycle states. You don't set this state directly — the platform derives it from the finding's disposition and who recorded it, so the same rules apply everywhere a finding is shown.

Both pending and confirmed findings are live — they count toward your residual risk. The difference is review status: pending means "nobody has looked at this yet," confirmed means "someone reviewed it and stands behind it." Only disposed findings drop out of your live risk.

Each tab shows a pending count — for example Countermeasures (N) — so you can see at a glance how many findings still need a first look.

Reading the lifecycle badges

The lifecycle state is shown on the row as a badge. There are three cases, and the middle one is deliberately not the same for the two finding types:

Three things are worth understanding here.

Pending shows no badge on purpose. A model that has just been analyzed is all pending. Badging every row would make an untouched model look alarming when nothing is wrong yet. The backlog is surfaced once, as the per-tab pending count, rather than on every row.

Confirmed is green for countermeasures and red for exposures, and this asymmetry is the point. Both mean "reviewed and confirmed", but they confirm opposite things: a countermeasure you've verified is in place is good news, and an exposure you've confirmed as a live risk is bad news. A single neutral colour would flatten that distinction — the one place green is right in this UI is a control you have confirmed exists.

A confirmed exposure is red, not yellow. Yellow is reserved for the stale marker and the Review button, so a confirmed risk never reads as "this needs your attention again."

Disposed rows keep the quiet outlined chip whatever kind they carry — that is where the "no severity colour-coding" rule holds. It applies to dispositions, not to the lifecycle badge.

Subtlety: an affirmation only counts as confirmed when it carries an attributed author. An affirmation with no recorded author is treated as pending, not confirmed — a safeguard so that an unattributed affirmation is never mistaken for a reviewed decision.

When a disposition goes stale

A disposition reflects the model as it was when you set it. The platform flags it as stale when the model changes underneath it: the row gets a yellow marker and the dispose action becomes a Review button. Two changes do this:

• You change an instantiation attribute of the element — the kind of change that drives what findings the module derives.
• A save of the element changes the MITRE techniques or other references linked to a system-generated finding: the class's policy now emits different ones, or the save removes a link someone added to the finding by hand. The platform's own re-evaluation after a module update counts as a save here.

Stale means "the model changed underneath this decision — confirm it still holds." Click Review to:

• Re-affirm the disposition (the reason and decision still apply) — this clears the stale flag and re-stamps the existing decision, whatever kind it is. (This is not the same as Affirm, which records a finding as a confirmed live risk; re-affirm only refreshes a disposition you already set.) Or
• Change the kind or reason, or
• Remove the disposition entirely.

Adding or removing a MITRE technique on a user-authored finding, such as your customized copy, does not make any disposition stale.

After a module update

When a module is updated, the rules that derive an element's findings may change. The platform then re-evaluates, in the background, every element whose class rules changed, as if the element were saved with no changes. You don't need to do anything, and the element's attribute values stay as they are. Once it has run:

• New findings the module now derives appear, awaiting review.
• Findings the module no longer derives are removed, with their dispositions. An affirmation, a mute and its reason are removed with the finding.
• A dispositioned finding whose techniques or references changed is flagged stale. Click Review on it (see When a disposition goes stale).
• Your own findings are not touched, including customized copies, even when the original a copy came from is removed.

The first start after an upgrade to a release with this behaviour re-evaluates every element once, so expect these changes then too. Elements of some modules, such as modules served from a remote service, are not re-evaluated; their findings change when you next save the element.

Tip: to keep your own version of a live finding whatever a module update does to it, Customize it (below). Your copy stays when the original is removed.

Customizing a finding (editable copy)

When you want your own editable version of a system-generated finding — to adjust its content, references, or techniques — Customize it. Change techniques and references on the copy: the next save of the element resets a system-generated finding's techniques and references to what the class's policy emits.

1. On any live system-generated finding, click the Customize as an editable copy action (the duplicate icon).
2. The platform creates a user-authored copy (named … (custom)) attached to the same element, and marks the original as Superseded with a reason that references your copy.
3. Edit the copy freely. The original stays visible, marked Superseded, as a record of where the copy came from.

Live means pending or affirmed. An affirmed finding carries a disposition and still offers Customize — confirming a finding as real is exactly the moment you may want your own version of it. Only disposed findings hide the action: a muted finding has already been ruled out, so there is nothing to supersede.

If creating the copy succeeds but marking the original as superseded fails, you'll see a notice with a Retry option — your copy is already saved; retry only re-attempts the disposition.

Deleting your customized copy later flags the superseded original as stale, prompting you to decide what to do with it now that the copy is gone.

What you can't do

• You can't delete or edit a system-generated finding directly from the UI — dispose it, or Customize it and edit the copy.
• You can't dispose a user-authored finding — edit or delete it directly instead.

See also

• Security Analysis Workflow — running analysis and interpreting findings.
• Working with Security Controls — creating controls and attaching MITRE techniques.
• Issue Management Guide — turning findings into tracked work.