Skip to content
Sencai.docs

Vulnerabilities

Security → Vulnerabilities (/gravity/security/vulnerabilities) lists known vulnerabilities (CVEs) found in your container images, so you can triage them without leaving the platform.

Where findings come from

Section titled “Where findings come from”

There are three sources, and a switch at the top of the screen chooses between them: Instances & manual, Registry images and External registries.

Registry images. Every container image pushed to your organization’s private registry is scanned with Trivy automatically when it is pushed, whether or not anything runs it, and again about weekly after that while a tag points to the image (the images inside a multi-platform image that a tag points to included), because new vulnerabilities are published every day. An image that no tag points to any more is not rescanned automatically. Findings belong to an exact image digest, and an image’s results show the date of the vulnerability data they were based on. You can scan an image again at any time with Scan again on its page in the registry. Nothing blocks a deploy - a scan reports, it does not refuse.

External registries. Images in a registry you run yourself and connected under Custom Registries are scanned when you ask - Test on an image, or a schedule - not on every push. The source lists the findings of the latest finished scan of each image, with the registry in a column, and its summary counts an image that was never scanned, was too large, or whose last scan failed as not covered rather than as zero. Decisions (Accept the risk, Mark as false positive, Reopen) are recorded here or on the scan page. See Scan images in your own registry.

Instances & manual. Sencai also scans the container images used by your active cloud instances, and keeps findings you added or imported by hand. These findings come from a separate scan of what is running, not from the registry, and the two sources can differ for the same image because they use different scanners and data.

Either way, a finding is one row: the image, the CVE ID, the affected package and version, a fix version if one exists, and severity.

What “no findings” means

Section titled “What “no findings” means”

A registry scan result is Clean only when the scan succeeded, found nothing, and had something to check - a recognized operating system or application packages. An image with no recognizable packages (a scratch image holding a single binary) shows Scanned - no packages found, cannot confirm the image is clean, and an image on an operating system that no longer receives security updates shows <OS> is end of life - results may be incomplete. An image that has not been scanned yet is shown as not scanned, never as zero. The summary shows coverage beside the counts, for example “3 critical in 12 of 13 images - 1 not scanned”. See What the statuses mean.

Severity model

Section titled “Severity model”

Findings are labeled Critical, High, Medium, or Low, matching the severity Trivy/Grype assigns to the underlying CVE. Registry findings can also be Unknown when the scanner has no severity for a CVE. Use the severity filter chips at the top of the table to narrow the list - each chip shows a live count.

Reading the table

Section titled “Reading the table”

Instances & manual

Column Meaning
Image The container image the finding was found in
CVE ID The vulnerability identifier
Package / Version The affected package and the version in the image
Fix Version The version that resolves it, if the scanner found one
Severity Critical / High / Medium / Low
Status Open, Accepted, or Fixed
Scanner Which tool produced the finding (Trivy or Grype)

Registry images

Column Meaning
Image The image in your registry; select it to open its page
Tag / digest The tag the finding was found under, or the digest when the image has no tag
CVE The vulnerability identifier
Package, Version The affected package and the version in the image
Fix The version that resolves it, if the scanner found one
Severity Critical, High, Medium, Low or Unknown
Decision Open, Risk accepted, or False positive

Above the table, the severity chips filter the list, each with a live count. With the top-bar organization switcher on All organisations, the registry list adds an Organisation column and covers every organization you can read security data in; organizations you cannot read are named, not silently left out.

For registry images, the table groups findings by CVE and package, and on the image’s page each finding lists the places in the image where the package was found. A finding that existed in the previous tagged version and is gone now shows Fixed in <digest> on the image page.

Triage workflow

Section titled “Triage workflow”

Each open finding has two possible actions:

  • Accept Risk - marks the finding as Accepted. Use this when you’ve reviewed a finding and decided not to act on it right now (for example, the affected code path isn’t reachable in your deployment). This is a one-click action today - it doesn’t currently prompt you for a written justification, so if your organization needs a documented reason, record it separately (for example, as a note on the related change or ticket).
  • Mark Fixed - available on both Open and Accepted findings. Use it once you’ve rebuilt or replaced the image with a version that resolves the CVE.

For registry images, decisions are recorded on the image’s page in the registry (Decide next to a finding): Accept the risk and Mark as false positive need a written reason, and an accepted risk can have an expiry date. The decision applies to that vulnerability and package in that image and survives new pushes and rescans. The registry table here only shows the decision.

There’s no bulk action - findings are triaged one at a time, which keeps the audit trail specific to each decision.

How findings relate to patches

Section titled “How findings relate to patches”

This screen covers container images, not the operating system packages installed on your fleet-enrolled hosts - those are tracked separately under Patching. If a finding here points to a base-image package rather than something your own build introduced, the fix is usually to rebuild from an updated base image rather than patching a running container in place.

Registry images are the ones you push to your organization’s registry; see Container registry for how to push and how to read the statuses, and Image signing and verification for proving which image you deployed.

What’s next

Section titled “What’s next”