Vulnerability Policies

This topic introduces Sysdig vulnerability policies that govern the pipeline, runtime, and host scanning features of Sysdig Secure.

This doc applies only to the Vulnerability Management engine. If your Sysdig Secure was deployed before April 20, 2022, use the Scanning features and the Threat Detection policy documentation. See Which Scanning Engine to Use for more information.

Overview

Vulnerability policies are designed to identify and address pipeline, runtime, and host vulnerabilities and other image risks out of the box, accompanied by relevant rule bundles.

A policy consists of a set of rules that are applied according to the outcomes of scans conducted on a CI/CD pipeline, container image, or host. These rules are activated when critical vulnerabilities are identified within the given asset, or based on other criteria such as missing labels or having the image’s default user set to root. If the given policy determines that one or more rules don’t match the desired criteria, Sysdig will flag the policy evaluation as “failed” for that image or host.

The process of editing or creating new policies and rules is similar for both runtime and pipeline policies.

Rule Bundles

A scanning rule is a predefined criterion or condition used to detect, prevent, or address specific security threats or events in container images and host machines. These rules are created based on known patterns of malicious behavior, vulnerabilities, or indicators of compromise. They specify conditions that, when met, indicate the presence of a security threat or violation defined in the security policies. When an event occurs that matches the criteria defined in a rule, Sysdig takes predefined actions, such as generating an alert or taking an action.

A rule bundle is a set of scanning rules that are grouped together. See Available Rules for list of custom rules that you can add to your rule bundle.

Guidelines

  • 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.
  • Creating multiple versions of the same rule template for the same policy bundle is allowed. You can have two or more cards of type Vulnerabilities: Severities and Threats as given in the example below.
  • Conditions between the same rule are evaluated with AND logic, as given in the example below. A vulnerability needs to meet all the conditions 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.
    • if any rule bundle is in violation, the policy containing it is in violation as well, considered “failed”.

Create a Rule Bundle

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

  2. Enter the parameters:

    • Name: Specify a name to identify the rule bundle.
    • Description: Enter the details about the rule bundle
    • Rules: A rule bundle is composed of one or more scanning rules. You can use the visual editor to create and configure new rules. They are represented as “cards” on the UI.
  3. Click Save.

    Now, 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

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 policies and rules are:

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

Pipeline Policy

  1. Navigate to Policies > Vulnerabilities | Pipeline.

The Pipeline scanning policy list is displayed.

  1. Click +Add Policy > Pipeline Policy.

  2. Specify the parameters:

    • Name: A unique name to identify this policy

    • Description: 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 to apply it to the evaluation.
    • Rule Bundles: A policy contains rule bundles to be evaluated. You can add, remove, or modify the bundles used for this policy.

      To do so, click Edit Assigned Rule Bundles and toggle the bundles to assign it to the policy. When you finish, click Update.


    • How to Scan Images with this policy: Preview the command line to to apply the policy to a specified pipeline scanner run. For information, see Install the Sysdig CLI Scanner.

    • Notifications: Configure alerts to trigger upon a pipeline policy failure and report to a configured Notification Channel. For more information, see Vulnerability Policy Alerts.

  3. Click Save.

Runtime Policy

  1. Navigate to Policies > Vulnerabilities | Runtime.

    The Runtime scanning policy list appears.

  2. Click +Add Policy > Runtime Policy

  3. Specify the parameters:


    • Name: User-assigned name for this policy

    • Description: User-assigned policy description

    • Scope: Consists of asset types: Container, Workload, and Host, along with subsets of scope values, which are essentially the associated labels of the chosen asset types.

      • Asset Type: Default is Any Asset. Select Container, Host, or Workload to narrow.

        For more information, see Asset Type Definitions.

      • Scope: Use Entire Infrastructure or build out a desired scope. Scope values applicable to the chosen asset types are displayed.

        • Click See Workloads in this Scope to check that the scope is valid and working as expected.
        • 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. You can add, remove, or modify the bundles used for this policy.

      To do so, click Edit Assigned Rule Bundles and toggle the bundles to assign it to the policy. When you finish, click Update.

    • Notifications: Configure alerts to trigger upon a runtime policy failure and report to a configured Notification Channel. For more information, see Vulnerability Policy Alerts.

Vulnerability Policy Alerts

You can create alerts to trigger upon a failure of a Vulnerability Management policy and report to a configured Notification Channel.

Sysdig scans run regularly throughout the day, and rescans of images will likely occur multiple times daily and continue throughout the image’s lifecycle. A poorly constructed failing policy could generate a significant number of alerts. It’s crucial to align the type of policy alerting with the appropriate notification channel. As a best practice, set up a test channel first and verify that the volume and content of alerts are appropriate before connecting to live channels such as production Slack.

Guidelines

  • Consider both the number of images and workloads to which a policy will be applied, as well as the constraints of the attached rules. Both factors may influence the number of alerts generated.
  • Set a frequency or standoff period during which no further alerts will be sent for this failed policy. If any asset fails to comply with the policy during the standoff period, no additional alert will be generated.

Create a Policy Alert

  1. Set up a notification channel.
  2. On the Vulnerabilities Policies page, select a desired Pipeline or Runtime policy.
  3. On the Edit Policy screen, under Notifications, specify the following:
  • Enable Notification by using the toggle.
  • Frequency: Specify the frequency of notifications for failed policies. This is the silence period during which no additional notification will be generated.
  • Channel: Select a notification channel.
  1. Click Save to complete creating the policy.

Available Rules

Sysdig provides the following rules that are ready to use:

Vulnerability Rules

Severities and Threats

While scanning for vulnerabilities in software is a primary concern, it’s essential to recognize that reported vulnerabilities may not always be relevant to the specific production environment being analyzed. Moreover, achieving an environment completely devoid of vulnerabilities for a particular software package is unrealistic. Therefore, each organization establishes an acceptable risk threshold for a vulnerability. This threshold helps determine whether the evaluated asset falls within acceptable boundaries or should be considered non-compliant.

Sysdig enables you to assess severities and threats in hosts and workloads against the following conditions:

ParamtersConditionDescription
Severity- Equals
- Greater than or equals
Severity levels to verify against include:
Critical
High
Medium
Low
Negligible
CVSS Score- Equals
- Greater than or equals
CVSS Scores to verify against include:
Critical
High
Medium
Low
Negligible
Disclosure DateDaysIt is the date when the vulnerability was publicly disclosed. Specify the days where the disclosure date is older than or equal to.
FixableDaysSpecify the number of days by which it should be fixed. The value can be either of the following:
- Boolean: The rule checks if a fix available for the vulnerability.
- Boolean and a number of days: First, the rule checks if a fix is available for the vulnerability, and then it verifies if the fix has been open for a certain number of days. If the duration exceeds a specific threshold, the rule fails.
Exploitability Metrics- Public Exploit available
- No administrative privileges required
- No User interaction required
- Network attack vector required
- Packages
Public Exploit available: Triggers the rule if a piece of code or tool is available to exploit the vulnerability.
No administrative privileges: The rule fails if the vulnerable system can be exploited without requiring administrator privileges.
No user interaction required: The rule fails if the vulnerable system can be exploited without interaction from any user.
Network attack vector: The rule fails if the vulnerability can be attacked via network.
For more information, see CVSS

CVE Deny List

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

Image Configuration 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 changes. It comprises of image configuration details and metadata.

For example:

  • Entrypoint / CMD
  • Configured user
  • Environment variables
  • Labels
  • Author
  • Creation time
  • Build history

Dockerfiles VS Image Configuration: Dockerfiles specify a language used to generate the resulting image, which contain the mentioned Image Configuration file inside. Although Dockerfiles and Image Configuration files are closely related, they are not the same concept. Compliant Image Configuration files can be generated using development tools other than Docker/Dockerfiles.

Default User

The default user configured to run the entrypoint or CMD.

Defaulting to root discouraged, as it can grant unnecessary privileges and make it easier for an attacker to escalate privileges or move laterally if successfully exploited.

Apart from avoiding root, this rule also allows specifying a particular user, for example jenkins, that must be set. Missing to set a user will result in rule failure.

Image Label

Check for labels configured in the Image Configuration file.

Environment Variables

Check for environment variables configured in the Image Configuration file.

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

Package Manager Instructions

This rule prohibits the use of package manager instructions, following recommended security practices. Directly fetching the latest available version of a package using a package manager during image build can lead to non-reproducible builds, and therefore the practice is discouraged.

The following package managers and update subcommands are currently detected from the image 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 serve as an indicator that the image has become stale. As the image creation date is an optional attribute, this rule will also fail if the date has not been declared.

Sensitive Information and Secrets

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

For example, violation of an AWS secret found in the image label AWS_TOKEN includes the following:

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

The current implementation uses a simple pattern matching technique with a regex check for keywords. Consequently, there is a risk of false positives if the keywords appear elsewhere in the metadata, such as in a filename.