Policy Gates
In this section of the document, we list and describe the current gates (and related triggers and parameters) that are supported within Anchore policy.
Getting Started
Before diving into the specifics of Policy Rule Sets and Gates, navigate to the Policies tab in order to create a new Policy.
Once a Policy has been created, you can start creating Rule Sets that define the Policy. When adding a new Rule Set, you will be prompted to select either “Source Repository” or “Container Images” that will define the source type of the Rule Set.
Note Currently, only the Vulnerabilities Gate and the following Triggers are available for Source Repository Rule Sets:
- Denylist
- Package
- Stale Feed Data
Components of a Policy Rule Set
A gate is a collection of checks that are logically grouped to provide a broader context for policy evaluations. It is the first step a user must set when creating a rule.
Once a gate has been selected, a list of associated triggers for the selecteed gate is provided. A trigger defines a specific condition to check within the context of the gate.
Once a trigger has been selected, a list of associated parameters are provided to customize the matched behavior of the rule. Please note that a trigger may contain both a required and optional paramater. Required paramaters must be configured in order to save a rule.
Finally, the last step in the process is to configure the action for every matched instance of a trigger. The available actions are “STOP”, “WARN”, and “GO”.
Note Please click here for more detailed information on the architectural framework of a policy rule set.
The final policy evaluation against an image SBOM will result in a failure if and only if at least one rule within any rule set in the active policy has been triggered with a “STOP” action.
Rule actions are set per rule and cannot interfere with other rules in the same policy. For example, if we create a policy with the same identical rule but with different actions (STOP and WARN), each rule will be evaluated independently resulting in a duplicate finding with the same trigger ID.
Note Please click here to learn more about Anchore’s policies.
1 - Gate: ancestry
Introduction
The “ancestry” gate gives users the ability to construct policy rules against an image’s ancestry, specifically the base and ancestor images. This gate becomes useful when a user needs to quickly identify if an image SBOM is not part of an organization’s approved set of base and/or ancestor images.
Base images is referred to the image that a given image was built from. It serves as a template for developers to create a standardized environment on top of which they can build their custom images (often referred to as a “golden” image).
Ancestor images is referred to the chain of images built from other images.
Note To understand the concept of base and ancestor images more, please click here.
Example Use-case
Scenario 1
Goal: Fail a policy evaluation if an image is not part of a list of approved base images.
Example rule set configuration in Anchore Enterprise
Gate: ancestry
Trigger: allowed base image digest
Required Parameters: base digest = “SHA256:abcdef123456”
Recommendation (Optional): The image is not derived from an approved base image. Remediation required.
Action: STOP
Reference: ancestry
| Trigger Name | Description | Parameter | Description | Example |
|---|
| allowed_base_image_digest | Checks to see if base image is approved | base_digest | List of approved base image digests. | sha256:123abc |
| allowed_base_image_tag | Checks to see if base image is approved | base_tag | List of approved base image tags. | docker.io/nginx:latest |
| denylist_ancestor_image_digest | Triggers if any of the ancestor images have the provided image digest(s) | ancestor_digest | List of ancestor image digests to check for. Accepts comma separated list of digests. | sha256:123abc |
| denylist_ancestor_image_tag | Triggers if any of the ancestor images have the provided image tag(s) | ancestor_tag | List of denied image tags to check the ancestry for. Accepts comma separated list of tags. | docker.io/nginx:latest |
| no_ancestors_analyzed | Checks to see if the image has a known ancestor | | | |
2 - Gate: distro
Introduction
The “distro” gate is solely intended to deny an image that is running on a specific distro. This is especially useful if a user wants to create a rule that can quickly discover any image SBOMs containing a specific version of a distro that is denied in their organization.
Example Use-case
Scenario 1
Goal: Create a rule that results in a STOP action for images that are running below Debian version 9.
Example rule set configuration in Anchore Enterprise
Gate: distro
Trigger: deny
Required Parameters: distro = “debian”, version = “9”, check = “<”
Recommendations (optional): “Image is running on an old version of Debian. Update required.”
Action: STOP
Reference: distro
| Trigger Name | Description | Parameter | Description | Example |
|---|
| deny | Triggers if the image distro and version match the criteria | distro | Name of the distribution to match | debian |
| deny | Triggers if the image distro and version match the criteria | version | Version of distribution to compare against | 9 |
| deny | Triggers if the image distro and version match the criteria | check | The comparison to use in the evaluation | < |
3 - Gate: dockerfile
Introduction
The “dockerfile” gate allows users to perform checks against a dockerfile or docker history for an image SBOM. This gate is especially useful when a user wants to create policy checks against not only the content, but the construction of an image SBOM.
The data that is collected by this gate depends on whether or not a dockerfile is provided by the user at the time of analysis. If a dockerfile is not provided, Anchore will collect the data from the layer history encoded in the image SBOM (docker history).
Note For further details in regards to the dockerfile gate, please see Policy Gate: dockerfile
Example Use-cases
Scenario 1
Goal: Create a rule that results in a STOP action for username “root” found in an image SBOM’s dockerfile “USER” line.
Example rule set configuration in Anchore Enterprise
Gate: dockerfile
Trigger: effective_user
Required Parameters: users = “root”, type = “denylist”
Recommendations (optional): “The username “root” is found in USER line. Fix required.”
Action: STOP
Scenario 2
Goal: Create a rule that results in a WARN action for usernames “nginx” or “jenkins” not found in an image SBOM’s dockerfile “USER” line.
Example rule set configuration in Anchore Enterprise
Gate: dockerfile
Trigger: effective_user
Required Parameters: users = “nginx,jenkins”, type = “allowlist”
Action: WARN
Scenario 3
Goal: Create a rule that results in a STOP action for any exposed AWS key environment variable found in an image SBOM’s dockerfile.
Example rule set configuration in Anchore Enterprise
Gate: dockerfile
Trigger: instruction
Required Parameters: instruction = “env”, check = “like”
Optional Parameters: value = “AWS_.*KEY”
Recommendations (optional): “AWS environment variable key found, Removal required.”
Action: STOP
Reference: dockerfile
| Trigger Name | Description | Parameter | Description | Example |
|---|
| instruction | Triggers if any directives in the list are found to match the described condition in the dockerfile. | instruction | The Dockerfile instruction to check. | from |
| instruction | Triggers if any directives in the list are found to match the described condition in the dockerfile. | check | The type of check to perform. | = |
| instruction | Triggers if any directives in the list are found to match the described condition in the dockerfile. | value | The value to check the dockerfile instruction against. | scratch |
| instruction | Triggers if any directives in the list are found to match the described condition in the dockerfile. | actual_dockerfile_only | Only evaluate against a user-provided dockerfile, skip evaluation on inferred/guessed dockerfiles. Default is False. | true |
| effective_user | Checks if the effective user matches the provided user names, either as a allowlist or blocklist depending on the type parameter setting. | users | User names to check against as the effective user (last user entry) in the images history. | root,docker |
| effective_user | Checks if the effective user matches the provided user names, either as a allowlist or blocklist depending on the type parameter setting. | type | How to treat the provided user names. | denylist |
| exposed_ports | Evaluates the set of ports exposed. Allows configuring allowlist or blocklist behavior. If type=allowlist, then any ports found exposed that are not in the list will cause the trigger to fire. If type=denylist, then any ports exposed that are in the list will cause the trigger to fire. | ports | List of port numbers. | 80,8080,8088 |
| exposed_ports | Evaluates the set of ports exposed. Allows configuring allowlist or blocklist behavior. If type=allowlist, then any ports found exposed that are not in the list will cause the trigger to fire. If type=denylist, then any ports exposed that are in the list will cause the trigger to fire. | type | Whether to use port list as a allowlist or denylist. | denylist |
| exposed_ports | Evaluates the set of ports exposed. Allows configuring allowlist or blocklist behavior. If type=allowlist, then any ports found exposed that are not in the list will cause the trigger to fire. If type=denylist, then any ports exposed that are in the list will cause the trigger to fire. | actual_dockerfile_only | Only evaluate against a user-provided dockerfile, skip evaluation on inferred/guessed dockerfiles. Default is False. | true |
| no_dockerfile_provided | Triggers if anchore analysis was performed without supplying the actual image Dockerfile. | | | |
4 - Gate: files
Introduction
The “files” gate performs checks against the files in an analyzed image SBOM and is useful when users need to create policies that trigger against any matched file content, names and/or attributes.
Note The “files” gate differs from the “retrieved_files” gate. The “files” gate searches against the files present in an image SBOM whereas the “retrieved_files” gate utilizes Anchore’s cataloger capability and checks against files that are provided and stored by the user before analysis.
Example Use-cases
Scenario 1
Goal: Create a rule that results in a STOP action for any file name that contains “.pem”, which may include information such as the public certificate or even an entire certificate chain (public key, private key, and root certificates) of an image SBOM.
Example rule set configuration in Anchore Enterprise
Gate: files
Trigger: name match
Required Parameters: regex = “.*\.pem”
Recommendations (optional): “Filename with “.pem” found - Remediation required.”
Action: STOP
Scenario 2
Goal: Create a rule that results in a STOP action for any file that matches against regex string “.*password.*” in an image SBOM.
Note In order to use this gate, the analyzer_config.yaml file for your Anchore deployment must have specific regex strings configured under the content_search section as the rule will only check against regex strings that appear in this list. Please use the optional parameter “regex name” if you want to specify a single string for your policy rule. If this paramater is not configured, then every regex string stored in the content_search section in the analyzer_config.yaml will be checked against.
Example rule set configuration in Anchore Enterprise
Gate: files
Trigger: content regex match
Optional Parameters: regex name = “ABC”
Recommendations (optional): “Regex string “.*password.*” found in file. Fix required.”
Action: STOP
analyzer_config.yaml file
Reference: files
| Trigger Name | Description | Parameter | Description | Example |
|---|
| content_regex_match | Triggers for each file where the content search analyzer has found a match using configured regexes in the analyzer_config.yaml “content_search” section. If the parameter is set, the trigger will only fire for files that matched the named regex. Refer to your analyzer_config.yaml for the regex values. | regex_name | Regex string that also appears in the FILECHECK_CONTENTMATCH analyzer parameter in analyzer configuration, to limit the check to. If set, will only fire trigger when the specific named regex was found in a file. | .password. |
| name_match | Triggers if a file exists in the container that has a filename that matches the provided regex. This does have a performance impact on policy evaluation. | regex | Regex to apply to file names for match. | .*.pem |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | filename | Filename to check against provided checksum. | /etc/passwd |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | checksum_algorithm | Checksum algorithm | sha256 |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | checksum | Checksum of file. | 832cd0f75b227d13aac82b1f70b7f90191a4186c151f9db50851d209c45ede11 |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | checksum_match | Checksum operation to perform. | equals |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | mode | File mode of file. | 00644 |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | mode_op | File mode operation to perform. | equals |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | skip_missing | If set to true, do not fire this trigger if the file is not present. If set to false, fire this trigger ignoring the other parameter settings. | true |
| suid_or_guid_set | Fires for each file found to have suid or sgid bit set. | | | |
5 - Gate: image_source_drift
Introduction
The “image source drift” gate allows users to perform checks against the difference between an image source repo SBOM and the build image SBOM. The difference operates by “contains” relationships where the analyzed image SBOM is the base “target” and the source revisions are the “source” for calculation.
Example Use-cases
Scenario 1
Goal: Create a rule that results in a STOP action for missing packages in an image SBOM that were supposed to be present based from the image source SBOM.
Example rule set configuration in Anchore Enterprise
Gate: image source drift
Trigger: package removed
Action: STOP
Scenario 2
Goal: Create a rule that results in a STOP action for npm packages found in an image SBOM with versions lower than the ones specified in the image source SBOM.
Example rule set configuration in Anchore Enterprise
Gate: image source drift
Trigger: package downgraded
Optional Paramaters: package types = “npm”
Action: STOP
Reference: image_source_drift
| Trigger Name | Description | Parameter | Description | Example |
|---|
| package_downgraded | Checks to see if any packages have a lower version in the built image than specified in the input source sboms | package_types | Types of package to filter by | java,npm |
| package_removed | Checks to see if any packages are not installed that were expected based on the image’s related input source sboms | package_types | Types of package to filter by | java,npm |
| no_related_sources | Checks to see if there are any source sboms related to the image. Findings indicate that the image does not have a source sbom to detect drift against | | | |
6 - Gate: licenses
Introduction
The “licenses” gate allows users to perform checks against found licenses in an image SBOM and perform different policy actions with available triggers.
Note The license names are normalized in Syft before the data is pulled into Anchore Enterprise
Example Use-case
Scenario 1
Goal: Create a rule that results in a STOP action for any “GNU packages” that are running on General Public License (GPL) version 2 or later.
Example rule set configuration in Anchore Enterprise
Gate: licenses
Trigger: denylist exact match
Required Parameters: licenses = “GPLv2+”
Action: STOP
Reference: licenses
| Trigger Name | Description | Parameter | Description | Example |
|---|
| denylist_exact_match | Triggers if the evaluated image has a package installed with software distributed under the specified (exact match) license(s). | licenses | List of license names to denylist exactly. | GPLv2+,GPL-3+,BSD-2-clause |
| denylist_exact_match | Triggers if the evaluated image has a package installed with software distributed under the specified (exact match) license(s). | package_type | Only trigger for specific package type. | all |
| denylist_partial_match | triggers if the evaluated image has a package installed with software distributed under the specified (substring match) license(s) | licenses | List of strings to do substring match for denylist. | LGPL,BSD |
| denylist_partial_match | triggers if the evaluated image has a package installed with software distributed under the specified (substring match) license(s) | package_type | Only trigger for specific package type. | all |
7 - Gate: malware
Introduction
The “malware” gate allows users to detect malware in an iamge SBOM through the use of ClamAV.
ClamAV is an open-source antivirus toolkit and can be used to detect various kinds of malicious threats on a system. Anchore pulls malware data from ClamAV and provides users the capability to create policy rules that triggers against malwares through the “malware” gate.
However, ClamAV has a limitation for the size of files that it can scan for a single image SBOM. Currently, the maximum allowable size of file that ClamAV can scan is 4GB. Additionally, utilizing the “malware” gate will impact analysis/scanning time as each analyzer service for the “malware” gate runs a malware signature update before analyzing each image SBOM. The duration of this latency depends on the size and number of files the image SBOM contains.
Note For detailed information about malware scanning, please click here
Example Use-case
Scenario 1
Goal: Create a rule that results in a STOP action if malware is detected on an image SBOM.
Example rule set configuration in Anchore Enterprise
Gate: malware
Trigger: scans
Action: STOP
Reference: malware
| Trigger | Description | Parameters |
|---|
| scans | Triggers if any malware scanner has found any matches in the image. | |
| scan_not_run | Triggers if no scan was found for the image. | |
8 - Gate: metadata
Introduction
The “metadata” gate provides users a variety of attributes to create policy rules that check against image SBOM metadata. Currently, the following attributes are provided in the “metadata” gate for policy rule creation:
- size
- architecture
- os type
- distro
- distro version
- like distro
- layer count
Example Use-case
Scenario 1
Goal: Create a rule that results in a STOP action for an image SBOM containing alpine OS.
Example rule set configuration in Anchore Enterprise
Gate: metadata
Trigger: attribute
Required Parameters: attribute = “os type”, check = “=”, value = “alpine”
Action: STOP
| Trigger Name | Description | Parameter | Description | Example |
|---|
| attribute | Triggers if a named image metadata value matches the given condition. | attribute | Attribute name to be checked. | size |
| attribute | Triggers if a named image metadata value matches the given condition. | check | The operation to perform the evaluation. | > |
| attribute | Triggers if a named image metadata value matches the given condition. | value | Value used in comparison. | 1073741824 |
9 - Gate: packages
Introduction
The “packages” gate allows users to perform checks against the packages discovered in an image SBOM.
Example Use-cases
Scenario 1
Goal: Create a rule that results in a STOP action if libssl packages are not found in an image SBOM.
Example rule set configuration in Anchore Enterprise
Gate: packages
Trigger: required package
Required Parameters: name = “libssl”
Action: STOP
Scenario 2
Goal: Create a rule that results in a STOP action if libssl-dev packages are found in an image SBOM but running on a version other than 1.1.1-1ubuntu2.1~18.04.23.
Example rule set configuration in Anchore Enterprise
Gate: packages
Trigger: metadata
Optional Parameters: name = “libssl-dev”, name comparison = “=”, version = “1.1.1-1ubuntu2.1~18.04.23”, version comparison = “!=”
Action: STOP
Reference: packages
| Trigger Name | Description | Parameter | Description | Example |
|---|
| required_package | Triggers if the specified package and optionally a specific version is not found in the image. | name | Name of package that must be found installed in image. | libssl |
| required_package | Triggers if the specified package and optionally a specific version is not found in the image. | version | Optional version of package for exact version match. | 1.10.3rc3 |
| required_package | Triggers if the specified package and optionally a specific version is not found in the image. | version_match_type | The type of comparison to use for version if a version is provided. | exact |
| verify | Check package integrity against package db in the image. Triggers for changes or removal or content in all or the selected “dirs” parameter if provided, and can filter type of check with the “check_only” parameter. | only_packages | List of package names to limit verification. | libssl,openssl |
| verify | Check package integrity against package db in the image. Triggers for changes or removal or content in all or the selected “dirs” parameter if provided, and can filter type of check with the “check_only” parameter. | only_directories | List of directories to limit checks so as to avoid checks on all dir. | /usr,/var/lib |
| verify | Check package integrity against package db in the image. Triggers for changes or removal or content in all or the selected “dirs” parameter if provided, and can filter type of check with the “check_only” parameter. | check | Check to perform instead of all. | changed |
| denylist | Triggers if the evaluated image has a package installed that matches the named package optionally with a specific version as well. | name | Package name to denylist. | openssh-server |
| denylist | Triggers if the evaluated image has a package installed that matches the named package optionally with a specific version as well. | version | Specific version of package to denylist. | 1.0.1 |
| metadata | Triggers on a package type comparison. | type | The type of package. | rpm |
| metadata | Triggers on a package name comparison. | name | The name of the package. Wildcards are supported. | *ssl |
| metadata | Triggers on a package version comparison. | version | The version of the package. Wildcards are supported. | *fips |
10 - Gate: passwd_file
Introduction
The “passwd_file” gate allows users to perform checks against /etc/passwd files with the retrieve_files cataloger. For more information about cataloger scans, please click here.
Example Use-case
Scenario 1
Goal: Create a rule that results in a STOP action for username “foobar” that is found in /etc/passwd in values.yaml file.
Note In order to use this gate, the values.yaml file for your Anchore deployment must have usernames configured for deny listing.
Example rule set configuration in Anchore Enterprise
Gate: passwd file
Trigger: denylist usernames
Required Parameters: user names = “foobar”
Action: STOP
Reference: passwd_file
| Trigger Name | Description | Parameter | Description | Example |
|---|
| content_not_available | Triggers if the /etc/passwd file is not present/stored in the evaluated image. | | | |
| denylist_usernames | Triggers if specified username is found in the /etc/passwd file | user_names | List of usernames that will cause the trigger to fire if found in /etc/passwd. | daemon,ftp |
| denylist_userids | Triggers if specified user id is found in the /etc/passwd file | user_ids | List of userids (numeric) that will cause the trigger to fire if found in /etc/passwd. | 0,1 |
| denylist_groupids | Triggers if specified group id is found in the /etc/passwd file | group_ids | List of groupids (numeric) that will cause the trigger ot fire if found in /etc/passwd. | 999,20 |
| denylist_shells | Triggers if specified login shell for any user is found in the /etc/passwd file | shells | List of shell commands to denylist. | /bin/bash,/bin/zsh |
| denylist_full_entry | Triggers if entire specified passwd entry is found in the /etc/passwd file. | entry | Full entry to match in /etc/passwd. | ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin |
11 - Gate: retrieved_files
Introduction
The “retrieved_files” gate allows users to check against the content and/or presence of files retrieved at the time of analysis for an image SBOM. The intent of this gate is to allow users to utilize the retrieve_files cataloger in order to create policy rules from a configured file list. However, the usage of this gate depends on running the retrieve_files cataloger which will require more resrouces and time to perform analysis on the image SBOM. For more information about cataloger scans, please click here.
Note The “retrieved_files” gate differs from the “files” gate. The “retrieved_files” gate utilizes Anchore’s cataloger capability and checks against files that are provided and stored by the user, while the “files” gate checks against the files present in the analyzed image SBOM (ie file content, file names, filesystem attributes)
Example Use-case
Scenario 1
Goal: Create a rule that results in a STOP action if the regex “SSIEnabled” is not found in the content of the file in the path /etc/httpd.conf.
Example rule set configuration in Anchore Enterprise
Gate: retrieved files
Trigger: content regex
Required Parameters: path = “/etc/httpd.conf”, check = “no match”, regex = “SSIEnabled”
Action: STOP
Reference: retrieved_files
| Trigger Name | Description | Parameter | Description | Example |
|---|
| content_not_available | Triggers if the specified file is not present/stored in the evaluated image. | path | The path of the file to verify has been retrieved during analysis | /etc/httpd.conf |
| content_regex | Evaluation of regex on retrieved file content | path | The path of the file to verify has been retrieved during analysis | /etc/httpd.conf |
| content_regex | Evaluation of regex on retrieved file content | check | The type of check to perform with the regex | match |
| content_regex | Evaluation of regex on retrieved file content | regex | The regex to evaluate against the content of the file | .SSlEnabled. |
12 - Gate: secret_scans
Introduction
The “secret_scans” gate allows users to perform checks against secrets and content found in an image SBOM using configured regexes found in the “secret_search” section of the analyzer_config.yaml file.
In order to use this gate effectively, ensure that regexes are properly configured in the analyzer_config.yaml file in the Anchore deployment. By default, the following names are made available in the “secret_search” section:
AWS_ACCESS_KEY
AWS_SECRET_KEY
PRIV_KEY
DOCKER_AUTH
API_KEY
Example Use-case
Scenario 1
Goal: Create a rule that results in a STOP action for disclosed AWS access key regex strings (that includes “/etc/.*) in an image SBOM.
Note In order to use this gate, the analyzer_config.yaml file for your Anchore deployment must have regexps named and configured.
If none of the optional parameters are used for the policy rule, by default, all regexp_match that are configured in the analyzer_config.yaml file will be checked.*
Example rule set configuration in Anchore Enterprise
Gate: secret scans
Trigger: content regex checks
Optional Parameters: content regex name = “AWS_ACCESS_KEY”, filename regex = “/etc/.*”, match type = “found”
Action: STOP
Reference: secret_scans
| Trigger Name | Description | Parameter | Description | Example |
|---|
| content_regex_checks | Triggers if the secret content search analyzer has found any matches with the configured and named regexes. Checks can be configured to trigger if a match is found or is not found (selected using match_type parameter). Matches are filtered by the content_regex_name and filename_regex if they are set. The content_regex_name shoud be a value from the “secret_search” section of the analyzer_config.yaml. | content_regex_name | Name of content regexps configured in the analyzer that match if found in the image, instead of matching all. Names available by default are: [‘AWS_ACCESS_KEY’, ‘AWS_SECRET_KEY’, ‘PRIV_KEY’, ‘DOCKER_AUTH’, ‘API_KEY’]. | AWS_ACCESS_KEY |
| content_regex_checks | Triggers if the secret content search analyzer has found any matches with the configured and named regexes. Checks can be configured to trigger if a match is found or is not found (selected using match_type parameter). Matches are filtered by the content_regex_name and filename_regex if they are set. The content_regex_name shoud be a value from the “secret_search” section of the analyzer_config.yaml. | filename_regex | Regexp to filter the content matched files by. | /etc/.* |
| content_regex_checks | Triggers if the secret content search analyzer has found any matches with the configured and named regexes. Checks can be configured to trigger if a match is found or is not found (selected using match_type parameter). Matches are filtered by the content_regex_name and filename_regex if they are set. The content_regex_name shoud be a value from the “secret_search” section of the analyzer_config.yaml. | match_type | Set to define the type of match - trigger if match is found (default) or not found. | found |
13 - Gate: tag_drift
Introduction
If evaluating by image tag, the “tag_drift” gate allows users to perform checks against packages that have been changed (added, removed, modified) on an image SBOM from the tag’s previous image SBOM.
Example Use-case
Scenario 1
Goal: Create a rule that results in a STOP action for any packages that have been modified in an evaluated image tag’s SBOM from the tag’s previous evaluation results.
Example rule set configuration in Anchore Enterprise
Gate: tag drift
Trigger: packages modified
Action: STOP
Reference: tag_drift
Gate: Tag Drift
Compares the SBOM from the evaluated image’s tag and the tag’s previous image, if found. Provides triggers to detect packages added, removed or modified.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| packages_added | Checks to see if any packages have been added. | package_type | Package type to filter for only specific types. If ommitted, then all types are evaluated. | apk |
| packages_removed | Checks to see if any packages have been removed. | package_type | Package type to filter for only specific types. If ommitted, then all types are evaluated. | apk |
| packages_modified | Checks to see if any packages have been modified. | package_type | Package type to filter for only specific types. If ommitted, then all types are evaluated. | apk |
14 - Gate: vulnerabilities
Introduction
The “vulnerabilities” gate provides users the ability to use either a single or combination of triggers and attributes that match against vulnerability metadata to create policies for the vulnerabilities discovered in an image SBOM.
Note Currently, only the following Triggers are available for Source Repository Rule Sets:
- Denylist
- Package
- Stale Feed Data
Example Use-cases
Scenario 1
Goal: Create a rule that results in a STOP action for every critical vulnerability.
Example rule set configuration in Anchore Enterprise
Gate: vulnerabilities
Trigger: package
Required Parameters: package type = “all”
Optional Parameters: severity comparison = “=”, severity = “critical”
Recommendations (optional): “Remediation is required for critical vulnerabilities.”
Action: STOP
Scenario 2
Goal: Create a rule that results in a STOP action for every vulnerability that is a part of CISA’s KEV list.
Example rule set configuration in Anchore Enterprise
Gate: vulnerabilities
Trigger: kev list
Recommendations (optional): “This vulnerability is part of CISA’s Known Exploited Vulnerability (KEV) catalogue. Remediation is required.”
Action: STOP
Scenario 3
Goal: Create a rule that results in a WARN action for every critical vulnerability with a fix that will not be addressed by a vendor.
Example rule set configuration in Anchore Enterprise
Gate: vulnerabilities
Trigger: package
Required Parameters: package type = “all”
Optional Parameters: severity comparison = “=”, severity = “critical”, vendor only = “false”
Recommendations (optional): “Even though this is a critical vulnerability, the vendor indicates that a fix will not be addressed.”
Action: WARN
Reference: vulnerabilities
| Trigger Name | Description | Parameter | Description | Example |
|---|
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | package_type | Only trigger for specific package type. | all |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | severity_comparison | The type of comparison to perform for severity evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | severity | Severity to compare against. | high |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_base_score_comparison | The type of comparison to perform for CVSS v3 base score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_base_score | CVSS v3 base score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_exploitability_score_comparison | The type of comparison to perform for CVSS v3 exploitability sub score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_exploitability_score | CVSS v3 exploitability sub score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_impact_score_comparison | The type of comparison to perform for CVSS v3 impact sub score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_impact_score | CVSS v3 impact sub score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | fix_available | If present, the fix availability for the vulnerability record must match the value of this parameter. | true |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_only | If True, an available fix for this CVE must not be explicitly marked as wont be addressed by the vendor | true |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | max_days_since_creation | A grace period, in days, for a vulnerability match to be present after which the vulnerability is a policy violation. Uses the date the match was first found for the given image. | 7 |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | max_days_since_fix | If provided (only evaluated when fix_available option is also set to true), the fix first observed time must be older than the days provided, to trigger. | 30 |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_base_score_comparison | The type of comparison to perform for vendor specified CVSS v3 base score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_base_score | Vendor CVSS v3 base score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_exploitability_score_comparison | The type of comparison to perform for vendor specified CVSS v3 exploitability sub score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_exploitability_score | Vendor CVSS v3 exploitability sub score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_impact_score_comparison | The type of comparison to perform for vendor specified CVSS v3 impact sub score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_impact_score | Vendor CVSS v3 impact sub score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | package_path_exclude | The regex to evaluate against the package path to exclude vulnerabilities | .test.jar |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | inherited_from_base | If true, only show vulns inherited from the base, if false than only show vulns not inherited from the base. Don’t specify to include vulns from the base image and the current image. See Base Images for more details. | True |
| denylist | Triggers if any of a list of specified vulnerabilities has been detected in the image. | vulnerability_ids | List of vulnerability IDs, will cause the trigger to fire if any are detected. | CVE-2019-1234 |
| denylist | Triggers if any of a list of specified vulnerabilities has been detected in the image. | vendor_only | If set to True, discard matches against this vulnerability if vendor has marked as will not fix in the vulnerability record. | True |
| stale_feed_data | Triggers if the CVE data is older than the window specified by the parameter MAXAGE (unit is number of days). | max_days_since_sync | Fire the trigger if the last sync was more than this number of days ago. | 10 |
| vulnerability_data_unavailable | Triggers if vulnerability data is unavailable for the image’s distro packages such as rpms or dpkg. Non-OS packages like npms and java are not considered in this evaluation | None | None | None |
| kev_list_data_missing | Triggers if the KEV list data has not been synced. | None | None | None |
| kev_list | Triggers if any vulns are on the KEV list. | None | None | None |
15 - Gate: always
Introduction
The “always” gate is intended for testing purposes and is advised against actual policy usage. The “always” gate only has one trigger that if it is part of a rule set, the policy evaluation will automatically result with the configured action (in most cases, “STOP”). This is especially useful when users want to test mappings and allowlists because they can use this rule in combination with other rules in a single rule set without having to manually create dedicated policies for running tests.
The gate will always trigger with the configured action if it is included inside an active policy.
Reference: always
| Trigger Name | Description | Parameter | Description | Example |
|---|
| always | Fires if present in a policy being evaluated. Useful for things like deny-listing images or testing mappings and allowlists by using this trigger in combination with policy mapping rules. | | | |