Vulnerability Policies

Overview

Sysdig includes scanning policies for both Pipeline and Runtime vulnerabilities that work out of the box, along with relevant rule bundles. The process of editing or creating new policies and rules is similar for both.

Available Rules

Vulnerability Rules

Severities and Threats

Scanning for vulnerabilities in the software is a primary concern; at the same time, reported vulnerabilities may not be relevant to the particular production environment being analyzed, and it’s usually unrealistic to achieve an environment with no vulns at all for a particular software package. Each organization sets an acceptable risk threshold for a vulnerability, in order to decide whether the evaluated asset is within acceptable boundaries or should be considered non-compliant.

CVE DenyList

If any vulnerability listed in this rule is detected, the rule will fail, regardless of severity or any other vulnerability attribute.

ImageConfig Rules

An OCI Image Configuration is a JSON document describing images for use with a container runtime and execution tool, and their relationship to filesystem changesets.

In short, is comprises the image configuration and metadata.

For example:

• Entrypoint / CMD
• Configured user
• Environment variables
• Labels
• Author
• Creation time
• Build history
• … (many other config keys, some of them mandatory some optional)

Default User

The default user configured to run the entrypoint or CMD.

Defaulting to root is discouraged, as it can confer unnecessary privileges and allow an attacker easier privilege escalation or lateral movements if successfully exploited.

Apart from avoiding root, this rule also allows specifying a particular user (i.e. jenkins) that must be set , or otherwise fail.

Recommended Instructions

The use of the ADD instruction is discouraged, as COPY is more predictable and less error prone.

Package Manager Instructions

This rule forbids the use of package manager instructions, per recommended security practices. (Directly fetching the latest available version of a package(s) using a package manager during image build can lead to non-reproducible builds, so may be discouraged.)

The following package managers / update subcommands are currently detected from the image’s build history:

apk
.*apk upgrade.*
apt
.*apt-get upgrade.*
.*apt upgrade.*
yum
.*yum upgrade.*
rpm
.*rpm (--upgrade|-U).*
pip
.*pip3* install (--upgrade|-U).*
pipenv
.*pipenv update.*
poetry
.*poetry update.*
npm
.*npm update.*
yarn
.*yarn update.*
composer
.*composer update.*
cargo
.*cargo update.*
bundle
.*bundle update.*
gem
.*gem update.*

Image Creation Date

The creation date of an image can be used to indicate that the image has become stale.

NOTE: Image creation date is an optional attribute, so this rule will also fail if the date has not been declared.

Sensitive Information and Secrets

Leakage of sensitive information is one of the most severe security issues and has often led to actual security breaches. By enabling this rule, the ImageConfig metadata will be parsed for sensitive strings.

Example violation of an AWS secret found in the image label AWS_TOKEN:

The currently available detections for this rule are:

• Aws_secret

  • AKIA keys: AKIA[0-9A-Z]{16}
  • Any other key: aws.{0,20}?(?:key|pwd|pw|password|pass|token).{0,20}?

• Azure storage account key

• Basic Auth: detects [http,ssh]://user@pass:domain.com

• JWT token

• Private keys: Check if strings contains

  "BEGIN DSA PRIVATE KEY",
  "BEGIN EC PRIVATE KEY",
  "BEGIN OPENSSH PRIVATE KEY",
  "BEGIN PGP PRIVATE KEY BLOCK",
  "BEGIN PRIVATE KEY",
  "BEGIN RSA PRIVATE KEY",
  "BEGIN SSH2 ENCRYPTED PRIVATE KEY",
  "PuTTY-User-Key-File-2"
  

Create Rule Bundles

A rule bundle is a set of scanning rules that are grouped together.

Note:

• Default Sysdig rule bundles (identified with the Sysdig shovel icon) cannot be deleted, but they can be duplicated if you want to use them as a template for a new rule bundle
• The same rule bundle can be used for several different policies
• Rules order is irrelevant from the evaluation perspective, but you can organize them to your liking for easier visualization.

Creation Steps

1. Navigate to Policies > Rule Bundles and click +Add Bundle.

   

2. Enter the parameters:

   • Name: User-assigned name for this rule bundle
   • Description: User-assigned rule bundle description
   • Rules: A rule bundle is composed of 1..N scanning rules; you can use the visual editor to create and configure new rules (represented as “cards” in the interface).

3. Click Save. You can now attach this rule bundle to policies.

Example

In the example below, a particular vulnerability will fail the check if:

• The severity is High or Critical AND
• It was discovered 60 days ago or more AND
• It has a published fix AND
• There is a public exploit available

Notes:

• You can create multiple version of the same rule template for the same policy bundle, i.e. you can have two or more cards like the one above of type Vulnerabilities: Severities and Threats"
• Conditions between the same rule are evaluated with AND logic, as in the example above, a vulnerability needs to meet all the conditions in order to be considered a violation
• All the rules in a rule bundle are evaluated using OR logic
  • If any rule is in violation, the rule bundle is in violation
  • Also if any rule bundle is in violation, the policy containing it is in violation as well, considered “failed”.

Create Scanning Policies

You can create custom scanning policies and rule bundles as needed to meet your organization’s vulnerability management guidelines. The basic concepts of scanning polices and rules are:

• An image can be evaluated with 1..N policies at the same time
• A policy can contain 1..N rule bundles to be evaluated
• A rule bundle is composed of any number of rules to be evaluated

Pipeline

1. Navigate to Policies | Vulnerabilities > Pipeline. The Pipeline scanning policy list is displayed.

2. Click +Add Policy|Pipeline.

   

3. Enter the parameters:

   • Name: User-assigned name for this policy

   • Description: User-assigned policy description

   • Always apply toggle: Mapping strategy to use:

     • If Always Apply is enabled, every execution of the scanner will apply this policy. This cannot be overridden by the CLI parameters.
     • If Always Apply is disabled, this policy must be explicitly requested when executing the scanner in order to apply it to the evaluation.

   • Rule Bundles: A policy contains rule bundles to be evaluated. Using this widget you can add, remove, or modify the bundles used for this policy.

     • Click Edit Assigned Rule Bundles and toggle on the bundle(s) to be assigned. Click Update.

       

   • How to Scan Images with this policy: Helper widget that previews the command line to be used in order to apply the policy to the scanner run. See also: Getting Started with Sysdig Secure.

4. Click Create.

Runtime

1. Navigate to Policies | Vulnerabilities > Runtime. The Runtime scanning policy list is displayed.

2. Click +Add Policy|Runtime.

   

3. Enter the parameters:

   • Name: User-assigned name for this policy

   • Description: User-assigned policy description

   • Scope: Consists of asset types (container image workloads and hosts) and subsets of scope values.

     • Asset Type: Default is Any Asset. Select Host or Workload to narrow.
     • Scope: Use Entire Infrastructure or build out a desired scope. Scope values applicable to the chosen asset type(s) are displayed.
       • Click See Workloads in this Scope to check that the scope is valid and working as expected.
       • NOTE: If you use asset type Any Asset, the only Scopes that apply to both Hosts and Workloads are Entire Infrastructure or kubernetes.cluster.name.

   • Rule Bundles: A policy contains rule bundles to be evaluated. Using this widget you can add, remove, or modify the bundles used for this policy.

     • Click Edit Assigned Rule Bundles and toggle on the bundle(s) to be assigned. Click Update.

       

Risk Acceptance Summary

If a user chooses to accept the risk of a known vulnerability, the list of those acceptances is compiled on this summary page.

Usage

Use the summary page to search for acceptances that are expired or close to expiry and manage them. You can also:

• Use the Search field to search by CVE name or image tag
• Filter by Entity or Acceptance Reason
• Filter by Active acceptances

To manage expired acceptances:

1. Navigate to Policies > Vulnerability|Risk Acceptance.

2. Find the relevant entries by:

   • Clicking the Expired button in the top filter
   • Sorting by Expiration date in the table header
   • Using the search bar for a targeted search

3. Click the row for each expired entry and either extend the time limit or revoke the Acceptance.

   

Note: When an acceptance expires, it no longer excludes the vulnerability from the vuln count.