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))
This gate provides users with a valuable testing resource, as it will be triggered unconditionally.
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 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
This trigger reviews whether the effective user matches the user provided, and will fire based on the configured type.
|Determines whether the user should be whitelisted or blacklisted.||N/A|
|The name of the user.||root,docker|
This trigger evaluates the set of exposed ports to determine whether they should be whitelisted or blacklisted.
|Defines whether the evaluation should skip inferred or guessed Dockerfiles, and only evaluate user-provided Dockerfiles. The default value is ||true|
|A comma-separated list of port numbers.||80,8080,8088|
|Defines whether the ports should be whitelisted or blacklisted.||N/A|
This trigger evaluates whether any directives/instructions in the list match the conditions in the Dockerfile.
|Defines whether the evaluation should skip inferred or guessed dockerfiles, and only evaluate user-provided dockerfiles. The default value is ||true|
|The type of check to perform.||=|
|The value to check the ||scratch|
This trigger will trip if there is no Dockerfile supplied with the image. No parameters are required for this trigger.
The Files gate reviews files within the analyzed image. This evaluation covers file content, names, and filesystem attributes.
This trigger is tripped for each file where a match has been found using
the configured regex in the
For more information regarding the regex values, refer to the
|The regex string that appears in the ||.*password.*|
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.
|The regex to search for.||.*\.pem|
This trigger is tripped for each file that has a set-user identification (SUID) or set-group identification (SGID) configured. No parameters are required.
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.
This trigger will be tripped if the image contains packages distributed under the exact license specified.
|A comma-separated list of license names to blacklist.||GPLv2+,GPL-3+,BSD-2-clause|
This trigger will be tripped if the image contains packages distributed under a license that includes the partial strings provided.
|A comma-separated list of strings to blacklist for licenses.||LGPL,BSD|
This gate reviews image metadata, including the size, operating system, and architecture.
The attribute trigger is tripped if a named image metadata value matches the given condition.
|The attribute name to check.||size|
|The operation to perform for the evaluation.||>|
|The value used for the evaluation.||1073741824|
The Packages gate reviews all packages within the image, verifying names, versions, and whitelisted / blacklisted packages.
This trigger is tripped if the image contains packages that have been blacklisted by either name, or name and version.
|The name of blacklisted package/s.||openssh-server|
|The exact version of the package that should be blacklisted.||1.0.1|
required_package trigger is tripped if the specified package /
version is not found in the image.
|The name of the required package.||libssl|
|The required package version.||1.10.3rc3|
|Defines 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|
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.
|Defines whether the check should focus on missing packages, changed packages, or all.||changed|
|Defines the list of directories the check should be limited to.||/usr,/var/lib|
|Defines the list of packages that should be verified.||libssl,openssl|
This gate reviews
/etc/passwd for blacklisted users, groups, and
This trigger trips if the whole password is found in the
|The full entry to match in ||ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin|
This trigger is tripped if the designated group id/s are found in the
|A numeric, comma separated list of group ids that will cause the trigger to trip.||999,20|
This trigger will trip if a designated login shell is found under any
user in the
|The list of shell commands to blacklist.||/bin/bash,/bin/zsh|
This trigger will be tripped if the specified user ID is present in
|The numerical, comma-separated list of user IDs to blacklist.||0,1|
blacklist_usernames trigger will trip if the specified username is
found in the
|A comma-separated list of usernames to blacklist.||daemon,ftp|
content_not_available trigger will trip if the
is not present in the image. No parameters are required.
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 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
either are set.
content_regex_name should be a value from the secret_search
The name of the variable / content. If found in the image, this should trip the trigger.
The names available by default are
Filters the files that should be analyzed for the presence of the
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.
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:
|If present, the fix availability for the vulnerability record must match the value of the parameter.||true|
|The specific type of package.||all|
|The vulnerability severity.||high|
|The type of comparison to perform for the security evaluation.||>|
|If true, an available fix for this CVE must not be explicitly marked as “Won’t be addressed by the vendor”.||true|
stale_feed_data trigger will be tripped if the CVE data is older
than the window specified.
|Determines how old in days sync data can be before the trigger is tripped.||10|
If no vulnerability data is available, the
vulnerability_data_unavailable trigger will trip. No parameters are
required for this trigger.
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.