Vulnerability Policies

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 a 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. Log in to Sysdig Secure and navigate to Policies > Vulnerabilities | Rule Bundles.

2. Click +Add Rule Bundle.

   

3. 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. Rules are represented as “cards” on the UI. You can use the visual editor to create and configure new rules. The following conditions are supported:
     • Severity: Specify if the severity level is Greater than or equals or Equals to a curtail severity level.
       • Greater than or equal to: The severity condition checks for values that are greater than or equal to the specified severity level.
       • Equal to: The severity condition checks for values that are equal to the specified severity level.
     • CVSS Score: Specify if the CVSS score is Greater than or equals to a curtail CVSS score. The condition checks for values that are greater than or equal to the specified CVSS score.
     • Disclosure date: Specify if the vulnerability disclosure date is older than or equal to a certain number of days.
     • Fixable: Specify if the severities and threats have been fixable since how many days ago.
     • Package Type: Supported types are Operating System (OS) packages and application packages (Non-OS ). This option is supported only if your system has one of the following installed:
       • Sysdig CLI Scanner v1.10.0 or above
       • Sysdig Runtime Scanner v1.7.0 or above
       • Sysdig Host Scanner v0.10.0 or above
     • Package Deny List: Specify a specific version of a package. Enter the package using packagename or packagename x.x.x (including the version) format. Press tab or enter after each entry. When including the version, make sure to separate the package name and version with a single space, not a dash (-) or any other character. For example, libgnutls30 3.7.1-5+deb11u2.
     • Exploitability Metrics: The measures to assess the likelihood with which a vulnerability can be exploited by attackers. They have the four components: attack vector, attack complexity, privileges required, and user interaction. Select all that are applicable:
       • If a public exploit has been available since how many days ago
       • No administrative privileges required: Indicates administrative or similar access privileges are not required to exploit the vulnerability successfully.
       • No User interaction required: Indicates exploitation of a vulnerability can be done without any interaction from any user.
       • Network attack vector required: Indicates the level of access required for an attacker to exploit the vulnerability. Network attack vector refers to the vulnerability exploits that are through the OSI layer 3, implies they are remotely exploitable through the internet.

4. Click Save.

   Your new rule bundle will be visible on the list in the Rule Bundles page.

   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
• The package type is Operating System (OS)
• 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 any number of policies at the same time
• A policy can contain any number of rule bundles to be evaluated
• A rule bundle is composed of any number of rules to be evaluated

Create a Pipeline Policy

1. Navigate to Policies > Vulnerabilities | Pipeline Policies.

   The Pipeline scanning policy list is displayed.

2. Click +Add Policy > Pipeline Policy.

   

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

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

4. Click Save.

Create a Runtime Policy

1. Navigate to Policies > Vulnerabilities | Runtime Policies.

   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

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

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

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

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.

4. Click Save to complete creating the policy.

Available Rules

Sysdig provides a number of rules out-of-the-box.

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:

CVE Deny List

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

Package Deny List

Blocks one or more packages. You can provide a specific version of a package. Enter the package using packagename or packagename x.x.x (including the version) format. Press tab or enter after each entry. When including the version, make sure to separate the package name and version with a single space, not a dash (-) or any other character. For example, libgnutls30 3.7.1-5+deb11u2.

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

Default User

The default user configured to run the entrypoint or CMD.

Defaulting to root is 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. Failing 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.

Recommended Instructions

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"