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
  • package and vulnerability enrichment services used by Cyscale

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

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 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 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.

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.