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 Enterprise 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 Repositories”, “SBOMs”, or “Container Images” that will define the artifact type of the Rule Set.
Currently, only the
Vulnerabilities Gate and the following Triggers are available for Source Repository and SBOM 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 selected 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 parameter. Required parameters 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”.
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.
To learn more about how Anchore Enterprise policies are structured and evaluated, see
Policy.
1 - 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. | | | |
2 - 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.
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 | | | |
3 - 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 | < |
4 - Gate: dockerfile
Introduction
This article reviews the “dockerfile” gate and its triggers. The dockerfile gate allows users to perform checks on the content of the dockerfile or docker history for an image and make policy actions based on the construction of an image, not just its content. This is particularly useful for enforcing best practices or metadata inclusion (e.g. labels) on images.
Anchore Enterprise is either given a dockerfile or infers one from the docker image layer history. There are implications to what data is available and what it means depending on these differing sources, so first, we’ll cover the input data for the gate and how it impacts the triggers and parameters used.
The “dockerfile”
The data that this gate operates on can come from two different sources:
- The actual dockerfile used to build an image, as provided by the user at the time of running
anchorectl image add <img ref> --dockerfile <filename> or the corresponding API call to: POST /images?dockerfile= - The history from layers as encoded in the image itself (see
docker history <img> for this output)
All images have data from history available, but data from the actual dockerfile is only available when a user provides it. This also means that any images analyzed by the tag watcher functionality will not have an actual dockerfile.
The FROM line
In the actual dockerfile, the FROM instruction is preserved and available as used to build the image, however in the history data, the FROM line will always be the very first FROM instruction used to build the image and all of its dependent based image. Thus, for most images, the value in the history will be omitted and Anchore Enterprise will automatically infer a FROM scratch line, which is logically inserted for this gate if the dockerfile/history does not contain an explicit FROM entry.
For example, using the docker.io/jenkins/jenkins image:
IMAGE CREATED CREATED BY SIZE COMMENT
sha256:3b9c9666a66e53473c05a3c69eb2cb888a8268f76935eecc7530653cddc28981 11 hours ago /bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh 8.79kB
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh 3.96kB
<missing> 11 hours ago /bin/sh -c #(nop) ENTRYPOINT ["/sbin/tini" "--" "/usr/local/bin/jenkins.sh"] 0B
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:dc942ca949bb159f81bbc954773b3491e433d2d3e3ef90bac80ecf48a313c9c9 in /bin/tini 529B
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:a8f986413b77bf4d88562b9d3a0dce98ab6e75403192aa4d4153fb41f450843d in /usr/local/bin/jenkins.sh 1.45kB
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:55594d9d2aed007553a6743a43039b1a48b30527f8fb991ad93e1fd5b1298f60 in /usr/local/bin/jenkins-support 6.12kB
<missing> 11 hours ago /bin/sh -c #(nop) USER jenkins 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV COPY_REFERENCE_FILE_LOG=/var/jenkins_home/copy_reference_file.log 0B
<missing> 11 hours ago /bin/sh -c #(nop) EXPOSE 50000 0B
<missing> 11 hours ago /bin/sh -c #(nop) EXPOSE 8080 0B
<missing> 11 hours ago |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref 328B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_UC=https://updates.jenkins.io 0B
<missing> 11 hours ago |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war && echo "${JENKINS_SHA} /usr/share/jenkins/jenkins.war" | sha256sum -c - 76MB
<missing> 11 hours ago /bin/sh -c #(nop) ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_VERSION=2.161 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG JENKINS_VERSION 0B
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:c84b91c835048a52bb864c1f4662607c56befe3c4b1520b0ea94633103a4554f in /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy 328B
<missing> 11 hours ago |7 TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini && curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc && gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg && gpg --verify /sbin/tini.asc && rm -rf /sbin/tini.asc /root/.gnupg && chmod +x /sbin/tini 866kB
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:653491cb486e752a4c2b4b407a46ec75646a54eabb597634b25c7c2b82a31424 in /var/jenkins_home/tini_pub.gpg 7.15kB
<missing> 11 hours ago /bin/sh -c #(nop) ARG TINI_VERSION=v0.16.1 0B
<missing> 11 hours ago |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p /usr/share/jenkins/ref/init.groovy.d 0B
<missing> 11 hours ago /bin/sh -c #(nop) VOLUME [/var/jenkins_home] 0B
<missing> 11 hours ago |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p $JENKINS_HOME && chown ${uid}:${gid} $JENKINS_HOME && groupadd -g ${gid} ${group} && useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user} 328kB
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_SLAVE_AGENT_PORT=50000 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_HOME=/var/jenkins_home 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG JENKINS_HOME=/var/jenkins_home 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG agent_port=50000 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG http_port=8080 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG gid=1000 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG uid=1000 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG group=jenkins 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG user=jenkins 0B
<missing> 11 hours ago /bin/sh -c apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/* 0B
<missing> 3 weeks ago /bin/sh -c set -ex; if [ ! -d /usr/share/man/man1 ]; then mkdir -p /usr/share/man/man1; fi; apt-get update; apt-get install -y --no-install-recommends openjdk-8-jdk="$JAVA_DEBIAN_VERSION" ; rm -rf /var/lib/apt/lists/*; [ "$(readlink -f "$JAVA_HOME")" = "$(docker-java-home)" ]; update-alternatives --get-selections | awk -v home="$(readlink -f "$JAVA_HOME")" 'index($3, home) == 1 { $2 = "manual"; print | "update-alternatives --set-selections" }'; update-alternatives --query java | grep -q 'Status: manual' 348MB
<missing> 3 weeks ago /bin/sh -c #(nop) ENV JAVA_DEBIAN_VERSION=8u181-b13-2~deb9u1 0B
<missing> 3 weeks ago /bin/sh -c #(nop) ENV JAVA_VERSION=8u181 0B
<missing> 3 weeks ago /bin/sh -c #(nop) ENV JAVA_HOME=/docker-java-home 0B
<missing> 3 weeks ago /bin/sh -c ln -svT "/usr/lib/jvm/java-8-openjdk-$(dpkg --print-architecture)" /docker-java-home 33B
<missing> 3 weeks ago /bin/sh -c { echo '#!/bin/sh'; echo 'set -e'; echo; echo 'dirname "$(dirname "$(readlink -f "$(which javac || which java)")")"'; } > /usr/local/bin/docker-java-home && chmod +x /usr/local/bin/docker-java-home 87B
<missing> 3 weeks ago /bin/sh -c #(nop) ENV LANG=C.UTF-8 0B
<missing> 3 weeks ago /bin/sh -c apt-get update && apt-get install -y --no-install-recommends bzip2 unzip xz-utils && rm -rf /var/lib/apt/lists/* 2.21MB
<missing> 3 weeks ago /bin/sh -c apt-get update && apt-get install -y --no-install-recommends bzr git mercurial openssh-client subversion procps && rm -rf /var/lib/apt/lists/* 142MB
<missing> 3 weeks ago /bin/sh -c set -ex; if ! command -v gpg > /dev/null; then apt-get update; apt-get install -y --no-install-recommends gnupg dirmngr ; rm -rf /var/lib/apt/lists/*; fi 7.81MB
<missing> 3 weeks ago /bin/sh -c apt-get update && apt-get install -y --no-install-recommends ca-certificates curl netbase wget && rm -rf /var/lib/apt/lists/* 23.2MB
<missing> 3 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 3 weeks ago /bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in / 101MB
Where the actual dockerfile for that image is:
FROM openjdk:8-jdk-stretch
RUN apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/*
ARG user=jenkins
ARG group=jenkins
ARG uid=1000
ARG gid=1000
ARG http_port=8080
ARG agent_port=50000
ARG JENKINS_HOME=/var/jenkins_home
ENV JENKINS_HOME $JENKINS_HOME
ENV JENKINS_SLAVE_AGENT_PORT ${agent_port}
# Jenkins is run with user `jenkins`, uid = 1000
# If you bind mount a volume from the host or a data container,
# ensure you use the same uid
RUN mkdir -p $JENKINS_HOME \
&& chown ${uid}:${gid} $JENKINS_HOME \
&& groupadd -g ${gid} ${group} \
&& useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user}
# Jenkins home directory is a volume, so configuration and build history
# can be persisted and survive image upgrades
VOLUME $JENKINS_HOME
# `/usr/share/jenkins/ref/` contains all reference configuration we want
# to set on a fresh new installation. Use it to bundle additional plugins
# or config file with your custom jenkins Docker image.
RUN mkdir -p /usr/share/jenkins/ref/init.groovy.d
# Use tini as subreaper in Docker container to adopt zombie processes
ARG TINI_VERSION=v0.16.1
COPY tini_pub.gpg ${JENKINS_HOME}/tini_pub.gpg
RUN curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini \
&& curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc \
&& gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg \
&& gpg --verify /sbin/tini.asc \
&& rm -rf /sbin/tini.asc /root/.gnupg \
&& chmod +x /sbin/tini
COPY init.groovy /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy
# jenkins version being bundled in this docker image
ARG JENKINS_VERSION
ENV JENKINS_VERSION ${JENKINS_VERSION:-2.121.1}
# jenkins.war checksum, download will be validated using it
ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919
# Can be used to customize where jenkins.war get downloaded from
ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/${JENKINS_VERSION}/jenkins-war-${JENKINS_VERSION}.war
# could use ADD but this one does not check Last-Modified header neither does it allow to control checksum
# see https://github.com/docker/docker/issues/8331
RUN curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war \
&& echo "${JENKINS_SHA} /usr/share/jenkins/jenkins.war" | sha256sum -c -
ENV JENKINS_UC https://updates.jenkins.io
ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental
ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals
RUN chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref
# for main web interface:
EXPOSE ${http_port}
# will be used by attached slave agents:
EXPOSE ${agent_port}
ENV COPY_REFERENCE_FILE_LOG $JENKINS_HOME/copy_reference_file.log
USER ${user}
COPY jenkins-support /usr/local/bin/jenkins-support
COPY jenkins.sh /usr/local/bin/jenkins.sh
COPY tini-shim.sh /bin/tini
ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/jenkins.sh"]
# from a derived Dockerfile, can use `RUN plugins.sh active.txt` to setup /usr/share/jenkins/ref/plugins from a support bundle
COPY plugins.sh /usr/local/bin/plugins.sh
COPY install-plugins.sh /usr/local/bin/install-plugins.sh
Anchore Enterprise will detect the history/dockerfile as this, if not explicitly provided (note order is reversed from docker history output, so it reads in same order as actual dockerfile):
[
{
"Size" : 45323792,
"Tags" : [],
"Comment" : "",
"Id" : "sha256:cd8eada9c7bb496eb685fc6d2198c33db7cb05daf0fde42e4cf5bf0127cbdf38",
"Created" : "2018-12-28T23:29:37.981962131Z",
"CreatedBy" : "/bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in / "
},
{
"Size" : 0,
"Tags" : [],
"Comment" : "",
"Id" : "<missing>",
"Created" : "2018-12-28T23:29:38.226681736Z",
"CreatedBy" : "/bin/sh -c #(nop) CMD [\"bash\"]"
},
{
"Size" : 10780911,
"Comment" : "",
"Tags" : [],
"CreatedBy" : "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends \t\tca-certificates \t\tcurl \t\tnetbase \t\twget \t&& rm -rf /var/lib/apt/lists/*",
"Created" : "2018-12-29T00:04:28.920875483Z",
"Id" : "sha256:c2677faec825930a8844845f55454ee0495ceb5bea9fc904d5b3125de863dc1d"
},
{
"Comment" : "",
"Tags" : [],
"Size" : 4340024,
"CreatedBy" : "/bin/sh -c set -ex; \tif ! command -v gpg > /dev/null; then \t\tapt-get update; \t\tapt-get install -y --no-install-recommends \t\t\tgnupg \t\t\tdirmngr \t\t; \t\trm -rf /var/lib/apt/lists/*; \tfi",
"Created" : "2018-12-29T00:04:34.642152001Z",
"Id" : "sha256:fcce419a96b1219a265bf7a933d66b585a6f8d73448533f3833c73ad49fb5e88"
},
{
"Size" : 50062697,
"Tags" : [],
"Comment" : "",
"Id" : "sha256:045b51e26e750443c84216071a1367a7aae0b76245800629dc04934628b4b1ea",
"CreatedBy" : "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends \t\tbzr \t\tgit \t\tmercurial \t\topenssh-client \t\tsubversion \t\t\t\tprocps \t&& rm -rf /var/lib/apt/lists/*",
"Created" : "2018-12-29T00:04:59.676112605Z"
},
... <truncated for brevity> ...
{
"Tags" : [],
"Comment" : "",
"Size" : 0,
"Id" : "<missing>",
"CreatedBy" : "/bin/sh -c #(nop) ENTRYPOINT [\"/sbin/tini\" \"--\" \"/usr/local/bin/jenkins.sh\"]",
"Created" : "2019-01-21T08:56:30.737221895Z"
},
{
"Size" : 1549,
"Tags" : [],
"Comment" : "",
"Id" : "sha256:283cd3aba8691a3b9d22d923de66243b105758e74de7d9469fe55a6a58aeee30",
"Created" : "2019-01-21T08:56:32.015667468Z",
"CreatedBy" : "/bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh "
},
{
"Comment" : "",
"Tags" : [],
"Size" : 3079,
"Created" : "2019-01-21T08:56:33.158854485Z",
"CreatedBy" : "/bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh ",
"Id" : "sha256:b0ce8ab5a5a7da5d762f25af970f4423b98437a8318cb9852c3f21354cbf914f"
}
]
NOTE: Anchore Enterprise processes the leading /bin/sh commands, so you do not have to include those in any trigger param config if using the docker history output.
The actual_dockerfile_only Parameter
The actual vs history impacts the semantics of the dockerfile gate’s triggers. To allow explicit control of the differences, most triggers in this gate includes a parameter: actual_dockerfile_only that if set to true or false will ensure the trigger check is only done on the source of data specified. If actual_dockerfile_only = true, then the trigger will evaluate only if an actual dockerfile is available for the image and will skip evaluation if not. If actual_dockerfile_only is false or omitted, then the trigger will run on the actual dockerfile if available, or the history data if the dockerfile was not provided.
Differences in data between Docker History and actual Dockerfile
With Actual Dockerfile:
- FROM line is preserved, so the parent tag of the image is easily available
- Instruction checks are all against instructions created during the build for that exact image, not any parent images
- When the actual_dockerfile_only parameter is set to true, all instructions from the parent image are ignored in policy processing. This may have some unexpected consequences depending on how your images are structured and layered (e.g. golden base images that establish common patterns of volumes, labels, healthchecks)
- COPY/ADD instructions will maintain the actual values used
- Multistage-builds in that specific dockerfile will be visible with multiple FROM lines in the output
With Docker History data, when no dockerfile is provided:
- FROM line is not accurate, and will nearly always default to ‘FROM scratch’
- Instructions are processed from all layers in the image
- COPY and ADD instructions are transformed into SHAs rather than the actual file path/name used at build-time
- Multi-stage builds are not tracked with multiple FROM lines, only the copy operations between the phases
Trigger: instruction
This trigger evaluates instructions found in the “dockerfile”.
Parameters
actual_dockerfile_only (optional): See above
instruction: The dockerfile instruction to check against. One of:
- ADD
- ARG
- COPY
- CMD
- ENTRYPOINT
- ENV
- EXPOSE
- FROM
- HEALTHCHECK
- LABEL
- MAINTAINER
- ONBUILD
- USER
- RUN
- SHELL
- STOPSIGNAL
- VOLUME
- WORKDIR
check: The comparison/evaluation to perform. One of: =, != , exists, not_exists, like, not_like, in, not_in.
value (optional): A string value to compare against, if applicable.
Examples
- Ensure an image has a HEALTHCHECK defined in the image (warn if not found).
{
"gate": "dockerfile",
"trigger": "instruction",
"action": "warn",
"parameters": [
{
"name": "instruction",
"value": "HEALTHCHECK"
},
{
"name": "check",
"value": "not_exists"
}
]
}
- Check for AWS environment variables set.
{
"gate": "dockerfile",
"trigger": "instruction",
"action": "stop",
"parameters": [
{
"name": "instruction",
"value": "ENV"
},
{
"name": "check",
"value": "like"
},
{
"name": "value",
"value": "AWS_.*KEY"
}
]
}
Trigger: effective_user
This trigger processes all USER directives in the dockerfile or history to determine which user will be used to run the container by default (assuming no user is set explicitly at runtime). The detected value is then subject to a allowlist or denylist filter depending on the configured parameters. Typically, this is used for denylisting the root user.
Parameters
actual_dockerfile_only (optional): See above
users: A string with a comma delimited list of username to check for.
type: The type of check to perform. One of: ‘denylist’ or ‘allowlist’. This determines how the value of the ‘users’ parameter is interpreted.
Examples
- Denylist root user.
{
"gate": "dockerfile",
"trigger": "effective_user",
"action": "stop",
"parameters": [
{
"name": "users",
"value": "root"
},
{
"name": "type",
"value": "denylist"
}
]
}
- Denylist root user but only if set in actual dockerfile, not inherited from parent image.
{
"gate": "dockerfile",
"trigger": "effective_user",
"action": "stop",
"parameters": [
{
"name": "users",
"value": "root"
},
{
"name": "type",
"value": "denylist"
},
{
"name": "actual_dockerfile_only",
"value": "true"
}
]
}
- Warn if the user is not either “nginx” or “jenkins”.
{
"gate": "dockerfile",
"trigger": "effective_user",
"action": "warn",
"parameters": [
{
"name": "users",
"value": "nginx,jenkins"
},
{
"name": "type",
"value": "allowlist"
}
]
}
Trigger: exposed_ports
This trigger processes the set of EXPOSE directives in the dockerfile/history to determine the set of ports that are defined to be exposed (since it can span multiple directives). It performs checks on that set to denylist/allowlist them based on parameter settings.
Parameters
actual_dockerfile_only (optional): See above
ports: String of comma delimited port numbers to be checked.
type: The type of check to perform. One of: ‘denylist’ or ‘allowlist’. This determines how the value of the ‘users’ parameter is interpreted.
Examples
- Allow only ports 80 and 443. Trigger will fire on any port defined to be exposed that is not 80 or 443.
{
"gate": "dockerfile",
"trigger": "exposed_ports",
"action": "warn",
"parameters": [
{
"name": "ports",
"value": "80,443"
},
{
"name": "type",
"value": "allowlist"
}
]
}
- Denylist ports 21 (ftp), 22 (ssh), and 53 (dns) . Trigger will fire a match on ports 21, 22, 53 if found in EXPOSE directives.
{
"gate": "dockerfile",
"trigger": "exposed_ports",
"action": "warn",
"parameters": [
{
"name": "ports",
"value": "21,22,53"
},
{
"name": "type",
"value": "denylist"
}
]
}
Trigger: no_dockerfile_provided
This trigger allows checks on the way the image was added, firing if the dockerfile was not explicitly provided at analysis time. This is useful in identifying and qualifying other trigger matches.
Parameters
None
Examples
- Raise a warning if no dockerfile was provided at analysis time .
{
"gate": "dockerfile",
"trigger": "no_dockerfile_provided",
"action": "warn",
"parameters": []
}
More 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. | | | |
5 - 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.
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 Enterprise’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.
In order to use this gate, the analyzer_config.yaml file for your Anchore Enterprise 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 parameter 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. | ignore dir | When set to true, the gate will not trigger if found on a directory. The default is false which will include evaluating directories as well as files | true |
6 - 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 Parameters: 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 | | | |
7 - 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.
License names are normalized to SPDX format. Please refer to the
SPDX License List for more information.
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 |
8 - Gate: malware
Introduction
The “Malware” Policy Gate allows users to apply compliance rules when malware has been detected within an image.
Anchore Enterprise uses ClamAV during image analysis to detect malware. ClamAV is an open-source antivirus toolkit and can be used to detect various kinds of malicious threats on a system. For additional details, please see Malware Scanning.
Please Note: Files in an image which are greater than 2GB will be skipped due to a limitation in ClamAV. Any skipped file will be identified with a Malware Signature as ANCHORE.FILE_SKIPPED.MAX_FILE_SIZE_EXCEEDED.
When performing Malware Scanning on these larger images, please expect an increase in your analysis time.
Reference: malware
| Trigger | Description | Parameters |
|---|
| scans | Triggers if the malware scanner has found any matches in the image. | |
| scan_not_run | Triggers if a file was skipped because it exceeded max file size. | Fire on Skipped Files |
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
9 - 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 |
10 - Gate: packages
Introduction
The “packages” gate allows users to perform checks against the packages discovered in an image SBOM. It provides triggers for requiring specific packages, denylisting unwanted packages, filtering on package metadata, and verifying package integrity against the package database.
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. Requires enable_package_db_load to be enabled. See Enable the Package Database. | 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. Requires enable_package_db_load to be enabled. See Enable the Package Database. | 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. Requires enable_package_db_load to be enabled. See Enable the Package Database. | 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 |
| denylist | Triggers if the evaluated image has a package installed that matches the named package optionally with a specific version as well. | version comparison | The type of comparison to use for version if a version is provided. | > |
| 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 |
Enable the Package Database
The verify trigger requires the package database to be loaded into the policy engine. This setting is disabled by default in newer deployments of Anchore Enterprise, though it was previously enabled by default. Only enable this setting if you intend to use the verify trigger, as loading the package database has a significant performance impact on the database.
You can confirm the current value of this setting from the System -> Configuration screen by searching for “load”.
To enable it, change enable_package_db_load from false to true:
services:
policy_engine:
enable_package_db_load: true
{% alert color=“warning” %}
If you re-enable this setting after it has been disabled, any images analyzed while the setting was disabled must be re-analyzed to populate the package database table. If you disable this setting after it was previously enabled, the underlying table must be manually truncated once the setting has been disabled and the services restarted.
{% /alert %}
11 - 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.
In order to use this gate, the values.yaml file for your Anchore Enterprise 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 |
12 - 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 resources and time to perform analysis on the image SBOM. For more information about cataloger scans, please click here.
The “retrieved_files” gate differs from the “files” gate. The “retrieved_files” gate utilizes Anchore Enterprise’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. |
13 - 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 Enterprise 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.
In order to use this gate, the analyzer_config.yaml file for your Anchore Enterprise 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 should 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 should 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 should 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 |
14 - Gate: stig
Introduction
The STIG policy gate is intended to deny an image that does not have at least one companion STIG evaluation stored
alongside of it. The STIG evaluation can be generated by using an AnchoreCTL workflow that will generate and upload
it to your Anchore Enterprise deployment.
For more information on the Anchore STIG feature, please see the Anchore STIG documentation.
Example Use-case
Scenario 1
Goal: Create a rule that results in a STOP action for images that do not contain a STIG evaluation.
Example rule set configuration in Anchore Enterprise
Gate: stig
Trigger: no stig evaluations available
Required Parameters: n/a
Recommendations (optional): “Perform STIG evaluation on image”
Action: STOP
Scenario 2
Goal: Create a rule that results in a STOP action for images where the uploaded STIG evaluations is older than 7 days.
Example rule set configuration in Anchore Enterprise
Gate: stig
Trigger: stig evaluations outdated
Required Parameters: max days since stig evaluation = “7”
Recommendations (optional): “Perform new STIG evaluation on image”
Action: STOP
Reference: stig
| Trigger Name | Description | Parameter | Description | Example |
|---|
| no stig evaluations available | Triggers if Anchore Enterprise does not have STIG evaluations for this image | n/a | n/a | n/a |
| stig evaluations outdated | Triggers if all of the uploaded STIG evaluations are outdated | max days since stig evaluation | The maximum age (in days) for any STIG evaluation - an image won’t trigger as long as it has at least one STIG evaluation within this window. | 7 |
15 - 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 |
16 - 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.
Currently, only the following Triggers are available for Source Repository and SBOM 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. Please note that days since fix begins when your Anchore Enterprise Deployment first sees there is a fix available. | 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 and Parent Images for more details. | True |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | epss score | The EPSS score to compare against. | 0.25 |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | epss_score_comparison | The type of comparison to perform for EPSS base score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | epss percentile | The EPSS percentile to compare against. | 87 |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | epss percentile comparison | The type of comparison to perform for EPSS percentile evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | known exploited vulnerability | If True, only trigger for vulnerabilities that are in the CISA KEV list (Known Exploited Vulnerability). | True |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | missing annotation | If true, only show vulnerabilities that are not annotated. | True |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | annotation status | Comma-separated list of annotation statuses to filter vulnerabilities. | affected |
| 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 |