This document applies only to the Vulnerability Management engine, released April 20, 2022. Make sure you are using the correct documentation: Which Scanning Engine to Use. You also need to enable it in Sysdig Labs.
As of December, 2022, hosts can be scanned for vulnerabilities as well as containers. See Host Scanning for details.
Why Runtime Scanning?
Although shifting vulnerability management to the earliest phases (such as integrating with CI/CD) is essential, runtime vulnerability management remains important:
- Strong defense: Runtime VM provides an additional layer of defense to your arsenal.
- Up-to-date: New vulnerabilities are discovered every day; new discoveries need to be checked against your running images.
- Prioritized feedback: The In Use spotlight lets you hone in on the most important vulnerabilities discovered within your running images so you can efficiently prioritize and act.
Sysdig’s runtime scanner will:
- Automatically observe and report on all the Runtime workloads, keeping a close-to-real time view of images and workloads executing on the different Kubernetes scopes of your infrastructure.
- Perform periodic re-scans, guaranteeing that the vulnerabilities associated with the Runtime workloads and images are up-to-date with the latest vulnerabilities feed databases. It will automatically match a newly reported vulnerability to your runtime workloads without requiring any additional user interaction.
Understanding the Runtime Workload and Labels
Runtime entities are associated using the concept of workload, defined by:
These workload labels are in the order:
cluster > namespace > type > container
Kubernetes cluster name, demo-kube-eks in the example above
Kubernetes namespace name, example-voting-app above
Kubernetes workload type, deployment (or daemonset, etc.)
Kubernetes container name, sysdiglabs/example-voting-app-result:metrics-3 above
- Several replicas of the same deployment are considered the same workload (single entry on the table), as the images are identical and the runtime context is the same.
- An identical image deployed on two different Kubernetes clusters will be considered two different workloads, as the runtime context is different.
About Runtime Policies
Policies let you define a set of rules that will evaluate each workload. After the evaluation, each policy will pass or fail. A policy failure or non-compliance happens if the scan result doesn’t meet all the rules in a policy.
Runtime policies contain a runtime scope filter, so it only applies workloads in that scope, or Entire infrastructure, which will apply globally.
NOTE: If you have enabled host scanning, then you can assign runtime policies to container image workloads, hosts, or the entire infrastructure.
Learn more about Vulnerability Management policies, the available rules, and how to define policies in Vulnerability Policies
Review Runtime Scan Results Overview
Vulnerabilities > Runtime.
By default, the entire infrastructure results are shown.
Results are ranked by:
- Number of actual exploits
- Severity of vulnerabilities
- Number of vulnerabilities
From here you can:
to find and remediate the priority issues discovered.
Understanding the In Use Column
The In Use column depends upon Image Profiling and is currently in Controlled Availability status.
- To enable In Use in your account, please contact your Sysdig representative.
- You will also need to set a parameter in the Node Analyzer of the Sysdig Agent and enable Image Profiling. See Profiling | Enable for Risk Spotlight and In Use. Data in the In Use column will appear approximately 12 hours after the feature has been deployed.
The In Use designation lets you focus first on the packages containing vulnerabilities that are actually being executed at runtime. If an image has 180 packages and 160 have vulnerabilities, but only 45 are used at runtime, then much of the vuln notification noise can be reduced.
Click on an image entry to see the In Use panel and drill down, clicking on the vulnerabilities for details and examining the link to any known exploits that exist.
Drill into Scan Result Details
Select a workload from the Runtime results list
Focuses on the package view and top-priority running images (In Use).
Clickable cells lead into the Vulnerabilities list (next).
Provides expanded filters and clickable list of CVEs that open the full CVE details, including source data and fix information.
Also organized by package view, with expanded filters and clickable CVE cells.
Shows CVEs organized by the
failed. Use the toggle to show or hide
passed. Click CVE names for the details.
Filter and Sort Results
Filter by workload labels and optionally save constructed filters as Favorite or Default from the kebab (3-dot) menu on the filter bar.
Filter by evaluation:
Click In Use to list the results that have been evaluated for risk first.
Use further-refined filters within the image detail tabs, e.g.
CVSS Score (>=);
Accept Risk: Runtime
As of November, 2022, users can choose to accept the risk of a detected vulnerability or asset.
If the minimum enablement requirements are not met, the
Accept Risk button and panel will show in your interface, but will not activate. A created Acceptance would appear in
Pending status for 20 minutes, then disappear as if you had never created it.
Configure an Accepted Risk
The process for Accept Risk is the same for Runtime and for Pipeline.
For a Failed CVE
Vulnerabilities > Runtime.
Click Accept Risk and continue to Complete the Configuration.
For a Failed Host or Image
You can accept risk for an entire host or image, based on the image name or host name.
- In this case, you are not accepting the vulnerabilities within, just the asset as a whole
- The ImageID or digests are not taken into account
Navigate to Vulnerabilities > Runtime and select a failed asset.
Choose the Policies panel and select the Accept image as a risk button.
Continue to Complete the Configuration.
Complete the Configuration
Select Accept Risk or Accept image as risk.
Enter the configuration details:
Not Relevant, or
Add details in the free-text box if needed.
Context: Defines the scope, i.e., the cases to which the Accept will apply.
- Global: Every time this vulnerability is found, regardless of the asset or the package and also regardless of the phase (Pipeline, Runtime), this vulnerability will always be accepted.
- Package: You are accepting only the combination of this CVE and a particular package. There are two sub options:
package version(default). For example:
Any package versionFor example,
- This image: Select the particular image or host name from the drop-down.
Note that the
contextcan affect multiple assets with a single configuration. For example, accepting one CVE
globallywould affect the policy evaluation of all the different images in which that vuln is found.
Customtime frame or
- Accepts should be exceptional choices; normally they should not mask a security risk forever
- When the Accept expires, the vulnerability (or asset) reappears in the violations count, potentially causing an evaluation to fail again.
A green acknowledgement message is displayed, and a greyed out
Shieldicon shows the Accept is in Pending status.
The creation, editing, or revocation of an Accept does not take effect immediately. The change is in Pending status with the grey shield icon until the next runtime scan is:
- Automatically triggered
- Within 20 minutes
No additional changes can made to the Accept configuration while it is pending.
Note: This differs in Pipeline.
There is a limit of 1000 Accept Risk items (per customer account)
- This is the number of configurations created, not the number of impacted assets/CVEs.
- For example, a global CVE Accept impacting 30 images counts as 1 Accept Risk item.
- Both CVE accepts and Asset accepts count towards that total.
When no longer pending, the Accept Risk shield is not greyed out and appears in the list of assets. You can also filter by Accept Risk to see all assets where an Accept has been applied.
Click in to the asset to see more, and hover over the shield icon to see all the Accept Risk config details.
Accepted Risk on a CVE will be shown in the:
- List of CVEs in the Vulnerabilities panel
- List of Policy violations under the Policies panel
- Policy evaluation card, showing the number of overridden violations
A policy will pass if:
- All the rules inside the policy pass, or
- All the violations to a policy have been voided by a matching accept
A host or image will pass if:
All the policies attached to the asset pass, or
The asset itself is accepted
In this example, the policies are failing but the asset has been accepted, indicated by the shield icon beside the [PASSED] global evaluation.
Edit an Accept
To edit an existing risk, click on the pencil icon in the Accept details.
You can edit the
To change the affected resource or the context, you must create a new Accept configuration, and delete the old one if no longer valid.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.