Skip to main content

Vulnerability Management

Cyscale brings vulnerability findings into cloud and Kubernetes context so security teams can prioritize vulnerable assets by exposure, ownership, identity, and relationships.

Where Findings Come From​

Depending on your connectors and provider configuration, Cyscale can ingest or compute vulnerability context from:

  • AWS Inspector for EC2 instances, Lambda functions, and ECR images
  • AWS ECR image scanning
  • Google Cloud Artifact Analysis / OS scanning
  • Kubernetes image SBOMs collected by the Cyscale Kubernetes agent
  • Cyscale virtual machine scans, using disk snapshots or SSH-based package collection
  • package and vulnerability enrichment services used by Cyscale

Provider-native scanners must be enabled in the cloud provider before Cyscale can show their findings.

Virtual Machine Vulnerability Scanning​

Cyscale can scan virtual machines directly when provider-native vulnerability coverage is not available or when you want a consistent view across cloud and self-managed compute.

VM scanning supports two collection modes:

  • Snapshot scanning analyzes disk snapshot evidence where supported. It does not require in-guest credentials and is useful when teams prefer to inspect VM package state from disk-level evidence.
  • SSH scanning connects to the running VM with approved SSH access and collects package inventory from the operating system. It is useful when snapshot access is unavailable, when the host is outside a supported snapshot workflow, or when the live OS view is required.

Both modes normalize findings into the same vulnerability model used across cloud, Kubernetes, and code context. After collection, Cyscale can show affected packages, CVEs, severity, remediation guidance where available, and the relationships that make a vulnerable VM more or less urgent.

Kubernetes Image Vulnerability Scanning​

When Kubernetes vulnerability scanning is enabled during Kubernetes connector onboarding, the Cyscale agent:

  1. discovers container images used by workloads
  2. pulls image metadata where it has access
  3. generates SBOMs inside the cluster
  4. sends the SBOMs to Cyscale
  5. lets Cyscale scan and re-scan those SBOMs for package vulnerabilities

This keeps sensitive runtime context inside the cluster while still giving Cyscale enough package evidence to correlate vulnerabilities with workloads, namespaces, services, and cloud context.

Viewing Vulnerabilities​

You can review vulnerabilities from:

  • the vulnerability inventory
  • an individual asset's Vulnerabilities tab
  • alert and graph views when vulnerabilities are part of the impact context
  • dashboard cards and trend views where available

Findings are generally grouped by CVE or package context and include severity, affected package, description, and remediation guidance when available.

Prioritization​

Cyscale helps you move beyond "highest CVSS first" by adding context such as:

  • whether the affected asset is internet reachable
  • whether the affected virtual machine is connected to sensitive networks, identities, or data stores
  • whether the vulnerable image is actually running
  • whether the workload is attached to sensitive identities
  • whether the asset is connected to critical data stores
  • whether the asset also fails posture controls
  • whether the vulnerable resource is production or in scope for compliance

Daily Re-Scanning​

For Kubernetes SBOMs and other stored package evidence, Cyscale can re-check findings as new CVEs are published. This helps identify newly disclosed vulnerabilities even when the workload did not change.

Setup Checklist​

  • Enable provider-native vulnerability scanners where applicable.
  • For virtual machines, choose snapshot scanning or SSH scanning based on the access model you can support.
  • Make sure snapshot permissions, network reachability, SSH credentials, and operating system package managers are available for the selected VM scanning mode.
  • For Kubernetes, enable vulnerability scanning during connector onboarding or update the Helm release with the setting shown in the app.
  • Make sure private registry access is configured when the agent needs to inspect private images.
  • Trigger a sync after enabling the scanner.
  • Review the vulnerability inventory and asset-level vulnerability tabs.

Common Gaps​

No findings are visible​

Check whether the provider-native scanner is enabled and whether the connector has synced after scanner activation.

Kubernetes images are missing findings​

Check whether the Kubernetes agent can access the image registry. Private registries may require image pull secrets, workload identity, or provider-specific registry authentication.

Virtual machines are missing findings​

Check whether the selected scan mode can access the VM evidence. Snapshot scanning requires the needed disk snapshot permissions and supported disk evidence. SSH scanning requires network reachability, valid credentials, and permission to read package inventory on the host.

Findings exist but are not prioritized​

Connect the related cloud provider and Kubernetes cluster when possible. The richer the graph context, the better Cyscale can show exposure, workload, identity, and data relationships.