Vulnerability Management

• 1: Pipeline
• 2: Runtime
• 2.1: Host Scanning
• 3: Reporting

$ helm list -n sysdig-agent
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
sysdig-agent    sysdig-agent    5               2022-11-11 17:57:54.109917081 +0100 CET deployed        sysdig-deploy-1.5.0

1 - Pipeline

Introduction

The sysdig-cli-scanner tools allow you to manually scan a container image, either locally or from a remote registry. You can also integrate the sysdig-cli-scanner as part of your CI/CD pipeline or automations to automatically scan any container image right after it is built and before pushing to the registry scanner.

Development / CI/CD / Pipeline / Shift-Left / …: all of these terms refer to scanning performed on container images that are not (yet) executed in a runtime workload. You can scan these images using the sysdig-cli-scanner tool, and explore the results directly in the console or in the Sysdig UI.

Optionally, you can create additional pipeline scanning policies and rules.

The Pipeline section in Sysdig Secure will display the scan results for all images that are scanned using the sysdig-cli-scanner

For Runtime workloads, see how they are automatically scanned by the Sysdig Runtime Scanner.

Running the CLI Scanner

The sysdig-cli-scanner is a binary you can download and execute locally in your computer or environment.

Scanning Images

1. Download latest version of sysdig-cli-scanner with:

• Linux:

  Intel Processor (AMD64)

  curl -LO "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/linux/amd64/sysdig-cli-scanner"
  

  ARM Processor (ARM64)

  curl -LO "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/linux/arm64/sysdig-cli-scanner"
  

• MacOS:

  Intel Processor (AMD64)

  curl -LO "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/darwin/amd64/sysdig-cli-scanner"
  

  Apple Silicon (M1, M2) Processor (ARM64)

  curl -LO "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/darwin/arm64/sysdig-cli-scanner"
  

Optionally, you can check the sha256sum as:

• Linux:

  Intel Processor (AMD64)

  sha256sum -c <(curl -sL "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/linux/amd64/sysdig-cli-scanner.sha256")
  

  ARM Processor (ARM64)

  sha256sum -c <(curl -sL "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/linux/arm64/sysdig-cli-scanner.sha256")
  

• MacOS:

  Intel Processor (AMD64)

  shasum -a 256 -c <(curl -sL "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/darwin/amd64/sysdig-cli-scanner.sha256")
  

  Apple Silicon (M1, M2) Processor (ARM64)

  shasum -a 256 -c <(curl -sL "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/darwin/arm64/sysdig-cli-scanner.sha256")
  

2. Set the executable flag on the file:

   chmod +x ./sysdig-cli-scanner
   

   You only need to download and set executable once. Then:

3. You can scan images by running the sysdig-cli-scanner command:

   SECURE_API_TOKEN=<your-api-token> ./sysdig-cli-scanner --apiurl <sysdig-api-url> <image-name>
   

See Parameters for more detail.

Integrating in your CI/CD Pipelines

The sysdig-cli-scanner can be included as a step in your CI/CD pipelines (i.e. Jenkins, Github actions or others) simply by running the sysdig-cli-scanner command as part of your pipeline.

• Make sure that the sysdig-cli-scanner binary is available as part of the worker or runner where the pipeline is executing.
  • If you are running an ephemeral environment in the pipeline, include the download and set executable steps in your pipeline to download the tool on every execution.
• Define a secret containing the API-Token and make it available in the pipeline (i.e. via a SECURE_API_TOKEN environment variable).
• Include a step in your pipeline to run the sysdig-cli-scanner after building the container image, and providing the image name as paremeter. For example:

./sysdig-cli-scanner --apiurl <sysdig-api-url> ${IMAGE_NAME}

See some examples on how to use it on different CI/CD pipelines:

• AWS CodeBuild
• Azure Pipelines
• GitHub
• GitLab
• Jenkins

About CI/CD Policies

Policies allow you to define a set of rules that will evaluate each scan result. 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.

For CI/CD and manual image scans, you can tell the sysdig-cli-scanner tool to explicitly evaluate one or more policies using the --policy= policy1,policy2,... flag and provide a comma-separated list of policy IDs.

CI/CD policies can be configured as Always apply. If a policy has the Always apply flag, it will be evaluated on every scanned image even if you don’t specify it explicitly.

Learn more about Vulnerability Management policies, the available rules, and how to define policies in Vulnerability Policies.

Parameters

Basic usage of the sysdig-cli-scanner:

sysdig-cli-scanner [OPTIONS] <ImageName>

Required

• The Sysdig CLI scanner will try to find a local image in Docker, ContainerD or other container runtimes, or try to pull if from the remote registry.
• Once the scan is complete, you will see the results directly in the console, and they will be available in the Pipeline section of the UI.

Registry credentials

Registry credentials can be supplied via the following environment variables

Example

$ REGISTRY_USER=<YOUR_REGISTRY_USERNAME> REGISTRY_PASSWORD=<YOUR_REGISTRY_PASSWORD> SECURE_API_TOKEN=<YOUR_API_TOKEN> ./sysdig-cli-scanner --apiurl https://secure.sysdig.com ${REPO_NAME}/${IMAGE_NAME}

Additional Parameters

Use the -h / --help flag to display a list of all available command line parameters:

Example

Usage:
  sysdig-cli-scanner [OPTIONS] [ImageName]

Application Options:
  -a, --apiurl=                 Secure API base URL
  -t, --apitimeout=             Secure API timeout (seconds) (default: 120)
      --output-json=            Output path of the scan result report in json format
  -s, --skiptlsverify           Skip TLS certificate verification (default: false)
  -u, --skipupload              Skip the scan results upload (default: false)
  -d, --dbpath=                 Database full path. By default it uses main.db.gz from the same directory
      --policy=                 Identifier of policy to apply
  -p, --cachepath=              Cache path
  -c, --clearcache              Clear the cache before to run (default: false)
  -l, --loglevel=               Log level (default: info)
  -o, --logfile=                File destination for logs, used if --console-log not passed
      --console-log             Force logs to console, --logfile will be ignored
      --full-vulns-table        Show the entire list of packages found
      --detailed-policies-eval  Show a detailed view of the policies evaluation
      
  --no-cache config flag				Disable the cache layer during the scan
  --standalone config flag 			Disable communication towards the backend. This implies:  
  															skip upload of the scan-result; offline-analyze; no 
  															policies; no policy remediations; no risk-acceptances; no 
  															download of the mainDB (local path for an existing one 
  															needs to be provided with the dedicated parameter)      

Help Options:
  -h, --help                    Show this help message

Arguments:
  ImageName:                    Image name

Image Sources

The Sysdig CLI scanner can load images from different sources. By default, it will try to automatically find the provided image name from all supported sources, in the order specified by the following list. However, you can explicitly select the image source by using the corresponding prefix for the image name:

• file:// - Load the image from a .tar file
• docker:// - Load the image from the Docker daemon (honoring DOCKER_HOST environment variable or other Docker configuration files)
• podman:// - Load the image from the Podman daemon
• pull:// - Force pulling the image from a remote repository (ignoring local images with same name)
• containerd:// - Load the image from Containerd daemon
• crio:// - Load the image from Containers Storage location

i.e. pull the image from remote registry even if it is locally available:

./sysdig-cli-scanner -a https://secure.sysdig.com pull://nginx:latest

Sample Result in Terminal

It is possible to view scan results in the terminal window (see below)

$ SECURE_API_TOKEN=<YOUR_API_TOKEN> ./sysdig-cli-scanner --apiurl https://secure.sysdig.com redis

Type: dockerImage
ImageID: sha256:7614ae9453d1d87e740a2056257a6de7135c84037c367e1fffa92ae922784631
Digest: redis@sha256:db485f2e245b5b3329fdc7eff4eb00f913e09d8feb9ca720788059fdc2ed8339
BaseOS: debian 11.2
PullString: pull:*//redis*

66 vulnerabilities found
8 Critical (0 fixable)
2 High (0 fixable)
4 Medium (0 fixable)
5 Low (0 fixable)
47 Negligible (0 fixable)

  POLICIES EVALUATION
  Policy: Sysdig Best Practices FAILED (9 failures)`

You can use --full-vulns-table or --detailed-policies-eval flags to include further details in the output.

For a more user-friendly scan result, find the image in the UI.

JSON Output

You can use the --output-json=/path/to/file.json to write a JSON report of the scan result

Scan Logs (for troubleshooting)

The sysdig-cli-scanner automatically writes a log file on every execution. You can change the output path using -o or --logfile flags. For troubleshooting purposes, you can change the log level by setting --loglevel=debug. This will increase the verbosity of the log messages to the debug level.

Review Pipeline Scans in the UI

You can explore the details for every image that has been scanned by executing the sysdig-cli-scanner in Sysdig Secure UI.

1. Navigate to Vulnerabilities > Pipeline.

   

2. Filter the list by Pass | Fail if desired.

   • The Policy Evaluation column reflects the policy state at evaluation time for that image and the assigned policies
     • Failed: If any of the policies used to evaluate the image is failing, the image is considered “Failed”
     • Passed If there is no violation of any of the rules contained in any of the policies, the image is considered “Passed”

From here you can drill down to the scan result details.

Drill into Scan Result Details

Select a result from the Pipeline list to see the details, parsed in different ways depending on your needs.

Overview Tab

Focuses on the package view and filters for those that are fixable. Clickable cells lead into the Vulnerabilities list (next).

Vulnerabilities Tab

Expanded filters and clickable list of CVEs that open the full CVE details, including source data and fix information.

The same security finding (e.g. a particular vulnerability) can be present in more than one rule violation table if it happens to violate several rules.

Content Tab

Also organized by package view, with expanded filters and clickable CVE cells.

Policies Tab

Shows CVEs organized by the policy+rule that failed. Use the toggle to show or hide policies+rules that passed. Click CVE names for the details.

Filter and Sort Results

Within the Pipeline results tabs, there are ways to further refine your view:

• Search by keyword or CVE name
• Use filters: Severity (>=); CVSS Score (>=); Vuln Type; Has Fix; Exploitable.

Accept Risk: Pipeline

As of November, 2022, users can choose to accept the risk of a detected vulnerability or asset. The process for handling Accepted Risk is the same for Pipeline as for Runtime.

Use the Runtime instructions, with the following difference:

Accept Validity - Pipeline

The pipeline scan results are point-in-time, so there is no automatic re-evaluation.

To trigger a new evaluation containing the accept:

• You must execute the pipeline process again over the same image
• The N+1 scan will contain the accept

2 - Runtime

Introduction

Sysdig Secure will automatically analyze and scan the container image for the workloads in your clusters, providing a list of vulnerabilities, policy evaluations, and the “In Use” spotlight, helping you focus on fixing the active, critical and exploitable vulnerabilities.

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 allows you to 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:

• A unique ImageID

• A set of labels describing the runtime context (Kubernetes in this case)

  

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

This means:

• 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 allow you to 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

1. Navigate to Vulnerabilities > Runtime.

   

   By default, the entire infrastructure results are shown.

   Results are ranked by:

   • Number of actual exploits
   • Severity of vulnerabilities
   • Number of vulnerabilities

2. From here you can:

   • Check what’s In Use
   • Drill down to image details
   • Filter results
   • Accept risks/ revoke acceptances

   to find and remediate the priority issues discovered.

Understanding the In Use Column

The In Use designation allows you to 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

Overview Tab

Focuses on the package view and top-priority running images (In Use).

Clickable cells lead into the Vulnerabilities list (next).

Vulnerabilities Tab

Provides expanded filters and clickable list of CVEs that open the full CVE details, including source data and fix information.

Content Tab

Also organized by package view, with expanded filters and clickable CVE cells.

Policies Tab

Shows CVEs organized by the policy+rule that failed. Use the toggle to show or hide policies+rules that 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.

  • Hover over the workload labels and click = or =! to add them to the filter bar to refine by cluster, namespace, type, etc.

    

• Filter by evaluation: Pass / Fail / No Policy

  

• 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. CVE Name; Severity (>=); CVSS Score (>=); Has Fix; Exploitable.

  

Accept Risk: Runtime

As of November, 2022, users can choose to accept the risk of a detected vulnerability or asset.

Review Understanding Accept Risk and the Enablement Prerequisites if needed.

Configure an Accepted Risk

The process for Accept Risk is the same for Runtime and for Pipeline.

For a Failed CVE

1. Navigate to Vulnerabilities > Runtime.

2. Either:

   • Select a failed asset from the list and choose the Vulnerabilities panel, then hover over the far-right column to see the Accept Risk button

     

   • Select a failed asset from the list and choose the Policies panel, then hover over the far-right column to see the Accept Risk button

     

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

Note:

• 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

1. Navigate to Vulnerabilities > Runtime and select a failed asset.

2. Choose the Policies panel and select the Accept image as a risk button.

   

3. Continue to Complete the Configuration.

Complete the Configuration

1. Select Accept Risk or Accept image as risk.

   

2. Enter the configuration details:

   • Reason: Risk Owned, Transferred, Avoided, Mitigated, Not Relevant, or Custom

     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 name AND package version (default). For example: rpm 4.14.4
       • Package name - Any package version For example, rpm (any version)
     • This image: Select the particular image or host name from the drop-down.

     Note that the context can affect multiple assets with a single configuration. For example, accepting one CVE globally would affect the policy evaluation of all the different images in which that vuln is found.

   • Expires In: 7/30/60/90 days, Custom time frame or Permanent

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

3. Click Accept.

   A green acknowledgement message is displayed, and a greyed out Shield icon shows the Accept is in Pending status.

   

Manage Accepts

Accept Validity

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

Limits

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

Review Accepts

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

Passing Evaluations

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

• Reason
• Description
• Expiration

To change the affected resource or the context, you must create a new Accept configuration, and delete the old one if no longer valid.

2.1 - Host Scanning

A “host” is any runtime entity where you could execute the Sysdig agent, including virtual machines, Kubernetes nodes, bare metal, cloud-managed hosts such as EC2, etc.

Scanning for vulnerabilities on hosts is as important as scanning on containers, and certain standards such as NIST 800-190 require vulnerability reports on running hosts to pass compliance. Sysdig’s host scanning feature provides a unified flow with image scanning, for a smooth user experience.

Note: Having the agent installed on the hosts is not required, but is recommended. Metadata autocomplete on the filters and searches depend on the Sysdig agent.

Enable Host Scanning

Installation methods include Helm (recommended), Docker container, or non-containerized binaries.

Supported OSes and Host Types

• Ubuntu 22.04
• Ubuntu 20.04
• Debian 11
• Debian 10
• Redhat Red Hat Enterprise Linux 9
• Redhat Red Hat Enterprise Linux 8
• Redhat Red Hat Enterprise Linux 7
• Red Hat Red Hat Enterprise Linux Core OS
• Amazon Linux 2
• Flatcar Container Linux
• Alibaba Cloud Linux (a.k.a. Aliyun Linux)
• Google Container-Optimized OS (COS), build 89+

Currently Supported CPU Architectures

• AMD64 (x86_64)

• ARM (arm64)

Current Feature Limitations

• No Risk Spotlight/In Use integration

How Long until Host Scan Results Appear in the UI?

After installation:

• If the default parameter nodeAnalyzer.nodeAnalyzer.hostScanner.scanOnStart=true is set, then a scan will start just after the pod is ready. You can expect the results in a few minutes, ~15 min max.
• If this parameter is not set, results will be shown ~11 hours from install
• In all cases, scans are refreshed every 12 hours
• Helm chart and Docker container installations behave the same

Helm Install

If you have Kubernetes, the Helm install is the preferred method.

Prerequisites

Host scanning requires Sysdig Secure SaaS to be installed with:

• sysdig-deploy Helm chart version 1.5.0+
  • HostScanner container version 0.3.0+ (*0.3.1+ for Google COS)
  • Included by default on the helm chart version 1.5.0+, unless the user pins or modifies the defaults

• Host scanning is installed out of the box by default with the Helm chart; you can opt-out if desired.

Check Your Versions

Check your sysdig-deploy Helm chart (default namespace is sysdig-agent)

helm list -n <namespace>

Example:

$ helm list -n sysdig-agent
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
sysdig-agent    sysdig-agent    5               2022-11-11 17:57:54.109917081 +0100 CET deployed        sysdig-deploy-1.5.0

Upgrade Helm Chart Instructions here

Opting Out

If for some reason you don’t want to use host scanning, you can opt-out using the Helm chart flag:

--set nodeAnalyzer.nodeAnalyzer.hostScanner.deploy=false

Docker Container Install

If you have non-Kubernetes hosts but still want to use containers, you can deploy Host scanning without Helm as follows:

docker run --detach -e HOST_FS_MOUNT_PATH=/host -e SYSDIG_ACCESS_KEY=<access-key> -e SYSDIG_API_URL=<sysdig-secure-endpoint> -e SCAN_ON_START=true -v /:/host:ro --uts=host --net=host quay.io/sysdig/vuln-host-scanner:$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)

• Retrieve your access key
• Check your Sysdig Secure endpoint by region

Non-Containerized Install

The Helm chart is the recommended installation method, but if you want to scan a host without using containers at all, we also offer a standalone binary and an RPM package.

The configuration is passed via environment variables, specifically:

• Retrieve your access key to use for SYSDIG_ACCESS_KEY=<your-access-key>
• Check your Sysdig Secure endpoint by region to use for SYSDIG_API_URL=https://<sysdig-url>

RPM

Compatible with any host that supports the RPM package format, such as RHEL.

# Configure the repo
$ rpm --import https://download.sysdig.com/DRAIOS-GPG-KEY.public
$ curl -s -o /etc/yum.repos.d/draios.repo http://download.sysdig.com/stable/rpm/draios.repo

# Update index
$ yum update

# Install the package
$ yum install vuln-host-scanner

# Create your configuration file
$ cat /opt/draios/etc/vuln-host-scanner/env
SYSDIG_ACCESS_KEY=<access-key>
SYSDIG_API_URL=<api-url>
SCAN_ON_START=true # optional

# Enable the service
$ systemctl enable vuln-host-scanner.service

# Start the service
$ systemctl start vuln-host-scanner.service

# Check logs
$ journalctl -u vuln-host-scanner.service

Raw Binary

## Binary

$ ARCH=amd64; curl -s https://download.sysdig.com/scanning/bin/sysdig-host-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)/linux/$ARCH/sysdig-host-scanner > sysdig-host-scanner
# ARCH=arm64 for arm architectures

# Give exec permission
$ chmod +x sysdig-host-scanner

# Run it 
$ SYSDIG_ACCESS_KEY=<access-key> SYSDIG_API_URL=<api-url> ./sysdig-host-scanner

Kubernetes Metadata:

If your node is part of an existing Kubernetes installation and you’re not using the official Helm chart, you’ll be in charge of setting node name and cluster name via

K8S_CLUSTER_NAME
K8S_NODE_NAME

Other environment variables for the Host Scanner are listed in the chart.

Usage

Once you have deployed the host scanner in your environment, the Runtime UI will integrate the findings alongside the runtime workload results, based on an out-of-the-box Vulnerability policy.

Filter for Hosts

You can filter to find results of host scanning using the quick links in the banner at the top of the page, and/or the filter bar.

Hosts can be filtered using

• Kubernetes cluster name
• Cloud account id
• Cloud account region
• Host Name
• Agent tags

See also, Vulnerability Policies|Runtime.

Download Reports

You can schedule and download reports for scanning done on hosts as well as containers.

See Vulnerabilities|Reporting.

3 - Reporting

Introduction

Use the Vulnerability Reporting interface to schedule asynchronous reports about detected runtime vulnerabilities along with package and image data. You can schedule reports for runtime (container) scanning and/or host scanning.

Here you can:

• Create a report definition
• Schedule its frequency
• Define notification channel(s) in which to receive the reports (email, Slack, or webhook)
• Preview how the data will appear (optional)
• Download the resulting reports in .csv, .json, or .ndjson
• Optionally, generate a manual (unscheduled) report

NOTE: Regardless of the schedule, reports always include the data from the past 24 hours. Therefore, most users schedule a daily report to avoid having any gaps

Past reports are stored for two weeks. Therefore, if you scheduled a weekly report, the list would only contain two records.

Create a Report Definition

For Runtime Workloads

1. Access: Log in to Sysdig Secure with Advanced User or higher permissions, and select Vulnerabilities > Reporting.

   The Vulnerabilities Reporting list page is displayed. If you have previously created report definitions, you can click one to see the details.

   

2. Create: Click Add Report . The New Report page is displayed.

   

3. Basic Info: Define the report basic info:

   • Name
   • Description
   • Export file format: .csv, .json, or .ndjson

   Select Definitions:

   • Entity: Runtime Workloads

   • Scope: Entire infrastructure or subset from the drop-down menu

4. Conditions: (Optional) Add Conditions from the drop-down if you want to filter the items reported on.

   The available conditions include:

   • Image Name * (only for this Entity)
   • OS Name
   • In Use * (only for this Entity)
   • Package Name
   • Package Path
   • Package Type
   • Package Version
   • Vulnerability ID
   • CVSS Score
   • CVSS Vector
   • Vuln Publish Date
   • Exploitable
   • Fix Available
   • Risk Accepted
   • Severity
   • Vuln Fix Date

   Example 1: You want a report of all vulnerabilities with a Severity >= High, and for which a Fix is Available.

   

   Example 2: You want a report of all vulnerabilities that are In Use with Accepted Risks.

   

5. Schedule: Define the Schedule (frequency and time of day) that the report should be run.

   Note: The schedule determines when the report data collection begins. As soon as evaluation is complete, you will receive a notification in the configured notification channels.

   

6. Notification Channel: If you have configured them, you can use email, Slack, or webhook notification channels, and they will appear in the drop-down. Since reports are typically large, the actual data is not sent to the notification channel; you receive a link to download it. You must be a valid Sysdig Secure user (Advanced User+) to access the link.

7. Data Preview: Click Refresh to apply the configuration you’ve chosen and pull up on the center bar of the Data Preview panel to see sample results.

8. Click Save.

For Runtime Hosts

All of the steps are the same as for Runtime Workload reports, except:

3. Basic Info: Select Runtime Hosts as the entity.

4. Conditions: (Optional) Add Conditions from the drop-down if you want to filter the items reported on.

   The available Conditions include:

   • Architecture * (only for this entity)
   • OS Name
   • Package Name
   • Package Path
   • Package Type
   • Package Version
   • CVSS score
   • CVSS vector
   • Vuln Publish Date
   • Exploitable
   • Fix Available
   • Risk Accepted
   • Severity
   • Vuln Fix Date

Manage Reports

View and Edit Report Definition

1. Select an entry in the Reporting list to see the detail panel.

   

2. Click Edit to change the report definition parameters. You can also access this panel from the kebab (3-dot) menu.

   

3. Make your edits, click Refresh to see the Data Preview, and Save.

Download Reports

1. From the Reporting list, the latest report download link appears in the Download column.

   

2. To see older reports, select an entry in the Reports list to open the detail panel and select from the report download list.

   

3. The report will be downloaded in the format you defined; the file is zipped (.gz) – double-click to unzip and view.

Generate Report Manually

1. Select an entry in the Reporting list to see the detail panel.
2. Click Generate Now. A Scheduled entry will appear. Within 15 minutes or so it will change to Completed and you can download the manually generated report.

Duplicate a Report Definition

1. Choose the kebab (3-dot) menu for a scheduled report.
2. Click Duplicate.

Report Definition Retention

The scheduled and manually created reports are retained for 14 days.

Delete a Report Definition

Be sure to download any needed reports before deleting the definition.

1. Choose the kebab (3-dot) menu for a scheduled report.

2. Click Delete, click Yes when prompted.

   The report definition and all associated reports are deleted.