Issues, attack paths and exceptions¶

A finding is one failing check on one deployment. Everything on this page is about what you do with findings: group them into issues, see how they chain into attack paths, and record the ones you accept, snooze or suppress.

In the console, writers are analyst or administrator, and administrators are administrator only. See Organizations, projects and roles.

Issues¶

An issue tracks the work to fix a root cause. Issues live under Findings › Issues and are numbered UNT-1, UNT-2 and so on.

Create an issue¶

Writers create an issue from a finding's drawer or from the Live posture work queue. From the API:

curl -sS -X POST "https://app.untrustsecurity.com/v1/organizations/<org>/issues" \
  -H "Authorization: Bearer $UNTRUST_API_KEY" -H "Content-Type: application/json" \
  -d '{"report_id": "<report-id>", "check_id": "KMS-01"}'

The issue is assigned to you unless you name another owner, who must be an active member.

Grouping by root cause¶

untrust groups findings by root cause so one fix is tracked once:

The root cause is the governance policy the check, IaC rule or detection rule maps to, or the check id if it maps to none.
If an open issue already owns that root cause, a new request attaches to it instead of opening a duplicate.
An issue's members are every current live failure with that root cause: scanner checks across clouds, failing IaC rules in the newest receipt, and unresolved detections.
The issue's severity is its worst member's.
The drawer explains why the members were grouped.
Demo reports never attach to live work.

Statuses¶

Status	Meaning
Open	Planned, not started.
In progress	Someone is working on it.
Ready for verification	The fix is in; waiting for a scan to confirm it.
Closed	Closed after manual review. Closing needs a closure note.
Suppressed	Shown, not set: an accepted-risk exception covers the finding.

Any status can move to any other. If two people edit the same issue at once, the second save is refused and asks you to reload.

Each issue also shows the state of its check: still failing, fixed in latest scan, not re-checked, or not re-scanned. The Issues tab has views for all, open, mine, fixed and overdue issues.

Notes¶

Notes are plain text, 1 to 4000 characters, up to 500 per issue. Closed issues still take notes. Only a note's author can remove it, and removal leaves a marker.

SLA¶

Each issue has a due date set from its severity when it is created:

Severity	Due within
Critical	7 days
High	30 days
Medium	90 days
Low, info	No SLA

An issue reads on track, due soon (the last quarter of its window), breached, or met (closed on time). A breach is recorded once and raises the issue.sla_breached event; see Alerts and webhooks. Merged and duplicate issues are left out of SLA.

In an issue, reconcile it with another open issue:

Merge into this closes the other issue with "Merged into UNT-n".
Duplicate of this keeps the other issue open, but out of counts and SLA.
Link as related links the two without changing either.

Only open issues can be merged or marked duplicate, and merges do not chain. If a finding was grouped into the wrong issue, report the wrongly merged member from the drawer; the report is recorded in the audit log.

Bulk actions¶

Select 1 to 100 issues to Assign to… or Set status… (closing still needs a note). Each issue reports its own result: ok, conflict, not found or forbidden.

Attack paths¶

Trust Graph › Attack paths shows chains of checks that together give an attacker a way in. A chain is a fixed sequence of checks from untrust's catalogue. A link can require that it fails on the same resource as an earlier link, for example the same instance, bucket, KMS key or instance profile.

State	Meaning
active	Every link fails, on the same joined resources.
unverified	A resource the links should share is missing from the report.
unknown	A link has no result.
disjoint	The links fail, but on different resources.
broken	Some link passes. Break any one link and the whole chain collapses.

Paths are ranked by state, then severity, then the share of links failing. Platforms with no real report are listed under "Not evaluated · no real report"; demo reports are never evaluated.

Chains are evaluated each time a report arrives, against each deployment's current report:

A chain that becomes active opens. If it opens again after closing, that counts as a regression.
A chain that becomes broken or disjoint closes.
The chip on each path shows when it opened or was first seen, when it closed, and how many times it regressed.

When a path opens or regresses, untrust opens an issue on the chain's entry check. The issue is assigned to the member who registered the matching cloud connection, or left unassigned. A regression reopens that issue if it was closed or ready for verification. Closing a path does not close its issue: close the issue when the fix is confirmed.

Any role can read attack paths, in the console or with GET /attack-paths and GET /attack-paths/{id}.

Accepted risk (exceptions)¶

When you decide to live with a failing check, accept the risk instead of leaving it open. An exception covers one failing check on one deployment and carries over to newer reports of that deployment.

Who: writers, from a finding's drawer (Accept risk) or in bulk (Accept risk on N).
What: only a FAIL can be accepted, with one active exception per report and check.
Reason: 10 to 2000 characters.
Expiry: in the future and at most 365 days away. The console suggests 90 days.
States: active, expired or reopened. Extend works on an active or expired exception, not a reopened one. An exception expiring within 14 days is flagged as expiring soon.

What it changes:

The finding leaves the Open counts and appears under Findings › Accepted risk.
Its issue shows Suppressed.
It stays FAIL in compliance and never clears a release gate.
It is listed in evidence packs.

Exceptions are recorded in the audit log as exception.created, exception.extended and exception.reopened.

Snoozes¶

A snooze hides a finding for a short time without accepting it.

Who: writers.
How long: until a date, or until the next scan. At most 30 days, and at most 3 days for a critical finding. No reason is needed.
Wakes when the time runs out, when the finding recurs in a newer scan, or when it is resolved. Wake now wakes it by hand.
Bulk: Snooze N until the next scan, for 1 day or for 7 days.

A snooze is not an accepted risk: it changes nothing in compliance and does not pause the issue's SLA. Snoozed findings are under Findings › Snoozed.

Suppression rules¶

A suppression rule stops one check from raising findings where you know it does not apply. Administrators manage them under Findings › Accepted risk.

A rule names one exact check id, optionally narrowed to an account and to a resource, given exactly or as a prefix ending in *.
Attest and hardware stage checks cannot be suppressed.
High and critical checks must be narrowed to an account or resource.
A critical finding is never suppressed.
Each rule needs a reason of 10 to 2000 characters and an expiry at most 365 days away.
An organization can have at most 200 rules.

Rules are recorded in the audit log as suppression_rule.created, .updated, .revoked and .lapsed.

Detection mutes¶

A mute stops one noisy detection rule from alerting, under Runtime Detections › Suppressions.

Who: administrators create mutes; anyone can read them.
What: one rule_id and exactly one of an exact resource or an environment (aws:<account>, gcp:<project>, azure:<subscription> or fleet:<id>). If a resource mute and an environment mute both match, the resource mute applies.
Reason: 10 to 2000 characters.
Expiry: at most 90 days. There are no permanent mutes. The Suppressions tab flags mutes that expire within 3 days, and expiry is recorded as detection_mute.lapsed.
Limit: at most 200 active mutes. A duplicate of an active mute is refused.

A muted detection is still recorded and shown as suppressed, and it never alerts.

From a detection event's drawer, writers can also Resolve or Reopen it, Mark benign, or Open incident.

Custom rules¶

Custom rules add your own findings on top of the built-in ones. They only add findings; they never suppress a built-in rule. A rule starts as a draft, which is stored only, or in shadow mode, which reports matches but never gates.

Build and IaC rules¶

Under Source analysis › Custom rules or IaC scan › Custom rules:

A rule has a name, a surface (build or iac), a severity and a matcher.
Build matcher: a file path that equals or contains a value, or file content that contains a value.
IaC matcher: a resource_type, an attribute, and one of equals, not_equals, present, absent or contains.
Strings are up to 200 characters.
Writers create draft and shadow rules. Administrators edit and delete them.
Dry run a rule against a pasted sample: up to 20 files of 64 KB each, or up to 100 resources, 512 KB in all.
An organization can have at most 50 rules in shadow mode or beyond.

Test a rules file locally with --custom-rules on untrust buildscan or untrust iacscan; see CI gates:

untrust buildscan ... --custom-rules rules.json

Custom detection rules¶

Under Runtime Detections › Custom rules:

A rule has a name, the built-in rule it is based on, a severity and a matcher.
The matcher is a case-insensitive substring match on action, principal and resource, optionally narrowed by a minimum severity and an environment. It can require a threshold (up to 1000 events within up to 1440 minutes). It needs at least one constraint.
Validate & dry-run shows what the rule would have matched in the last 24 hours, whether it would have fired, and up to 5 sample events.
Writers create rules, which are saved in shadow mode.

Rule levels¶

Administrators set how each built-in build and IaC rule gates, on the Rules tab of Source analysis and IaC scan. The Mode column shows enforcing, warn, report or disabled (the picker says block, warn and report), and the Source tooltip says whether the level comes from a floor rule, the profile or an override. The profile selector sits above the table.

Levels apply to the whole organization; there is no per-project or per-pipeline profile. What each level and profile does, floor rules, and applying the same levels to pull-request checks are covered in CI gates.