Scanning Policy Gates and Triggers

This doc applies only to the Legacy Scanning engine. Make sure you are using the correct documentation: Which Scanning Engine to Use

This document describes the gates (and their respective triggers / parameters) that are supported within Sysdig Secure policy bundles. Use these policy gates, triggers, and parameters to build in-depth scanning policies, from whitelisting / blacklisting partial file names to defining what login shells are approved.

This information can also be obtained using the CLI:

user@host:~$ sdc-cli policy describe (--gate <gatename> (--trigger <triggername))

For more information, see Manage Scanning Policies and Dockerfile Gate and Triggers Deep Dive.

Always

This gate provides users with a valuable testing resource, as it will be triggered unconditionally.

always

The always trigger / gate will trip if it is present in the policy.

The Always gate is useful for testing whether the image blacklist/whitelist is working as expected.

Dockerfile

The dockerfile gate reviews the contents of a Dockerfile, or the assumed contents of a dockerfile if one is not provided, for exposed ports and instructions that do not follow best practices.

The gate can assume what the contents would be based on the Docker layer history. See also: Dockerfile Gate and Triggers Deep Dive

effective_user

This trigger reviews whether the effective user matches the user provided, and will fire based on the configured type.

ParameterDescriptionExample
typeDetermines whether the user should be whitelisted or blacklisted.N/A
userThe name of the user.root,docker

exposed_ports

This trigger evaluates the set of exposed ports to determine whether they should be whitelisted or blacklisted.

ParameterDescriptionExample
actual_dockerfile_onlyDefines whether the evaluation should skip inferred or guessed Dockerfiles, and only evaluate user-provided Dockerfiles. The default value is false.true
portsA comma-separated list of port numbers.80,8080,8088
typeDefines whether the ports should be whitelisted or blacklisted.N/A

instruction

This trigger evaluates whether any directives/instructions in the list match the conditions in the Dockerfile.

ParameterDescriptionExample
actual_dockerfile_onlyDefines whether the evaluation should skip inferred or guessed dockerfiles, and only evaluate user-provided dockerfiles. The default value is false.true
checkThe type of check to perform.=
instructionThe dockerfile instruction to check.FROM
valueThe value to check the dockerfile instruction against.scratch

no_dockerfile_provided

This trigger will trip if there is no Dockerfile supplied with the image. No parameters are required for this trigger.

Files

The Files gate reviews files within the analyzed image. This evaluation covers file content, names, and filesystem attributes.

content_regex_match

This trigger is tripped for each file where a match has been found using the configured regex in the analyzer_config.yaml content_search section.

For more information regarding the regex values, refer to the analyzer_config.yaml file.

ParameterDescriptionExample
regex_nameThe regex string that appears in the FILECHECK_CONTENTMATCH analyzer parameter..*password.*

name_match

This trigger is tripped if the name of a file in the container matches the provided regex.

This trigger has a performance impact on policy evaluation.

ParameterDescriptionExample
regexThe regex to search for..*\.pem

suid_or_guid_set

This trigger is tripped for each file that has a set-user identification (SUID) or set-group identification (SGID) configured. No parameters are required.

Licenses

This gate is used to review software licenses found in the container image, to ensure, for example, that packages that violate internal company policy are not being used.

blacklist_exact_match

This trigger will be tripped if the image contains packages distributed under the exact license specified.

ParameterDescriptionExample
licensesA comma-separated list of license names to blacklist.GPLv2+,GPL-3+,BSD-2-clause

blacklist_partial_match

This trigger will be tripped if the image contains packages distributed under a license that includes the partial strings provided.

ParameterDescriptionExample
licensesA comma-separated list of strings to blacklist for licenses.LGPL,BSD

Metadata

This gate reviews image metadata, including the size, operating system, and architecture.

attribute

The attribute trigger is tripped if a named image metadata value matches the given condition.

ParameterDescriptionExample
attributeThe attribute name to check.size
checkThe operation to perform for the evaluation.>
valueThe value used for the evaluation.1073741824

Packages

The Packages gate reviews all packages within the image, verifying names, versions, and whitelisted / blacklisted packages.

blacklist

This trigger is tripped if the image contains packages that have been blacklisted by either name, or name and version.

ParameterDescriptionExample
nameThe name of blacklisted package/s.openssh-server
versionThe exact version of the package that should be blacklisted.1.0.1

required_package

The required_package trigger is tripped if the specified package / version is not found in the image.

ParameterDescriptionExample
nameThe name of the required package.libssl
versionThe required package version.1.10.3rc3
version_match_typeDefines whether the trigger should require the exact package and version (exact), or just a version of the package (minimum). This is only relevant if the version is defined.exact

verify

This trigger reviews the package integrity against the package database in the image, and is tripped for change or removal of content in either all or a defined list of directories provided.

ParameterDescriptionExample
checkDefines whether the check should focus on missing packages, changed packages, or all.changed
only_directoriesDefines the list of directories the check should be limited to./usr,/var/lib
only_packagesDefines the list of packages that should be verified.libssl,openssl

Passwd File

This gate reviews /etc/passwd for blacklisted users, groups, and shells.

blacklist_full_entry

This trigger trips if the whole password is found in the /etc/password file.

ParameterDescriptionExample
entryThe full entry to match in /etc/passwd.ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin

blacklist_groupids

This trigger is tripped if the designated group id/s are found in the /etc/passwd file.

ParameterDescriptionExample
group_idsA numeric, comma separated list of group ids that will cause the trigger to trip.999,20

blacklist_shells

This trigger will trip if a designated login shell is found under any user in the /etc/passwd file.

ParameterDescriptionExample
shellsThe list of shell commands to blacklist./bin/bash,/bin/zsh

blacklist_userids

This trigger will be tripped if the specified user ID is present in /etc/passwd.

ParameterDescriptionExample
user_idsThe numerical, comma-separated list of user IDs to blacklist.0,1

blacklist_usernames

The blacklist_usernames trigger will trip if the specified username is found in the /etc/passwd file.

ParameterDescriptionExample
user_namesA comma-separated list of usernames to blacklist.daemon,ftp

content_not_available

The content_not_available trigger will trip if the /etc/passwd file is not present in the image. No parameters are required.

Secret Scans

Secret scans determine, based on configured regex, whether secrets that could be available if an image was compromised have been baked into the image.

content_regex_checks

The content_regex_checks trigger trips if the content search analyzer finds a match with the configured and named regexes. Matches are filtered by the content_regex_name, and the filename_regex, if either are set.

The content_regex_name should be a value from the secret_search section of analyzer_config.yaml.

Parameter

Description

Example

content_regex_name

The name of the variable / content. If found in the image, this should trip the trigger.

The names available by default are AWS_ACCESS_KEY, AWS_SECRET_KEY, PRIV_KEY, DOCKER_AUTH, and API_KEY.

AWS_ACCESS_KEY

filename_regex

Filters the files that should be analyzed for the presence of the content_regex_name.

/etc/.*

Vulnerabilities

CVE / vulnerability checks can be used to ensure the included packages don’t have vulnerabilities above a set level, are older than a designated period, or if data is unavailable.

package

The package trigger is tripped if a vulnerability in an image matches the configured comparison criteria. The table below outlines the available parameters and criteria:

ParameterDescriptionExample
fix_availableIf present, the fix availability for the vulnerability record must match the value of the parameter.true
package_typeThe specific type of package.all
severityThe vulnerability severity.high
severity_comparisonThe type of comparison to perform for the security evaluation.>
vendor_onlyIf true, an available fix for this CVE must not be explicitly marked as “Won’t be addressed by the vendor”.true

stale_feed_data

The stale_feed_data trigger will be tripped if the CVE data is older than the window specified.

ParameterDescriptionExample
max_days_since_syncDetermines how old in days sync data can be before the trigger is tripped.10

vulnerability_data_unavailable

If no vulnerability data is available, the vulnerability_data_unavailable trigger will trip. No parameters are required for this trigger.