On this page

Last updated: May 23, 2026

Security Events

A Security Event is a chronological record of something security-relevant that happened on your account. Where Findings answer “what is wrong right now?”, events answer “what happened, and when?”.

Events are the security history of your account in one timeline.

What ends up in the timeline

Security Events cover the full lifecycle of every Shield capability, plus platform-level security-relevant moments. Examples you’ll see:

EventWhy it matters
vulnerability_scan_completedA container image scan finished, useful for confirming coverage and timing.
critical_vulnerability_detectedA new critical CVE just landed in one of your images.
service_scan_completedA bounded posture scan finished for one of your public service endpoints.
secret_exposure_scan_completedA secret exposure pass finished for a service’s configuration.
public_endpoint_enabledA service became publicly reachable. The single most common cause of accidental exposure.
public_endpoint_disabledA service stopped being publicly reachable.
finding_openedA new finding just opened, regardless of source.
finding_resolvedA finding was resolved, either by action or by automatic re-observation.
finding_suppressedA finding was suppressed (with the suppression reason in evidence).
runtime_signal_observedA runtime risk signal fired for a workload.
threat_explanation_generatedAn AI explanation was generated for a finding or event.

Why events and findings are different

A finding is current state. An event is history. Both are normalized, both share scopes (account, project, service), and they reference each other:

  • Most findings are created by an event. finding_opened is itself an event.
  • Some events are pure context. They don’t create a finding (for example, a clean scan completing).
  • One finding can collect many events over its lifetime: opened, acknowledged, re-observed, resolved.

This split means you can audit history without polluting your triage inbox, and you can triage your inbox without losing the audit trail.

Reading the timeline

The events page is paginated and filterable. You can narrow by:

  • Scope, account, project, or service.
  • Time range, last hour, day, week, custom.
  • Event type, for example, “show me every public_endpoint_enabled in the last 30 days.”
  • Source, narrow to one Shield capability.

Each event row shows when it occurred, what scope it touched, a short human-readable summary, and a link to the related finding when one exists.

Free baseline vs. expanded coverage

Security Events is intentionally framed as a free baseline Security page, separate from Guara Shield. Even if Shield were ever rolled back, the events timeline would remain available so every account keeps a security history.

Guara Shield expands what you see in the timeline:

  • Wider event coverage. Shield-only capabilities (service scans, flow log correlations, secret exposure, runtime risk signals) emit their own event types.
  • Correlation. Events from different sources can reference the same finding, so the timeline tells you the story of a single condition across multiple sources.
  • Explanations. threat_explanation_generated events let you trace which findings or events you’ve asked for an AI read on.

Today, all of this is included for every account. Shield is free for everyone.

What the timeline records

Events are intentionally lean, and the timeline records discrete occurrences with bounded, structured evidence. That means:

  • Evidence is structured and bounded. Each event carries the fields needed to understand it, with no raw request or response bodies.
  • Events are about discrete occurrences, not metrics. For metrics, see Observability.
  • Events reference your services and resources by identifier. They do not include the contents of your application logs.
  • Events are append-only. The timeline shows what’s currently retained; retention is bounded by what the timeline displays.

Project and service scope

Events also appear, pre-filtered, on the Security tab of every project and every service. Use those scopes when you want to investigate the history of one specific resource without the noise of the whole account.

See Project & Service Security.

Where to go next