On this page

Last updated: May 23, 2026

Vulnerabilities

Guara Cloud automatically scans every container image used by your services for known vulnerabilities (CVEs reported against the operating system packages and language dependencies inside the image) and surfaces the results in two places:

  • Account-wide vulnerabilities page at /security/vulnerabilities.
  • Vulnerabilities tab on every service detail page.

What gets scanned

Every container image that backs one of your services is scanned automatically:

  • Application services built from your source or pushed as Docker images.
  • Service catalog services (managed Postgres, Redis, NATS, and other catalog offerings). Guara scans the catalog images so you see what your dependencies are exposed to, even though you don’t manage their content directly.

Scans run when a new image is observed and on a regular cadence after that, so newly published CVEs are reflected without you having to redeploy.

What you see

Each vulnerability row shows:

FieldDescription
CVE IDThe canonical identifier (e.g., CVE-2025-12345).
SeverityCVSS-mapped: critical, high, medium, low, unknown.
PackageThe affected package and version inside the image.
Fixed inThe fixed version, if one is available upstream.
Affected servicesWhich of your services run this image and are therefore exposed.
First seenWhen this CVE first appeared in your account.

You can filter by severity, by service, and by whether a fix is available, useful for triaging “what can I actually fix today?” vs. “what’s pending upstream?”

Account-wide view

The account-wide page aggregates every CVE across every service. Use it for big-picture answers:

  • “How many criticals do I have right now?”
  • “Which services have the most unpatched CVEs?”
  • “Which CVEs have fixes available but aren’t deployed yet?”

This is the fastest way to see the state of your container security across the whole account in one place.

Per-service view

Every service detail page has its own Vulnerabilities tab, scoped to just that service’s current image. It’s the right surface when you’re investigating one service or before you cut a release.

The free Vulnerabilities tab on the service page is preserved exactly. Guara Shield does not rename it, gate it, or hide it.

How vulnerabilities relate to findings

Each material vulnerability also opens a Security Finding, with the same severity, the same lifecycle, and the same triage actions:

  • Acknowledge a known CVE you can’t fix yet.
  • Suppress until a date when you expect a vendor fix.
  • Resolve automatically when a later scan confirms the fix is gone.
  • Mark false positive if the CVE doesn’t apply to your usage.

This means the vulnerability surfaces and the unified findings inbox stay in sync, you can triage a CVE from either place.

When Shield adds correlation (a critical CVE on a service that is publicly exposed, for example), the related finding will reflect the elevated context. The base CVE row stays informational; the finding tells you “this one matters more right now.”

What we scan for

  • OS package CVEs, vulnerabilities in the base image’s package layer (Debian, Alpine, Ubuntu, RHEL UBI, distroless variants where applicable).
  • Language ecosystem dependencies, npm, pip, Maven, Go module, RubyGems, and similar manifests embedded in the image.
  • Image metadata posture, flags around the image config (running as root, missing health check) are reported as info severity, never inflated.

How to act on a finding

Most fixes come in one of three shapes:

  1. Rebuild the image so the base layer and dependencies pick up the patched versions. Most Guara Cloud builds re-pull base images on each build; for explicit control, see Build configuration.
  2. Bump a dependency in your package manifest to a fixed version.
  3. Suppress until the vendor publishes a fix, and revisit on that date.

Each finding’s remediation field includes the fixed version (if known) and a deep link back to the affected service.

Where to go next