Runtime Risk Signals

Runtime Risk Signals are curated risk signals the Shield derives from observed runtime state of your account. They answer questions like:

• “Is one of my workloads behaving like it’s been compromised or runaway, burning CPU or memory abnormally?”
• “Did I just expose a workload to the internet that also has known critical CVEs?”
• “Did the public-exposure surface of one of my projects just change in a risky way?”
• “Did a recent deploy roll out under risky context (skipped checks, rapid retries)?”

Each signal opens, updates, or resolves a Security Finding with source runtime_detection and category runtime.

The v1 signal set

The v1 rule set is deliberately small. Each rule is explicit, explainable, and operates on data Guara Cloud already collects for your account.

Resource abuse pattern

Flags a workload whose runtime resource use looks like abuse, sustained anomalous CPU or memory consumption against the workload’s own historical baseline. Common triggers include:

• A cryptominer or runaway loop in a service container.
• A regression in your application that suddenly pegs CPU after a deploy.
• A leaking process that climbs memory steadily until it OOMs.

The signal is a risk signal, not an exploit detection. It tells you “this workload is using resources in a way that often correlates with abuse or regression”, and you decide whether it’s malicious, buggy, or just a hot Friday.

Exposed vulnerable workload receiving traffic

Flags the dangerous intersection of two facts Shield already knows independently:

1. The workload has known critical or high CVEs in its container image.
2. The workload is publicly exposed and is actively receiving traffic.

This combination is the single most actionable shape in Shield: a known-vulnerable thing with hands on it. A critical CVE on a private internal service is a problem; a critical CVE on a public service that real users are hitting right now is a priority.

Risky public exposure change

Flags a sudden change in your public-exposure surface that looks risky in context:

• A previously-private service becomes public.
• A service that just had a brand-new critical CVE discovered also just opened a public endpoint.
• Public exposure expanded in a project right after a credential or configuration change.

The point of this rule is to catch the moment your attack surface grew, while the change is still fresh in your team’s memory.

Risky deployment context

Flags deploys that landed under context that historically correlates with incident:

• A burst of rapid redeploys with failing readiness checks (the “shotgun debugging” pattern).
• A deploy of a service with active critical findings.
• An unusual deploy pattern compared to the project’s history.

Deploys are never blocked by runtime risk; signals appear post-deploy so you can decide whether to redeploy or rollback. The signal is a passive marker so you can correlate findings to specific deploys when investigating.

What evidence each finding carries

Every Runtime Risk Signal finding includes:

• The rule name (one of the four above).
• The workload, project, and service it applies to.
• A bounded, structured snapshot of the observed signal, for example “rate of redeploys in the last 30 minutes” or “critical CVE count plus public exposure state.”
• Concrete remediation guidance for that specific rule.

Evidence is minimal by design. Platform internals stay platform-side, and Shield’s evidence stops at the curated signal data above. Process listings, syscall traces, file-access traces, DNS telemetry, log contents, application payloads, and secrets never appear in a finding.

Lifecycle

Like every Shield surface, runtime findings deduplicate on the underlying condition. If the same rule keeps firing on the same workload, Shield updates the existing finding’s last_seen_at instead of opening duplicates. Findings only resolve after the condition has been absent for multiple consecutive observation windows, to avoid flapping.

Runtime control stays with you

Shield reports risk signals so you can decide the action. Runtime control stays with you, Shield never pauses, restarts, isolates, or modifies your workloads. It writes findings; you act.

How signals interact with other Shield surfaces

Runtime Risk Signals are most useful in combination with other Shield data:

• A runtime signal that links to a Vulnerability finding gives the CVE urgency.
• A runtime signal during a recent deploy explains why a deploy might warrant rollback.
• A runtime signal on a workload that just appeared in Flow Logs at unusual rate gives the traffic shape context.

The Reports & Posture page aggregates runtime signals into your overall posture score.

Where to go next

• Triage the findings these signals produce: Security Findings.
• See the chronological events that fire alongside signals: Security Events (look for runtime_signal_observed).
• Get a plain-language read on a specific signal: Explain This Threat.