Compliance Management

1 - Policies via UI

What is a policy?

A policy is composed of a set of rules that are used to perform an evaluation on a source repository or container image. These rules include—but are not limited to—checks on security, known vulnerabilities, configuration file contents, the presence of credentials, manifest changes, exposed ports, or any user defined checks.

Policies can be deployed site wide, or customized to run against specific sources, container images, or categories of application. For additional information, refer to the Policy concepts section.

Once a policy has been applied to a source repository or image container, it can return one of two results:

• indicating that source or image complies with your policy.

• indicating that the source or image is non-compliant with your policy.

Rules

Each rule contained within a policy is configured with a check to perform. For example, check if deny-listed package openssh-server present. The policy additionally specifies the action to take place, based on the result of the evaluation.

• STOP: Critical error that should stop the deployment by failing the policy evaluation.
• WARN: Issue a warning.
• GO: Okay to proceed.

Policy rule checks are made up of gates and triggers. A gate is a set of policy checks against broad categories like vulnerabilities, secret scans, licenses, and so forth. It will include one or more triggers, which are checks specific to the gate category.

Listing Policies

The area under the Policies sub-tab in the policy editor contains a table that lists the policies defined within a selected policy. The numeric indicator represents the overall number of polices currently defined in the policy.

Adjacent to each name in the policy list is a counter that indicates the number of rules within that policy.

Note: A lock icon next to the rule counter indicates that the policy cannot be deleted. Policy rules that are used by policy mappings in the policy (which will be listed under the Used By Mapping(s) column entry) cannot be deleted until they are removed from every associated mapping.

Tools

The Tools dropdown menu in the Actions column provides options to:

• Edit the policy

• Copy the policy

• Download the policy as a JSON document

• Delete the policy (if it is not being used by any policy mapping)

  

Adding a New Policy

You can add new rule sets to a policy.

1. Click Add New Rule Set.

2. Select Source Repository if you want the new policy to apply to a source, or select Container Image to have the policy apply to an image.

3. Type a uniqe name for the new policy (you can also add an optional description) and click OK.

4. From the Edit Source Repository Policy Rules modal, set up the policy rules for the new policy. Start by selecting an item from the Gate dropdown list, where each item represents a category of policy checks.

   Note: If you are creating a policy rule for a source repository, only vulnerabilities are available.

   

5. After selecting a gate item, hover over the (i) indicator next to Gate to see additional descriptive details about the gate you have selected.

6. Click the Triggers drop down and select a specific check that you want associated with this item, such as package, vulnerability data unavailable, and so on. Triggers may have parameters, some of which may be optional.

   If any optional parameters are associated with the trigger you select, these will also be displayed in an additional field where they can be added or removed. Optional parameters are described in more detail in the next section.

   

7. Select an action to apply to the policy rule. Choose STOP, WARN, or GO. The action options are only displayed once all required parameters have been provided, or if no mandatory parameters are required. Once an action has been selected, the rule is added to the main list of rules contained in the policy.

8. Click Save and Close.

Editing Rule Sets

Existing rule sets from a source repository or container image may be modified.

1. From Actions, either select Edit, or Tools > Edit Policy Rules. You can also copy a policy, download the policy to JSON, or delete the policy.

   

2. From the Edit Source Repository Policy Rules or Edit Container Image Policy Rules modal (depending on whether you choose to edit a policy for a source repository or container image), you can change the policy name and description.

   You can also change any documentation associated with individual policy rules by editing the descriptions presented within each row of the table.

   

   Note: If you are editing a policy rule for a source repository, only vulnerabilities are available under Gate.

The following example shows a sophisticated policy check. The metadata gate has a single trigger that allows checks to be performed against various attributes of an image, including image size, architecture, and operating system distribution:

The Attribute parameter drop-down includes a number of attributes taken from image metadata, including the operating system distribution, number of layers, and architecture of the image (AMD64, ARM, and so forth).

Once an attribute has been selected, the Check dropdown is used to create a comparison expression.

The type of comparison varies based on the attribute. For example the numeric comparison operators such as >, <, >= would be relevant for numeric field such as size, while other operators such as not in may be useful for querying data field such as distro.

In this example, by entering rhel centos oracle in the Value field, our rule will check that the distro (that is, the operating system) under analysis is not RHEL, Centos, or Oracle.

Optional Parameters

If a trigger has optional parameters, they will be automatically displayed in the policy editor, and an editable field next to the Triggers drop-down will show all the current selections.

You can remove unneeded optional parameters by clicking the X button associated with each entry in the Optional Parameters list, or by clicking the X button within each associated parameter block.

If an optional parameter is removed, it can be reapplied to the rule by clicking the Optional Parameters field and selecting it from the resulting dropdown list.

Editing Rules

After a rule has been added to the policy, you will see it in the the edit policy list page as a new entry.

1. The final action of each rule can be modified by clicking the STOP, WARN, or GO buttons.

   

2. Click Remove to get rid of any unwanted rules.

3. Click Edit to edit the policy rule again.

   

4. After modifying the existing rule, click Apply and the rule will be updated.

5. When you are satisfied that all your new (or updated) rules are correct, you can click Save new rule, and Close to update and store your policy.

1.1 - Policy

Introduction

The Policy Manager page shows a list of your policies. You can see the policy names, IDs, descriptions, when they were last updated, and which policies are active. From this view you can also create or add policies, as well as edit, copy, delete, or download policies.

Create a New Bundle.

Create a new policy and add it to the list of policies.

1. To add a new policy , click Create New Bundle.

   

2. Enter a unique name, along with an optional (but recommended) description for your new policy.

   

3. Click OK. Notice that when you create a new policy, it is populated with two policies. DefaultPolicy is for a container image, and DefaultSourcePolicy is for a source repository.

   

4. Start adding rules to your new policy. You can edit existing policies, add additional policies, add new mappings or edit existing mapping rules from either source repositories or container images, set up allow lists, or allowed/denied images for your policy.

Refresh a Policy

Click Refresh the Bundle Data if multiple users are accessing the Policy Manager, or if policy items are being added or removed through the API or AnchoreCTL then you may update the list of policies.

Rename a Policy

1. Click Edit Name to rename the policy.

   

2. Enter the new name.

3. Click the green check to rename the policy.

   

Policy Status

As described in the Managing Policies page, only one policy may be set as active (default). The management view for each policy includes a status indicator to represent the current status.

This label shows that the policy is active and that changes will have an immediate effect on your policy evaluation.

This label shows that the policy is not currently active and that changes can be made without altering the policy evaluation output.

Navigate Back to the Bundle List

Click Policies, or use the browsers navigation buttons to navigate back to the list of Policies.

Edit Bundle Content

You can edit the components of the policy at any time, including the policies, allowlists, mappings, and allowed or denied images.

Policies tab:

Edit or add policies and policy rules. See the Policies section for more information.

Allowlists tab:

Edit or add allowlists associated with the policy. See the Allowlists section for more information.

Mappings tab:

Edit or add mappings and mapping rules. See the Policy Mappings section for more information.

Allowed / Denied Images tab:

Edit or add images that you want allowed or denied in a policy. Each of the policy elements can be edited by selecting the appropriate tab in the navigation bar. See the Allowed / Denied Images section for more information.

1.2 - Policy Mappings

Introduction

The Mapping feature of the Policy Editor creates rules that define which policies and allowlists should be used to perform the policy evaluation of a source repository or container image based on the registry, repository name, and tag of the image.

The policy editor lets you set up different policies that will be used on different images based on the use case. For example the policy applied to a web-facing service may have different security and operational best practices rules than a database backend service.

Mappings are set up based on the registry, repository, and tag of an image. Each field supports wildcards. For example:

In this example,an image named registry.example.com/anchore/webapi:latest would match this mapping, and so the policy and allowlist configured for this mapping would be applied.

The mappings are applied in order, from top to bottom and the system will stop at the first match.

Note: The trusted images and denylisted images lists take precedence over the mapping. See Allowed / Denied Images for details.

If the policy includes no mappings, click the to add your first mapping.

The Add a New Mapping dialog will be displayed and includes mandatory fields for Name, Policy, Registry, Repository and Tag. The Allowlist(s) field is optional.

Each entry field includes an indicator showing if the current entry is valid or has errors .

In the following screenshot you can see multiple policy mappings have been defined some of which include one or more allowlists.

Image evaluation is performed sequentially from top to bottom. The system will stop at the first match so particular care should be paid to the ordering.

Mappings can be reordered using the buttons which will move a mapping up or down the list. Mappings may be deleted using the button.

It is recommended that a final catch all mapping is applied to ensure that all images are mapped to a policy. This catch-all mapping should specify wildcards in the registry, repository, and tag fields.

1.2.1 - Container Image Mapping

Introduction

The container image policy mapping editor creates rules that define which policies and allowlists should be used to perform the policy evaluation of an image based on the registry, repository name, and tag of the image.

Create a new Image Container Mapping

1. From the Policies screen, click Mappings.

2. Click Add New Mapping, then select Container Images to create the mapping from a container image.

   

3. From the Add New Container Image Mapping dialog, add a name for the mapping, the policy for which the mapping will apply (added automatically), a registry, a repository, and a tag. You can optionally add an allowlist and set the position for the mapping.

   

4. Using the policy editor, you can set up different policies that will be used on different images based on use case. For example the policy applied to a web facing service may have different security and operational best practices rules than a database backend service.

   Mappings are set up based on the registry, repository, and tag of an image. Each field supports wildcards. For example:

In this example, an imaged named registry.example.com/anchore/webapi:latest would match this mapping, so the policy and allowlist configured for this mapping would be applied.

The mappings are applied in order, from top to bottom and the system will stop at the first match.

Note: The allowed images and denied images lists take precedence over the mapping. See Allowed / Denied Images for details.

5. The empty policy includes no mappings. Click Let’s add one! to add your first mapping.

6. From Add a New Container Image Mapping, fill in the mandatory fields for Name, Policy, Registry, Repository and Tag. The Allowlists and Position fields are optional. See the following table for more information about these fields.

Each entry field includes an indicator showing if the current entry is valid or has errors .

Image evaluation is performed sequentially from top to bottom. The system will stop at the first match, so particular care should be paid to the ordering.

Mappings can be reordered using the buttons which will move a mapping up or down the list. Mappings may be deleted using the button.

It is recommended that a final catch-all mapping is applied to ensure that all container images are mapped to a policy. This catch-all mapping should specify wildcards in the registry, repository, and tag fields.

1.2.2 - Source Repository Mapping

The source repository policy mapping editor creates rules that define which policies and allowlists should be used to perform the policy evaluation of a source repository based on the host, and repository name.

Using the policy editor organizations can set up multiple policies that will be used on different source repositories based on use case. For example the policy applied to a web facing service may have different security and operational best practices rules than a database backend service.

Mappings are set up based on the Host and Repository of a source repository. Each field supports wildcards.

Create a Source Repository Mapping

1. From the Policies screen, click Mappings.

   

2. Click Add New Mapping, then select Source Repositories. By selecting source repositories, you are saying you want the new policy rule to apply to a source repository.

   

3. From the Add New Source Repository Mapping dialog, add a name for the mapping, choose the policy for which the mapping will apply, the position (optional) for the new mapping, a host (such as github.com), and a repository. You can optionally add an allowlist and set the position for the mapping.

   

4. Click OK to create the new mapping.

1.3 - Managing Policies

What is a Policy

A policy container includes the following elements:

• Rule Sets

  A policy is made up from a set of rules that are used to perform an evaluation on a source repository or container image. These rules can include checks on security vulnerabilities, package allowlists, denylists, configuration file contents, presence of credentials, manifest changes, exposed ports, or any user defined checks. These policies can be deployed site wide or customized for specific source repositories, container images, or categories of applications. A policy may contain one or more named rule sets.

• Allowlists

  An allowlist contains one or more exceptions that can be used during policy evaluation. For example allowing a CVE to be excluded from policy evaluation. A policy may contain multiple allowlists.

• Mappings

  A policy mapping defines which policies and allowlists should be used to perform the policy evaluation of a given source repository or container image. A policy may contain multiple mappings including wildcard mappings that apply to multiple elements.

• Allowed Image

  An allowed image defines one or more images that will always pass policy evaluation regardless of any policy violations. Allowed images can be specified by name, image ID, or image digest. A policy contains a single list of allowed images.

• Denied Images

  A denied Images list defines one or more images that will always fail policy evaluation. Denied images can be specified by name, image ID, or image digest. A policy contains a single list of denied images.

Policies

The Policy Manager displays a list of policies that are loaded in the system. Each policy has a unique name, unique ID (UUID), and an optional description.

Anchore Enterprise supports multiple policies. The Anchore API, CLI, and CI/CD plugins support specifying a policy when requesting an source repository or container image evaluation. For example, the development team may use a different set of policy checks than the operations team. In this case, the development team would specify their policy ID as part of their policy evaluation request.

If no policy ID is specified, then Anchore Enterprise will use the active policy which can be considered as the default policy. Only one policy can be set as default/active at any time. This policy will be highlighted with a green ribbon.

Note: policiess which are not marked as Active can still be explicitly requested as part of a policy evaluation.

If multiple users are accessing the Policy Manager, or if policy are being added or removed through the API or AnchoreCTL, then you may update the list of policies using the clicking Refresh the Bundle Data.

The following command can be run to list policies using AnchoreCTL:

# anchorectl policy list

Create a New Policy

1. To create a new, empty policy, click Create New Policy.

2. Add a name for the policy. This name should be unique.

3. Optional: You can add a description.

The following example shows a policy called test. Notice the unique Bundle ID (UUID) that was automatically created by Anchore Enterprise.

Upload a Policy Bundle

If you have a JSON document containing an existing policy, then you can upload it into Anchore Enterprise.

1. Click Add a Local File to upload or paste a valid policy JSON.

2. You can drag Policy Bundle files into the dropzone. Or, you can click the “Add a Local File” button to add from the local file system.

3. Click OK to perform a validation on a policy. Only validated policies may be stored by Anchore Enterprise.

Note: The following command can be run to add policies using AnchoreCTL

# anchorectl policy add --input /path/to/my/policy/bundle.json

Edit a Policy Bundle

You can edit existing policies at any time, including the policies, allowlists, mappings, and allowed or denied images.

1. Click Edit Policy to open the policy viewer which has the following options.

• Policies tab: Edit or add policies and policy rules. See the policies section for more information.

• Allowlists tab: Edit or add allowlists associated with the policy.

• Mappings tab: Edit or add mappings and mapping rules. See the Policy Mappings section for more information.

• Allowed / Denied Images tab: Edit or add images that you want allowed or denied in a policy. Each of the policy elements can be edited by selecting the appropriate tab in the navigation bar.

Copy an Existing Policy Bundle

If you already have a policy that you would like to use as a base for another policy, you can make a copy of it, give it a new name, and then work with the policies, mappings, allowlists, and allowed or denied images.

1. From the Tools list, select Copy Bundle.

2. Enter a unique name for the copy of the policy.

3. Optional: You can add a description to explain the new policy. This is recommended.

4. Click OK to copy the policy.

Delete a Policy Bundle

If you no longer use a policy, you can delete it. An active (default) policy cannot be deleted. To delete the active policy first you must mark another policy as active.

1. From the Tools menu, select Delete Bundle.

2. Click Yes to confirm that you want to delete the policy.

*Warning: Once the policy is deleted, you cannot recover it.

Note: Use the following command to delete a policy using AnchoreCTL. The policy must be referenced by its UUID. For example:

# anchorectl policy delete 4c1627b0-3cd7-4d0f-97da-00be5aa835f4

Download a Policy Bundle

1. From the Tools menu, select Download to JSON.

2. The JSON file is downloaded just like any other downloaded file to your computer. Save the downloaded JSON file to your location of choice.

Note: Use the following command to download a policy using AnchoreCTL. The policy must be referenced by its UUID. For example:

# anchorectl policy get 4c1627b0-3cd7-4d0f-97da-00be5aa835f4 --detail > policy.json

1.4 - Alowed / Denied Images

Introduction

You can add or edit allowed or denied images for your policy rules.

The Allowed / Denied Images tab is split into the following two sub tabs:

• Allowed Images: A list of images which will always pass policy evaluation irrespective of any policies that are mapped to them.

• Denied Images: A list if images which will always fail policy evaluation irrespective of any policies that are mapped to them.

  

Add an Allowed or Denied Image to Bundle

1. If you do not have any allowed or denied images in your policy, click Let’s add one! to add them.

The workflow for adding Allowed or Denied images is identical.

2. Images can be referenced in one of the following ways:

• By Name: including the registry, repository and tag. For example: docker.io/library/centos:latest

  The name does not have to be unique but it is recommended that the identifier is descriptive.

  

• By Image ID: including the full image ID. For example: e934aafc22064b7322c0250f1e32e5ce93b2d19b356f4537f5864bd102e8531f

  

  The full Image ID should be entered. This will be a 64 hex characters. There are a variety of ways to retrieve the ID of an image including using the anchorectl, Anchore UI, and Docker command.

• By Image Digest: including the registry, repository and image digest of the image. For example: docker.io/library/centos@sha256:989b936d56b1ace20ddf855a301741e52abca38286382cba7f44443210e96d16

  

3. Click OK to add the Allowed or Denied Image item to your policy.

See the following sections for more details about the Name, Image ID, and Image Digest.

For most use cases, it is recommended that the image digest is used to reference the image since an image name is ambiguous. Over time different images may be tagged with the same name.

If an image appears on both the Allowed Images and Denied Images lists, then the Denied Image takes precedence and the image will be failed.

Note: See Evaluating Images against Policies for details on image policy evaluation.

The Allowed Images list will show a list of any allowed images defined by the system includes the following fields:

• Allowlist Name A user friendly name to identify the image(s).

• Type Describes how the image has been specified. By Name, ID, or Digest.

• Image The specification used to define the image.

• Actions The actions you can set for the allowed image.

  The button can be used to copy the image specification into the clipboard.

  An existing image may be deleted using the or edited by pressed the button.

Adding an Image by Image ID

The full Image ID should be entered. This will be a 64 hex characters. There are a variety of ways to retrieve the ID of an image including using the anchorectl, Anchore UI and Docker command.

Using AnchoreCTL

$ anchorectl image get library/debian:latest | grep ID
ID: 8626492fecd368469e92258dfcafe055f636cb9cbc321a5865a98a0a6c99b8dd

Using Docker CLI

$ docker images --no-trunc debian:latest

REPOSITORY          TAG                 IMAGE ID                                                                  CREATED             SIZE
docker.io/debian    latest              sha256:8626492fecd368469e92258dfcafe055f636cb9cbc321a5865a98a0a6c99b8dd   3 days ago          101 MB

By default the docker CLI displays a short ID, the long ID is required and it can be displayed by using the –no-trunc parameter.

Note: The algorithm (sha256:) should not be entered into the Image ID field.

Adding an Image by Digest

When adding an image by Digest the following fields are required:

• Registry. For example: docker.io

• Repository. For example: library/debian

• Digest. For example: sha256:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f

The full identifier for this image is: docker.io/library/debian@sha256:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f

Note: The tag is not used when referencing an image by digest.

There are a variety of ways to retrieve the digest of an image including using the anchorectl, Anchore UI, and Docker command.

Using AnchoreCTL

$ anchorectl image get library/debian:latest | grep Digest
Digest: sha256:7df746b3af67bbe182a8082a230dbe1483ea1e005c24c19471a6c42a4af6fa82

Using Docker CLI

$ docker images --digests debian
REPOSITORY          TAG                 DIGEST                                                                    IMAGE ID            CREATED             SIZE
docker.io/debian    latest              sha256:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f   8626492fecd3        1 days ago          101 MB

Note: Unlike the Image ID entry, the algorithm (sha256:) is required.

Adding an Image by Name

When adding an image by Name, the following fields are required:

• Registry. For example: docker.io

• Repository. For example: library/debian

• Tag. For example: latest

Note: Wild cards are supported, so to trust all images from docker.io you would enter docker.io in the Registry field, and add a * in the Repository and Tag fields.

1.5 - Allowlists

Introduction

An allowlist contains one or more exceptions that can be used during policy evaluation. For example allowing a CVE to be excluded from policy evaluation.

The Allowlist tab shows a list of allowlists present in the policy. Allowlists are an optional element of the policy, and a policy may contain multiple instances.

Add a New Allowlist

1. Click Add New Allowlist to create a new, empty allowlist.

2. Add a name for the allowlist. A name is required and should be unique.

3. Optional: Add a description. A description is recommended. Often the description is updated as new entries are added to the allowlist to explain any background. For example “Updated to account for false positive in glibc library”.

   

Upload or Paste an Allowlist

If you have a JSON document containing an existing allowlist, then you can upload it into Anchore Enterprise.

1. Click Upload / Paste Allowlist to upload an allowlist. You can also manually edit the allowlist in the native JSON format.

   

2. Drag an allowlist file into the dropzone. Or, you can click the “Add a Local File” button and load it from a local filesystem.

3. Click OK to upload the allowlist. The system will perform a validation for the allowlist. Only validated allowlists may be stored by Anchore Enterprise.

Copying a Allowlists

You can copy an existing allowlist, give it a new name, and use it for a policy evaluation.

1. From the Tools drop down, select Copy Allowlist.

   

2. Enter a unique name for the allowlist.

3. Optional: Add a description. This is recommended. Often the description is updated as new entries are added to the allowlist to explain any background.

   

Downloading Allowlists

You can download an existing allowlists as a JSON file. From the Tools drop down, click Download to JSON.

Editing Allowlists

The Allowlists editor allows new allowlist entries to be created, and existing entries to be edited or removed.

1. Choose an allowlist to edit, then click Edit.

   

   Anchore Enterprise supports allowlisting any policy trigger, however the
   Allowlists editor currently supports only adding Anchore Security checks,
   allowing vulnerabilities to be allowlisted.

2. Choose a gate for the allowlist, for example, vulnerabilities.

   

   A vulnerabilities allowlists entry includes two elements: A CVE / Vulnerability Identifier and a Package.

3. Enter a CVE / Vulnerability Identifier. The CVE/Vulnerability Identifier field contains the vulnerability that should be matched by the allowlists. This can include wildcards.

   

   For example: CVE-2017-7246. This format should match the format of the CVEs shown in the image vulnerabilities report. Wildcards are supported, however, care should be taken with using wildcards to prevent allowlisting too many vulnerabilities.

4. Enter a package. The package name field contains the package that should be matched with a vulnerability. For example libc-bin.

   

   Wildcards are also supported within the Package name field.

   An allowlists entry may include entries for both the CVE and Package field to specify an exact match, for example: Vulnerability: CVE-2005-2541 Package: tar.

   In other cases, wildcards may be used where a multiple packages may match a vulnerability. For example, where multiple packages are built from the same source. Vulnerability: CVE-2017-9000 Package: bind-*

   In this example the packages bind-utils, bind-libs and bind-license will all be allowlisted for CVE-2017-9000.

   Special care should be taken with wildcards in the CVE / Vulnerability Identifier field. In most cases a specific vulnerability identifier will be entered. In some exceptional cases a wild card in this field may be appropriate.

   A good example of a valid use case for a wildcard in the CVE / Vulnerability Identifier field is the bind-license package. This package include a single copyright text file and is included by default in all CentOS:7 images.

   CVEs that are reported against the Bind project are typically applied to all packages built from the Bind source package. So when a CVE is found in Bind it is common to see a CVE reported against the bind-license package. To address this use case it is useful to add an allowlists entry for any vulnerability (*) to the bind-license package.

5. Optional: Click to edit an allowlist.

6. Optional: Click Remove to delete an allowlist.

7. Ensure that all changes are saved before exiting out of the Edit Allowlists Items Page. At that point the edits will be sent to Anchore Enterprise.

1.6 - Testing Policies

Introduction

The Evaluation Preview feature allows you to perform a test evaluation on an image to verify the mapping, policies and allowlists used to evaluate an image.

To test an image you should enter the name of the image, optionally including the registry if the image is not stored on docker.io In the example below an evaluate was requested for library/debian:latest because no registry was specified the default, docker.io registry was used.

Here we can see that the image was evaluated against the policy named “anchore_security_only” and the evaluate failed, the final action was Stop.

Clicking the “View Policy Test Details” will show a more detailed report.

The image was evaluating using the mapping named and the evaluation failed as the image was found in a denylist.

The next line explains that the image had been denylisted by the No centos denylist rule, however if the image was not denylisted it would only have produced a warning instead of a failure.

The subsequent table lists the policy checks that resulted in any Warning or Stop (failure) checks.

The policy checks are performed on images already analyzed and recorded in Anchore Enterprise. If an image has been added to the system but has not yet completed analysis then the system will display the following error:

If the evaluation test is re-run after a few minutes the image will likely have completed analysis and a policy evaluation result will be returned.

If the image specified has not been analyzed by the system and has not been submitted for analysis then the following error message will be displayed.

2 - Policies via CTL

Introduction

Policies are central to the concept of Anchore Enterprise, this article provides information on how to create, delete, update, and describe policies using AnchoreCTL to interact with a running Anchore Enterprise deployment.

At a high-level Anchore Enterprise consumes policies store in a Policy that contain:

• Policies
• Allowlists
• Mappings
• Allowlisted Images
• Denylisted Images

Anchore Enterprise can store multiple policies for each account, but only one policy can be active at any point in time. All users within an account share the same set of policies. It is common to store historic policies to allow previous policies and evaluations to be inspected. The active policy is the one used for evaluation for notifications, incoming kubernetes webhooks (unless configured otherwise), and other automatic system functions, but a user may request evaluation of any policy stored in the system using its id.

For more information on the content and semantics of policies see: Policies and Evaluation

Creating Policies

Policies are just JSON documents. Anchore Enterprise includes a default policy configured at installation that performs basic CVE checks as well as some Dockerfile checks.

To create custom polices, you may:

• Edit JSON manually and upload a file
• Use the Anchore Enterprise UI to edit policies

Managing Policies

Policies can be managed directly using the REST API or the anchorectl policy command.

Adding Policies using AnchoreCTL

The anchorectl tool allows you to upload policies to Anchore Enterprise.

# anchorectl policy add --input /path/to/policy/policy.json

Note: Adding a policy will not automatically set the policy to be active, you will need to activate the policy using the activate command.

Listing Policies

Anchore Enterprise may store multiple policies however at a given time only one policy may be active. Policies can be listed using the policy list command.

# anchorectl policy list
 ✔ Fetched policies
┌────────────────┬──────────────────────────────────────┬────────┬──────────────────────┐
│ NAME           │ POLICY ID                            │ ACTIVE │ UPDATED              │
├────────────────┼──────────────────────────────────────┼────────┼──────────────────────┤
│ Default policy │ 2c53a13c-1765-11e8-82ef-23527761d060 │ true   │ 2023-10-25T20:39:28Z │
│ devteam1policy │ da8208a2-c8ae-4cf2-a25b-a52b0cdcd789 │ false  │ 2023-10-25T20:47:16Z │
└────────────────┴──────────────────────────────────────┴────────┴──────────────────────┘

Each policy has a unique ID that will be reference in policy evaluation reports.

Note: Times are reported in UTC.

Viewing Policies

Using the policy get command, summary or detailed information about a policy can be retrieved. The policy is referenced using its unique id.

# anchorectl policy get 2c53a13c-1765-11e8-82ef-23527761d060
 ✔ Fetched policy
Name: Default policy
ID: 2c53a13c-1765-11e8-82ef-23527761d060
Comment: Default policy
Policies:
  - artifactType: image
    comment: System default policy
    id: 48e6f7d6-1765-11e8-b5f9-8b6f228548b6
    name: DefaultPolicy
    rules:
      - action: STOP
        gate: dockerfile
        id: ce7b8000-829b-4c27-8122-69cd59018400
        params:
          - name: ports
            value: "22"
          - name: type
            value: denylist
        trigger: exposed_ports
...
...

The policy can be downloaded in JSON format by passing the --detail parameter.

# anchorectl policy get 2c53a13c-1765-11e8-82ef-23527761d060 --detail -o json-raw > policy.json
 ✔ Fetched policy

Activating Policies

The policy activate command can be used to activate a policy. The policy is referenced using its unique id which can be retrieved using the policy list command.

# anchorectl policy activate 2c53a13c-1765-11e8-82ef-23527761d061
 ✔ Activate policy
┌─────────────────┬──────────────────────────────────────┬────────┬──────────────────────┐
│ NAME            │ POLICY ID                            │ ACTIVE │ UPDATED              │
├─────────────────┼──────────────────────────────────────┼────────┼──────────────────────┤
│ Default policy  │ 2c53a13c-1765-11e8-82ef-23527761d061 │ true   │ 2023-10-25T20:50:17Z │
└─────────────────┴──────────────────────────────────────┴────────┴──────────────────────┘

Deleting Policies

Policies can be deleted from Anchore Enterprise using the policy del command The policy is referenced using its unique id. A policy marked as active cannot be deleted, another policy has to be marked active before deleting the currently active policy.

# anchorectl policy delete 2c53a13c-1765-11e8-82ef-23527761d061
 ✔ Deleted policy
No results

See Anchore Policy Checks for information about available policy gates and triggers in Anchore Enterprise.

2.1 - Anchore Policy Checks

Introduction

In this document, we describe the current anchore gates (and related triggers and parameters) that are supported within anchore policy.

Gate: dockerfile

Checks against the content of a dockerfile if provided, or a guessed dockerfile based on docker layer history if the dockerfile is not provided.

Note For further information on usage see Policy Gate: Dockerfile

Gate: files

Checks against files in the analyzed image including file content, file names, and filesystem attributes.

Gate: passwd_file

Content checks for /etc/passwd for things like usernames, group ids, shells, or full entries.

Gate: packages

Distro package checks

Gate: vulnerabilities

CVE/Vulnerability checks.

Gate: licenses

License checks against found software licenses in the container image

Gate: ruby_gems

Ruby Gem Checks

Gate: npms

NPM Checks

Gate: secret_scans

Checks for secrets and content found in the image using configured regexes found in the “secret_search” section of analyzer_config.yaml.

Gate: metadata

Checks against image metadata, such as size, OS, distro, architecture, etc.

Gate: always

Triggers that fire unconditionally if present in policy, useful for things like testing and deny-listing.

Gate: retrieved_files

Checks against content and/or presence of files retrieved at analysis time from an image

Gate: Malware

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.

Gate: Image Source Drift

Triggers for evaluating diffs of an image’s source repo sbom and the built image. Operates on the diffs defined by ‘contains’ relationships where the image is the ‘source’ and the source revisions that are the ’target’ for the relationship.

Gate: Ancestry

Checks the image ancestry against approved images.

Gate: Distro

Checks against the image distro metadata. This can be used to denylist versions of a distro, such as versions that are EOL.

Next Steps

See how policy gates can be used in evaluation steps in Evaluating Images Against Policies

2.2 - Evaluating Images Against Policies

Introduction

The evaluate command can be used to evaluate a given image for policy compliance.

The image to be evaluated can be in the following format:

• Image Digest
• Image ID
• registry/repo:tag

Using the Evaluate command

# anchorectl image check docker.io/debian:latest
 ✔ Evaluated against policy                  [failed]                                                                                                                                                                                              docker.io/debian:latest
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:34:43Z
Evaluation: fail

By default, only the summary of the evaluation is shown. Passing the --detail parameter will show the policy checks that raised warnings or errors.

# anchorectl image check docker.io/debian:latest --detail
 ✔ Evaluated against policy                  [failed]                                                                                                                                                                                              docker.io/debian:latest
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:35:05Z
Evaluation: fail
Final Action: stop
Reason: policy_evaluation

Policy Evaluation Details:
┌─────────────────┬─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┐
│ GATE            │ TRIGGER     │ DESCRIPTION                                                                                                                                    │ STATUS │
├─────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ dockerfile      │ instruction │ Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check                                                            │ warn   │
│ vulnerabilities │ package     │ MEDIUM Vulnerability found in os package type (dpkg) - libgnutls30 (CVE-2011-3389 - https://security-tracker.debian.org/tracker/CVE-2011-3389) │ warn   │
│ vulnerabilities │ package     │ CRITICAL Vulnerability found in os package type (dpkg) - zlib1g (CVE-2022-37434 - https://security-tracker.debian.org/tracker/CVE-2022-37434)  │ stop   │
└─────────────────┴─────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┘

In this example we specified library/repo:tag which could be ambiguous. At the time of writing the image Digest for library/debian:latest was sha256:0fc..... however previously different images may have been tagged as library/debian:latest. The --history parameter can be passed to show historic evaluations based on previous images or previous policies.

Anchore supports allowlisting and denylisting images by their name, ID or digest. A denylist or allowlist takes precedence over any policy checks. For example if an image is explicitly listed as denylisted then even if all the individual policy checks pass the image will still fail evaluation.

# anchorectl image check docker.io/debian:latest --detail
 ✔ Evaluated against policy                  [failed]                                                                                                                                                                                              docker.io/debian:latest
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:39:36Z
Evaluation: fail
Final Action: stop
Reason: denylisted

Policy Evaluation Details:
┌─────────────────┬─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┐
│ GATE            │ TRIGGER     │ DESCRIPTION                                                                                                                                    │ STATUS │
├─────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ dockerfile      │ instruction │ Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check                                                            │ warn   │
│ vulnerabilities │ package     │ MEDIUM Vulnerability found in os package type (dpkg) - libgnutls30 (CVE-2011-3389 - https://security-tracker.debian.org/tracker/CVE-2011-3389) │ warn   │
└─────────────────┴─────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┘

In this example even though the image only had one policy check that raised a warning the image fails policy evaluation since it is present on a denylist.

Evaluating status based on Digest or ID

Performing an evaluation on an image specified by name is not recommended since an image name is ambiguous. For example the tag docker.io/library/centos:latest refers to whatever image has the tag library/centos:latest at the time of evaluation. At any point in time another image may be tagged as library/centos:latest.

It is recommended that images are referenced by their Digest. For example at the time of writing the digest of the ‘current’ library/centos:latest image is sha256:191c883e479a7da2362b2d54c0840b2e8981e5ab62e11ab925abf8808d3d5d44

If the image to be evaluated is specified by Image ID or Image Digest then the --tag parameter must be added. Policies are mapped to images based on registry/repo:tag so since an Image ID may may to multiple different names we must specify the name user in the evaluation.

For example - referencing by Image Digest:

# anchorectl image check docker.io/debian@sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc --detail --tag docker.io/debian:latest
 ✔ Evaluated against policy                  [failed]                                                                                                                             docker.io/debian@sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:44:24Z
Evaluation: fail
Final Action: stop
Reason: denylisted

Policy Evaluation Details:
┌─────────────────┬─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┐
│ GATE            │ TRIGGER     │ DESCRIPTION                                                                                                                                    │ STATUS │
├─────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ dockerfile      │ instruction │ Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check                                                            │ warn   │
│ vulnerabilities │ package     │ MEDIUM Vulnerability found in os package type (dpkg) - libgnutls30 (CVE-2011-3389 - https://security-tracker.debian.org/tracker/CVE-2011-3389) │ warn   │
│ vulnerabilities │ package     │ CRITICAL Vulnerability found in os package type (dpkg) - zlib1g (CVE-2022-37434 - https://security-tracker.debian.org/tracker/CVE-2022-37434)  │ stop   │
└─────────────────┴─────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┘

For example - referencing by image ID:

# anchorectl image check dd8bae8d259fed93eb54b3bca0adeb647fc07f6ef16745c8ed4144ada4d51a95  --detail --tag docker.io/debian:latest
 ✔ Evaluated against policy                  [failed]                                                                                                                                                     dd8bae8d259fed93eb54b3bca0adeb647fc07f6ef16745c8ed4144ada4d51a95
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:45:20Z
Evaluation: fail
Final Action: stop
Reason: denylisted

Policy Evaluation Details:
┌─────────────────┬─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┐
│ GATE            │ TRIGGER     │ DESCRIPTION                                                                                                                                    │ STATUS │
├─────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ dockerfile      │ instruction │ Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check                                                            │ warn   │
│ vulnerabilities │ package     │ MEDIUM Vulnerability found in os package type (dpkg) - libgnutls30 (CVE-2011-3389 - https://security-tracker.debian.org/tracker/CVE-2011-3389) │ warn   │
│ vulnerabilities │ package     │ CRITICAL Vulnerability found in os package type (dpkg) - zlib1g (CVE-2022-37434 - https://security-tracker.debian.org/tracker/CVE-2022-37434)  │ stop   │
└─────────────────┴─────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┘

2.3 - Policy Mappings

Mappings in the policy are a set of rules, evaluated in order, that describe matches on an image, id, digest, or tag and the corresponding sets of policies and allowlists to apply to any image that matches the rule’s criteria.

Policies can contain one or more mapping rules that are used to determine which rule_sets and allowlists apply to a given image. They match images on the registry and repository, and finally be one of id, digest, or tag.

A mapping has:

• Registry - The registry url to match, including wildcards (e.g. ‘docker.io’, ‘quay.io’, ‘gcr.io’, ‘*’)
• Repository - The repository name to match, including wildcards (e.g. ’library/nginx’, ‘mydockerhubusername/myrepositoryname’, ’library/*’, ‘*’)
• Image - The way to select an image that matches the registry and repository filters
  • type: how to reference the image and the expected format of the ‘value’ property
    • “tag” - just the tag name itself (the part after the ‘:’ in a docker pull string: e.g. nginx:latest -> ’latest’ is the tag name)
    • “id” - the image id
    • “digest” - the image digest (e.g. sha256@abc123)
  • value: the value to match against, including wildcards

Note: Unlike other parts of the policy, Mappings are evaluated in order and will halt on the first matching rule. This is important to understand when combined with wildcard matches since it enables sophisticated matching behavior.

Examples

Example 1, all images match a single catch-all rule:

[
  {
    "registry": "*",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "rule_set_ids": ["defaultpolicy"],
    "allowlist_ids": ["defaultallowlist"]
  }
]

Example 2, all “official” images from DockerHub are evaluated against officialspolicy and officialsallowlist (made up names for this example), while all others from DockerHub will be evaluated against defaultpolicy and defaultallowlist , and private GCR images will be evaluated against gcrpolicy and gcrallowlist:

[
  {
    "registry": "docker.io",
    "repository": "library/*",
    "image": { "type": "tag", "value": "*"},
    "rule_set_ids": [ "officialspolicy"],
    "allowlist_ids": [ "officialsallowlist"]
  },
  {
    "registry": "gcr.io",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "rule_set_ids": [ "gcrpolicy"],
    "allowlist_ids": [ "gcrallowlist"]
  },
  {
    "registry": "*",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "rule_set_ids": [ "defaultpolicy"],
    "allowlist_ids": [ "defaultallowlist"]
  }
]

Example 3, all images from a unknown registry will be evaluated against defaultpolicy and defaultallowlist, and an internal registry’s images will be evaluated against a different set (internalpolicy and internalallowlist):

[
  {
    "registry": "myregistry.mydomain.com:5000",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "policy_ids": [ "internalpolicy"],
    "allowlist_ids": [ "internalallowlist"]
  },
  {
    "registry": "*",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "policy_ids": [ "defaultpolicy"],
    "allowlist_ids": [ "defaultallowlist"]
  }
]

Using Multiple Policies and Allowlists

The result of the evaluation of the mapping section of a policy is the list of rule sets and allowlists that will be used for actually evaluating the image. Because multiple rule sets and allowlists can be specified in each mapping rule, you can use granular rule sets and allowlists and then combined them in the mapping rules.

Examples of schemes to use for how to split-up policies include:

• Different policies for different types of checks such that each policy only uses one or two gates (e.g. vulnerabilities, packages, dockerfile)
• Different policies for web servers, another for database servers, another for logging infrastructure, etc.
• Different policies for different parts of the stack: os-packages vs. application packages

Next Steps

Read more about the Allowlists component of a policy.

2.4 - Allowlists

Allowlists provide a mechanism within a policy to explicitly override a policy-rule match. An allowlist is a named set of exclusion rules that match trigger outputs.

Example allowlist:

{
  "id": "allowlist1",
  "name": "My First Allowlist",
  "comment": "A allowlist for my first try",
  "version": "2",
  "items": [
    {
      "gate": "vulnerabilities",
      "trigger_id": "CVE-2018-0737+*",
      "id": "rule1",
      "expires_on": "2019-12-30T12:00:00Z"
    }
  ]
}

The components:

• Gate: The gate to allowlist matches from (ensures trigger_ids are not matched in the wrong context)
• Trigger Id: The specific trigger result to match and allowlist. This id is gate/trigger specific as each trigger may have its own trigger_id format. We’ll use the most common for this example: the CVE trigger ids produced by the vulnerability->package gate-trigger. The trigger_id specified may include wildcards for partial matches.
• id: an identifier for the rule, must only be unique within the allowlist object itself
• Expires On: (optional) specifies when a particular allowlist item expires. This is an RFC3339 date-time string. If the rule matches, but is expired, the policy engine will NOT allowlist according to that match.

The allowlist is processed if it is specified in the mapping rule that was matched during policy evaluation and is applied to the results of the policy evaluation defined in that same mapping rule. If a allowlist item matches a specific policy trigger output, then the action for that output is set to go and the policy evaluation result notes that the trigger output was matched for a allowlist item by associating it with the allowlist id and item id of the match.

An example of a allowlisted match from a snippet of a policy evaluation result (See Policies for more information on the format of the policy evaluation result). This a single row entry from the result:

[
  {
    "trigger_id": "CVE-2018-0737+openssl",
    "gate": "package",
    "trigger": "vulnerabilities",
    "message": "MEDIUM Vulnerability found in os package type (dpkg) - openssl (fixed in: 1.0.1t-1+deb8u9) - (CVE-2018-0737 - https://security-tracker.debian.org/tracker/CVE-2018-0737)",
    "action": "go",
    "policy_id": "myfirstpolicy",
    "recommendation": "Upgrade the package",
    "rule_id": "rule1",
    "allowlisted": true,
    "allowlist_match": {
      "matched_rule_id": "rule1",
      "allowlist_id": "allowlist1",
      "allowlist_name": "My First Allowlist"
    },
    "inherited_from_base": false
  },
]

Note: Allowlist are evaluated only as far as necessary. Once a policy rule match has been allowlisted by one allowlist item, it will not be checked again for allowlist matches. But, allowlist items may be evaluated out-of-order for performance optimization, so if multiple allowlist items match the same finding any one of them may be the item that is actually matched against a given trigger_id.

Recap

Read more about the Anchore Policy Checks for a complete list of gates and triggers.

2.5 - Policy 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 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:

1. 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=
2. 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 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 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 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:

1. FROM line is preserved, so the parent tag of the image is easily available
2. Instruction checks are all against instructions created during the build for that exact image, not any parent images
   1. 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)
3. COPY/ADD instructions will maintain the actual values used
4. 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:

1. FROM line is not accurate, and will nearly always default to ‘FROM scratch’
2. Instructions are processed from all layers in the image
3. COPY and ADD instructions are transformed into SHAs rather than the actual file path/name used at build-time
4. 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”

Supported Directives/Instructions:

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

1. 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"
    }
  ]
}

2. 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: packages_added

This trigger warns if a package was added to the SBOM.

Parameters

Optional parameter: “package_type”

Example

Raise a warning if packages were added.

  {
   "action": "WARN",
   "gate": "tag_drift",
   "trigger": "packages_added",
   "params": [],
   "id": "1ba3461f-b9db-4a6c-ac88-329d38e08df5"
  }

Trigger: packages_removed

This trigger warns if a package was deleted from the SBOM.

Parameters

Optional parameter: “package_type”

Example

Raise a warning if packages were deleted.

  {
   "action": "WARN",
   "gate": "tag_drift",
   "trigger": "packages_removed",
   "params": [],
   "id": "de05d77b-1f93-4df4-a65d-57d9042b1f3a"
  }

Trigger: packages_modified

This trigger warns if a package was changed in the SBOM.

Parameters

Optional parameter: “package_type”

Example

Raise a warning if packages were changed.

  {
   "action": "WARN",
   "gate": "tag_drift",
   "trigger": "packages_modified",
   "params": [],
   "id": "1168b0ac-df6c-4715-8077-2cb3e016cf63"
  }

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

1. Denylist root user

{
  "gate": "dockerfile",
  "trigger": "effective_user", 
  "action": "stop", 
  "parameters": [ 
    {
      "name": "users",
      "value": "root"
    }, 
    {
      "name": "type",
      "value": "denylist"
    }
  ]
}

2. 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"
    }
  ]
}

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

1. 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"
    }
  ]
}

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

1. Raise a warning if no dockerfile was provided at analysis time

{
  "gate": "dockerfile",
  "trigger": "no_dockerfile_provided", 
  "action": "warn", 
  "parameters": [] 
}

2.6 - SBOM Drift

Software bill of materials (SBOM) drift is understanding how SBOMs change over time, and is a key part of managing your SBOMs. The nature of changes themselves may give early warning into unexpected behavior or intrusion into the build system that a review without context from previous builds would not easily be able to identify.

To do this, you set triggers for policy violations on changes in the SBOM between images with the same tag so that it can detect drift over time between builds of your images.

Gate: tag_drift

The triggers are:

• packages_added
• packages_removed
• packages_modified

The “tag_drift” gate compares the SBOMs from the image being evaluated as input, and the SBOM of the image that precedes the input image with the requested tag provided for policy evaluation. The triggers in this gate evaluate the result to determine if packages were added, removed, or modified.

Trigger: packages_added

This trigger warns if a package was added to the SBOM.

Parameters

Optional parameter: “package_type”

Example

Raise a warning if packages were added.

  {
   "action": "WARN",
   "gate": "tag_drift",
   "trigger": "packages_added",
   "params": [],
   "id": "1ba3461f-b9db-4a6c-ac88-329d38e08df5"
  }

Trigger: packages_removed

This trigger warns if a package was deleted from the SBOM.

Parameters

Optional parameter: “package_type”

Example

Raise a warning if packages were deleted.

  {
   "action": "WARN",
   "gate": "tag_drift",
   "trigger": "packages_removed",
   "params": [],
   "id": "de05d77b-1f93-4df4-a65d-57d9042b1f3a"
  }

Trigger: packages_modified

This trigger warns if a package was changed in the SBOM.

Parameters

Optional parameter: “package_type”

Example

Raise a warning if packages were changed.

  {
   "action": "WARN",
   "gate": "tag_drift",
   "trigger": "packages_modified",
   "params": [],
   "id": "1168b0ac-df6c-4715-8077-2cb3e016cf63"
  }

Related Topics

• SBOM Generation and Management
• Observe Applications in Enterprise
• Anchore Enterprise Application Groups
• SBOM Generation and Management from Source Repository - AnchoreCTL
• SBOM Generation and Management from Source Repository - Anchore API