On this page

Last updated: May 23, 2026

Security Findings

A Security Finding is a single security-relevant condition you can review, act on, suppress, or resolve. Findings are the centerpiece of Guara Shield. Every source (vulnerabilities, service scans, flow logs, secret exposure, runtime risk signals) writes to the same finding model, with the same lifecycle and the same triage actions.

If you only ever learn one Shield surface, learn this one.

What a finding contains

Every finding carries the same fields, regardless of which source produced it:

FieldWhat it tells you
TitleA short, human-readable name (e.g., “Broad CORS on public endpoint”, “Critical CVE in container image”).
SourceWhich Shield capability produced it: vulnerability scan, service scan, flow log, secret exposure, runtime detection, or AI explanation.
Severitycritical, high, medium, low, or info.
ConfidenceHow sure Shield is about this finding: high, medium, or low. Useful for filtering out noisy detectors.
StatusWhere in the lifecycle it sits, see below.
ScopeAlways tied to your account; optionally narrowed to a project and a specific service.
EvidenceStructured, bounded, redacted evidence, never raw bodies, packets, secrets, or unbounded logs.
RemediationConcrete guidance on what to change. Some findings include direct links to the affected service or setting.
First seen / last seenWhen Shield first noticed this condition and when it last reconfirmed it.

The lifecycle

Findings move through a small, explicit state machine:

 open  ─►  acknowledged  ─►  resolved
   │                            ▲
   ├──►  suppressed (until …)  ─┘
   └──►  false_positive
  • open, newly observed. Counts toward your posture score.
  • acknowledged, someone on the team has seen it and accepted it as real, but hasn’t fixed it yet. Stays counted.
  • resolved, the underlying condition is gone. Either you fixed it and a later scan confirmed the fix, or the affected resource was deleted.
  • suppressed, you’ve explicitly hidden the finding, optionally until a date. Useful for known-and-accepted risks or third-party issues you can’t fix today.
  • false_positive, the finding was wrong. Suppressing as false-positive helps tune the detectors over time.

Severity guidance

Shield assigns severity from the source’s own scoring, not from a single global heuristic. A few examples:

  • Vulnerability findings inherit CVSS severity from the vulnerability database, capped by image exposure (a critical CVE in an unreachable internal service is still reported critical, but Shield’s correlation may downgrade urgency if the workload has no external traffic).
  • Service scan findings are mapped to severity based on the specific check. Broad CORS is high, missing X-Content-Type-Options is low on HTML endpoints, and platform-controlled gaps are recorded as context, not findings.
  • Runtime risk signals weigh observed evidence (e.g., a vulnerable workload receiving traffic is higher severity than a vulnerable workload at rest).

Triage actions

Every finding row supports the same actions:

ActionWhen to use it
AcknowledgeYou’ve seen it; you’ll get to it; don’t surface it as new again.
ResolveThe underlying issue is fixed. Shield will reopen the finding if a later scan re-observes it.
Suppress until …Hide it for a defined window. Good for vendor-fix-pending CVEs or planned deprecations.
Mark false positiveThe detector was wrong. Helps tune the detector and silences it for the same condition going forward.
Explain this threatOpen an AI-generated, plain-language explanation of the finding. See Explain This Threat.

Triage actions are optimistic, the UI updates immediately. If something goes wrong server-side, you’ll see a clear error and the row reverts.

Evidence and remediation

Each finding includes a structured evidence object, a bounded list of typed evidence items (a sampled header, a hostname, an image reference, a workload name) plus a short summary. Evidence is intentionally limited in size and always redacted:

  • No raw HTTP request or response bodies.
  • No packet payloads.
  • No raw secret values, even if the finding is about a secret exposure.
  • No unbounded logs or high-cardinality telemetry.

Remediation is a separate, structured field with actionable guidance. Where Shield can deep-link to the affected service, project, environment variable, or deploy, the remediation will include that link.

Deduplication

The same condition only opens one finding. If a service scan finds broad CORS on the same endpoint check-after-check, Shield updates the existing finding’s last_seen_at instead of creating duplicates. This keeps the inbox honest: every row represents a distinct, current condition.

If the condition disappears (a later scan no longer observes it), Shield resolves the finding automatically. You’ll see it move to resolved in the timeline.

The findings inbox supports filtering by:

  • Scope, account, a specific project, or a specific service.
  • Severity, multi-select.
  • Status, including hiding suppressed and resolved by default.
  • Source, narrow to one capability at a time.

Combine filters to focus on, for example, “open high and critical findings from service scans on production projects only.”

Project and service scope

Findings also appear on the Security tab of every project and every service. The list there uses the same component as the account inbox, pre-filtered to that scope. See Project & Service Security for the full wayfinding map.

How findings fit your workflow

Findings live in your triage inbox. Paging is opt-in: you choose which findings escalate to notifications. Shield records finding state changes as Security Events, which you can route through your notification preferences elsewhere on Guara Cloud.

Findings are a record of current security-relevant conditions, not a queue you must zero. Some findings are accepted risk, some are vendor-pending, some are platform-controlled. The goal is honest awareness and disciplined triage.

Where to go next