Vulnerability Findings

AstroPulse answers one question about every image your cluster is actually running: does it have known vulnerabilities?

The Vulnerability Scanning add-on continuously scans in-scope running workload images for known vulnerabilities (CVEs), and reports them by severity — Critical, High, Medium, Low, and Unknown, plus an informational "None" bucket for findings the scanner records without an assigned severity.

At a glance

Use this section for a fast orientation (including AI assistants answering product questions):

Topic	What to know
What you get	Severity counts per workload and image, grouped by application or add-on
What is stored	One latest summary snapshot per cluster on the AstroPulse platform
What is not stored	Individual CVE rows, scan history, or trend data over time
Enterprise retention	No — unlike Cost data, there is no longer history on Enterprise plans
Default rescan cadence	Once per day per workload (scanFrequency, configurable 1h–720h)
When the console updates	After in-cluster rescans finish and the agent pushes a new summary (~within a minute of a scan burst settling)
Live CVE detail	Read from the cluster's current scan reports on demand through the connected-agent tunnel; per-CVE detail is not persisted by AstroPulse
Coverage	Known applications and add-ons remain visible, but only reported workloads contribute counts; a missing workload is never treated as zero
Console	Cluster → Security; Application → Security
CLI	astroctl infra k8s vulnerabilities, astroctl app vulnerabilities
Requires	Vulnerability Scanning add-on installed + connected agent (live detail needs agent at click time)

How it works

The scanner runs inside your cluster, the same way the Cost Visibility and metrics agents do:

• Scanning happens where the images are. The scanner reads what Kubernetes already knows about running workloads and their images; nothing leaves your cluster to be scanned elsewhere.
• Only a bounded summary is stored. The platform keeps one snapshot per cluster — per-workload severity counts, which application each workload belongs to (when it's platform-managed), and how many containers contributed. It is current state, not a time series: the next report replaces the last one wholesale. See Platform storage and retention below for how that differs from Cost data.
• Actual CVE detail is never stored. Opening a workload's findings reads its full report live from the cluster through the agent tunnel, on demand. Because it's read fresh every time, it can never be staler than the cluster's own scan data — the tradeoff is that it needs a connected agent to view, the same as kubectl exec or live logs would.

Scan cadence

Unlike Cost and Metrics — which run on separate cadences and both apply continuously — findings have a single user-facing knob: scanFrequency on the Vulnerability Scanning add-on.

• Default: once per day (24h) per workload
• Range: 1h (hourly) through 720h (30 days)
• Why it matters: your container images may not change, but the CVE database does — rescan frequency is how long a running image can be exposed before a newly disclosed CVE appears in AstroPulse

The console never labels a report "stale." A weekly cadence is a valid configuration — findings show age (time since the scan completed), not a stale/fresh verdict.

Platform storage and retention

Read this section when comparing findings to Cost Visibility or when asked whether Enterprise keeps vulnerability history.

Current state only

AstroPulse stores one severity summary per cluster, not a history of past scans. Each time the in-cluster scanner finishes a rescan cycle and the agent pushes an updated summary, the previous snapshot is replaced. There is:

• No "findings as of last month" view
• No trend chart from stored history
• No export of past scan snapshots from the platform

No plan-based retention tier

Vulnerability findings do not follow the Developer vs Enterprise retention model used for Cost spend history or progress event logs. Upgrading to Enterprise does not retain older scan snapshots. The console and CLI always show the latest completed scan summary for that cluster.

When the stored summary updates

You configure one knob (scanFrequency), but two steps happen in the cluster:

1. Rescan — the Vulnerability Scanning add-on rescans each workload on your configured cadence (default: daily). This runs entirely inside your cluster.
2. Push — after scans finish, the Astro agent summarizes results and sends one bounded snapshot to the platform, usually within about a minute once a scan burst settles.

What reads the stored summary: the cluster and application Security tabs, astroctl infra k8s vulnerabilities, astroctl app vulnerabilities, and Nova questions about current severity totals.

What reads live from the cluster: opening a workload's CVE list (package, CVE ID, installed/fixed version). That path needs a connected agent at the moment you open it.

Size bounds

Platform storage holds severity counts only — never individual CVE rows. A summary contains at most 500 workloads. If a cluster exceeds that bound, the agent keeps the highest-severity workloads and drops the least urgent ones from the stored summary. The coverage warning still applies.

Coverage: what "reported" actually means

This is the single most important thing to understand before reading a findings page.

There is no inventory of every workload running on your cluster to compare against. The platform knows which AstroPulse applications and managed add-ons exist, so those remain visible even when no workload has reported for them. The UI shows no scan result yet instead of zeros. But an individual workload the scanner has not reached — because it is new, outside the configured scope, still scanning, or omitted by the 500-workload bound — is absent from the summary.

This means a findings page can never honestly say "25 of 30 workloads scanned," because there is no 30 to compare against. Every findings view states this plainly instead:

12 workloads reported by the scanner. Every application and installed add-on is listed, including those with no scan result yet — but the platform does not track how many workloads each one runs, so an application's count cannot be confirmed as complete.

A page reporting zero criticals still carries this caveat. Zero findings is a real, meaningful result — but only for what was actually scanned. Read the coverage note before trusting a clean-looking total.

Attribution: applications, not Kubernetes objects

AstroPulse is a layer above Kubernetes, and findings read that way. The console groups findings by what you actually manage:

• Your applications, matched by the platform's own generated identity for each workload — the same identity that resolves cost and metrics to an application. A multi-workload application (say, a web process and a worker) is one row with combined counts. A known application with no reported workload remains visible as no scan result yet.
• The platform's own managed add-ons, by their catalog name (for example "Cost Visibility" or "Vulnerability Scanning" itself), when a workload resolves to one. This is rare in the default configuration: add-on namespaces are excluded from scanning by default (see the add-on's scanScope in Add-ons).
• Everything else, grouped plainly as "Other workloads" — anything the platform doesn't manage that the scan scope still covers.

Kubernetes namespaces and object kinds stay out of the primary view. They still exist where the mechanics require them — opening a specific workload's live CVE detail needs to address a specific object — but you reach that only by opening a row, not by reading a namespace/kind table.

Where to see it

Console

• Cluster → Security: the full picture — severity totals, the coverage caveat, freshness, and applications and add-ons ordered worst first. Known applications and add-ons with no reported workload are shown explicitly. The cluster Overview tab also carries a compact summary card that opens this tab.
• Application → Security: severity counts for that application's reported workloads, with live CVE detail grouped by image directly below them.

On the cluster view, selecting a reported row or workload reads its actual CVE list live from the cluster. The application view performs that live read inline. AstroPulse shows the scan result as recorded and does not reinterpret it.

CLI

# A whole cluster — severity totals and every application or add-on
astroctl infra k8s vulnerabilities -c my-cluster

# One application's slice of the same cluster report
astroctl app vulnerabilities checkout

# Drill into one application's actual CVEs (live read, not the stored summary)
astroctl infra k8s vulnerabilities my-cluster --application checkout

Aliases: vuln, vulns, cve.

Nova

Ask in plain language. Nova answers current posture questions from the stored summary; use the console or astroctl ... --application when you need the live package-level CVE rows:

Does my-cluster's latest scan report any critical vulnerabilities?

Does the latest report show any CVEs affecting checkout?

Getting notified

Findings are pull by default: the console and CLI above are where you see them. Alerting exists and is opt-in on both sides — you subscribe, and the platform deployment enables delivery.

Subscribe (either surface):

• Console → Settings → Notifications → subscribe to Security Alerts
• astroctl notifications subscriptions upsert --topic security-alerts --channels email (or slack,email) — same subscription, same effect

Subscribing on its own does not start delivery. Vulnerability alerting is disabled by default on a platform deployment and is turned on by the platform operator; until then the evaluation runs and records what it would have sent, without sending anything. If you have subscribed and receive nothing, that is the reason — ask your platform operator whether it is enabled.

Once it is on:

	Behaviour
Cadence	Evaluated daily.
Default threshold	At least 1 Critical or 10 High findings across a cluster. Platform operators can override these thresholds.
Volume	One message per organization, listing every affected cluster worst-first — not one per cluster.
Repeats	At most once per cluster per 7 days, unless the posture materially worsens (default 1.5×).
Channels	Whatever your Security Alerts subscription names — email, Slack, or both.
Quiet clusters	A cluster whose findings have not been refreshed in over 24 hours is skipped rather than re-alerted, so removing the add-on stops alerts instead of freezing them.

The message carries the severity breakdown, the most affected applications, how many findings already have a published package fix, and which images to start with. "Fixable" means the scanner knows a package version that resolves the CVE — it does not mean a newer image tag exists. The fix is to rebuild the image on current packages; pulling a newer tag only helps if that tag was built after the package fix landed.

What is not scanned

	Covered?
Images of running workloads	Yes — this is the whole scope.
Node / host OS images	No. Your cloud provider or your team owns node images; patching them is a cluster upgrade, not this add-on.
Workload misconfigurations	No. The scanner can produce them, but the platform does not collect or surface them.
Secrets baked into images	No, same reason.

Common questions

Question	Answer
Does Enterprise keep longer vulnerability history?	No. Findings are latest snapshot only — no plan-based retention tier.
Can I see CVE trends over 90 days?	Not from stored platform data. Only the latest summary is kept.
Why does age show 2 days on a daily scan?	Rescan is per workload/TTL-driven; a workload may not have rescanned yet, or a push may be pending after a scan burst.
Why does my app say "no scan result yet"?	No workload was attributed to it in the latest summary. It may be outside scanScope, newly deployed, still scanning, or omitted by the workload bound; this is unknown, not zero.
Why can't I open CVE detail?	Live detail needs a connected agent at that moment; the summary alone does not include CVE rows.
Is zero criticals safe?	Only for reported workloads — read the coverage caveat first.
Does this scan my nodes?	No. Workload images only — node/host OS images belong to your provider or your team.
I subscribed but get no alerts.	Delivery is disabled by default and enabled per platform deployment — ask your platform operator.
Does "fixable" mean a newer image exists?	No. It means a fixed package version is published; rebuild the image to pick it up.

Requirements

	Requirement
Supported cluster	Any supported provisioned or registered cluster with a connected, compatible Astro agent.
Findings summary	The Vulnerability Scanning add-on installed and healthy.
Live CVE detail	A connected agent at the moment you open it; the detail is read on demand and is not persisted by AstroPulse.

If an application shows no scan result yet, its workloads may fall outside the configured scanScope, may not have completed a scan, or may not fit in the bounded summary. Read the coverage note before assuming it is clean.