Vulnerability, Image Configuration and Content Rules

Rules are the individual security checks that make up a rule bundle. Each rule defines a specific condition or set of criteria to evaluate, such as vulnerability severity, package type, image configuration, or exploitability metrics. By combining multiple rules, you can create targeted policies that address your organization’s unique security and compliance requirements.

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:

Parameter	Condition(s)	Description
Severity	- Equals - Greater than or equals	Severity levels to verify against: - Critical - High - Medium - Low - Negligible
CVSS Score	- Equals - Greater than or equals	CVSS scores to verify against: - Critical - High - Medium - Low - Negligible
Disclosure Date	- Days - Date Range	- Days: The number of days since the vulnerability was publicly disclosed. Specify when the disclosure date is older than or equal to this value. - Date Range: Choose a specific range of disclosure dates (e.g., Jun 01, 2025 to Jun 25, 2025).
In Use	True or False	Detects at runtime only if the affected package is actively in use, as detected by Sysdig In-Use.
Fixable	- Days - Boolean - Boolean + Days	Specify if and when a fix is available: - Boolean: Checks if a fix exists for the vulnerability. - Boolean + Days: Checks if a fix exists and if it has been available for a certain number of days. Rule fails if threshold is exceeded.
Exploitability Metrics	- Public exploit available - No administrative privileges required - No user interaction required - Network attack vector required - Packages	- Public exploit available: Triggers rule if exploit code/tool exists. - No admin privileges: Rule fails if no admin privileges are needed to exploit. - No user interaction: Rule fails if no user interaction is needed. - Network attack vector: Rule fails if exploitable via the network. See CVSS for details.

Included in CISA KEV

Rule/Filter	Description
Included in CISA KEV	Flags vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.
CISA KEV available since X days ago	Filters vulnerabilities based on how long they have been in the KEV Catalog, measured in days.
CISA KEV due date in X days	Flags on CISA-KEV Vulnerabilities that have a due date within the specified time, measured in days.
Known to be used in Ransomware Campaigns	Flags vulnerabilities that are known to be leveraged in ransomware attacks.

Exploit Prediction Scoring System

Rule/Filter	Description
EPSS	Flags vulnerabilities with an Exploit Prediction Scoring System (EPSS) score, helping assess the likelihood of real-world exploitation.
EPSS Score greater than or equals X %	Filters vulnerabilities where the EPSS probability score meets or exceeds the specified percentage, indicating higher likelihood of exploitation.
EPSS Percentile greater than or equals X %	Filters vulnerabilities that fall within the top specified percentile of EPSS scores, focusing on vulnerabilities with the highest risk of exploitation.

CVE Deny List

If any vulnerability listed in this rule is detected, the rule will fail, regardless of severity or any other vulnerability attribute. e.g. CVE-2025-1974

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

The rule includes the following condition types that cause the policy to fail if detected:

User is root: Enforces not using root as the user of your container images.
User is not: Enforces the usage of a specific user in the configuration.
User in/not in: Enforces the usage or blocking of specific users in the configuration.

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

Sysdig does not recommend use of the ADD instruction is discouraged. 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:

Package Manager	Upgrade Command Regex
apk	.apk upgrade.
apt	.apt-get upgrade.
	.apt upgrade.
yum	.yum upgrade.
rpm	.*rpm (–upgrade
pip	.pip3 install (–upgrade
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:

Secret Type	Detection Pattern / Description
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 Key	N/A
Basic Auth	Detects `[http,ssh]://user@pass:domain.com`
JWT Token	N/A
Private Keys	Checks if string 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.

Image Content

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.

Feedback

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.