At Anchore we are consistently working with our users and customers to help them gain better insight into the contents of their container images, and more importantly, helping them create rules to enforce security, compliance, and best practices. The enforcement element is achieved through Anchore policy evaluations, and more specifically, the rules are defined within the policies component of a policy bundle.

Anchore policy bundles are the unit of policy definition and evaluation. Anchore users may have multiple policy bundles, but for policy evaluation, the user must specify a bundle to be evaluated or default to the bundle currently marked as active. One of the components of a policy bundle is whitelists. A whitelist is a set of exclusion rules for trigger matches found during policy evaluation. A whitelist defines a specific gate and trigger_id that should have its action recommendation statically set to go. When a policy rule result is whitelisted, it is still present in the output of the policy evaluation, but its action is set to go and it is indicated that there was a whitelist match. The overarching idea is to give developers, operations, and security team members an effective mechanism for ignoring vulnerability matches that are known to be false positives or ignoring vulnerabilities on specific packages (if they have been patched), or any other agreed-upon reason for creating a whitelist rule.

Whitelists in Anchore Enterprise

Within the Anchore Enterprise UI, navigating to the Whitelists tab will show the lists of whitelists that are currently present in the current policy bundle.

Anchore Enterprise whitelists tab for policy bundles.

Selecting the edit button on the far right under the action column will bring up the whitelist editor where users have the ability to create new whitelist entries or modify existing ones.

Anchore whitelist editor for list items.

The example whitelist above is represented as JSON below:

{
  "comment": "Default global whitelist",
  "id": "37fd763e-1765-11e8-add4-3b16c029ac5c",
  "items": ,
  "name": "Global Whitelist",
  "version": "1_0"
}

Components of a Whitelist in Anchore

 

  • Gate: The gate to whitelist matches from (ensures trigger_ids are not matched in the wrong context).
  • Trigger Id: The specific trigger result to match and whitelist. This id is gate/trigger specific as each trigger may have its own trigger_id format. Most commonly, the CVE trigger ids produced by the vulnerability package gate-trigger. The trigger_id may include wildcards for partial matches as shown with the second item.
  • Id: An identifier for the whitelist rule. It only needs to be unique within the whitelist object itself.

It is important to note that if a whitelist item matches a policy trigger output, the action for that particular output is set to go and the policy evaluation result will inform the user that the trigger output was matched for a whitelist item.

Uploading a Whitelist in Anchore Enterprise

Through the UI, Anchore users have the option to upload a whitelist by selecting the Upload Whitelist button which brings up the following:

Uploading a whitelist to Anchore platform.

Viewing Whitelisted Entries

Anchore users can view the whitelisted entries in the Policy Evaluation table as shown below:

View whitelist entries in the Anchore policy evaluation tab.

Additionally, users can optionally Add / Remove a particular whitelist item as shown below:

Add or remove whitelist items from Anchore.

Conclusion

When working with the security risks associated with both the operating system and non-operating system packages, ignoring issues is sometimes a necessary action. At Anchore, the goal is to provide teams a solid means of managing vulnerabilities and packages that may need to be suppressed. Due to the fact that working with whitelists and policies carries a certain level of risk, Anchore Enterprise provides role-based access control to make policy editing only available to users who have been assigned the appropriate level of permissions. In the example below, the current user only has 'read-only' access and cannot make any changes to the whitelist.

Anchore policy bundles on platform.

When working with whitelisted items, it is important to remember that this does not mean there are no longer security issues, only that these particular items now have a go output associated with them. Remember to use carefully and in moderation. Lastly, as with any CVE remediation and policy rule creation, consult across your development, security, and operations teams to collectively come up with acceptable actions that best suit your organization's security and compliance requirements.

Further information on Anchore Enterprise can be found on our website.