Anchore Enterprise Release Notes

1 -

Future Release of Anchore Enterprise v5.0.0

For detail steps on migrating to the v5.0.0 release, please see 5.0 Migration Guide.

Upgrade Requirements

• Postgres database major version must be 13 or greater in order to upgrade to Enterprise v5.0.0
  • Our current minimal allowed Postgres version is 9.6 which is no longer supported by Postgres
  • Postgres 13 is significantly more performant than prior versions and provides additional schema update features that enable a better Enterprise upgrade experience.
• Your current Enterprise release must be v4.0.0 or greater in order to upgrade to Enterprise v5.0.0
  • If you are currently running a release older than v4.0.0, please upgrade to an Enterprise release in the v4.x series
• A new Enterprise Helm Chart will be available shortly for review. The Enterprise Helm Chart is required for use with Enterprise v5.0.0.

Deprecations

• The anchore-cli has been deprecated and will be removed from the docker.io/anchore/enterprise image
  • AnchoreCTL is available within docker.io/anchore/enterprise image today
  • AnchoreCTL is the only supported command line tool for interacting with Anchore Enterprise
• KAI (Kubernetes Automated Inventory) will no longer be compatible with Enterprise v5.0.0. A new version of this agent, called anchore-k8s-inventory, is available now and compatible with Enterprise v4.7.0. You may start to migrate to this new agent today.
• Support for REM (Remote Execution Manager) has been deprecated. It will no longer be supported in Enterprise v5.0.0.

Additional Changes

• The Enterprise v5.0.0 release will have multiple updates to the public API. Many of these changes will not be backwards compatible. This will only be impactful if you are currently accessing Anchore Enterprise directly via our public APIs. For more information, please see Migrating from API V1 to V2.
• Most customers access Anchore Enterprise via one or more of our custom integrations or clients such as Enterprise UI, AnchoreCTL or anchore-k8s-inventory. In this case, you will need to upgrade your integrations and/or client applications to the Enterprise v5.0.0 compatible versions. A complete list of compatible versions to the upcoming Enterprise v5.0.0 release is found below.

AnchoreCTL Updates

• V2 compatible versions of AnchoreCTL will use version numbers associated with Enterprise releases. For example, once Enterprise v5.0.0 is released, there will be an AnchoreCTL v5.0.0 released. This new version will support only the V2 API and have the same Syft version as Enterprise v5.0.0.
• AnchoreCTL v4.9.0 is available now!
  • Fully compatible with the V2 API available within Enterprise v4.9.x.
  • Once you have upgraded to Enterprise v4.9.x, you should start using AnchoreCTL v4.9.0.
  • Install with:

    curl -sSfL  https://anchorectl-releases.anchore.io/anchorectl/install.sh  | sh -s -- -b /usr/local/bin v4.9.0
    

Compatible Integrations

• Integrations have been released that support Enterprise V2 API.
• Once you upgrade your deployments to Enterprise v4.9.x, you should upgrade all integrations to the compatible versions which support V2 API. Doing this now will minimize the impact of the 5.0 upgrade on clients.

2 - Anchore Enterprise Release Notes - Version 5.0.0

Anchore Enterprise v5.0.0

Enterprise Service Updates

5.0 Migration Guide

Requirements

• Enterprise v5.0.0 requires Postgres 13 or greater.
• Enterprise v5.0.0 requires that the previous version was Enterprise v4.0.0 or greater. Strongly recommend that you upgrade to Enterprise v4.9.0 prior to attempting this upgrade.
• Enterprise v5.0.0 requires the use of the Enterprise Helm Chart v2.0.0.
• Enterprise v5.0.0 requires that you upgrade your integration and client. Please see below the table containing compatible versions.

Improvements

• V2 API
  • The Anchore Enterprise API has been updated. For complete details, please review Migrating from API V1 to V2.
  • The Anchore Enterprise API is found in the API Service. The RBAC Manager API, Notifications API, and Reports API are now served through that same endpoint. Those services are now internal-only services for processing requests in the 5.0 release.
  • fix_observed_at is now returned as part of the GET /v2/images/{image_digest}/vuln/{vuln_type} endpoint response where a fix is available.
• Reports
  • Scheduled Query Executions now contain a status field. Values include: pending, error, running, and complete.
  • The pagination of the scheduledQueries query has been improved. An additional query scheduledQueryExecutions has been added to allow pagination of the executions of a specific scheduled query.
  • Provided a Fix Observed Date for all report queries that contain vulnerabilities information. This Fix Observed Date is the date which Anchore observed that a fix was available.
  • Improved the Filter Descriptions within the runtime reports.
• False Positive Reduction
  • Provide configuration settings so users can select which package types use CPE-base matching against NVD. For additional details, please review False Positive Management
• Policy
  • Improvements in presentation and validation during policy editing have been made. Please see Policy for an overview on using policies.
  • New distro policy gate has been added with a deny trigger. Required parameters include the Name of the Distribution, Version of Distribution, and the Operation to perform the evaluation (ie. <, >, !=).
• RBAC Roles
  • Provided a new user role called image-developer. Used alone, the role limits the user to viewing images, vulnerabilities, polices and policy evaluations.
• Events
  • The ANCHORE_EVENT_RETENTION_AGE_DAYS has now been set to 180 days by default.
• Runtime Inventory
  • Now supports a new configuration option inventory_ingest_overwrite which, when set to true, stores only the most recent inventory per cluster/namespace. Note: the inventory_ttl_days continues to be available for use.

Fixes

• Image Dockerfile Status now reports correctly even after a force re-analysis.
• Images analyzed from runtime inventory now have the correct Dockerfile Status reported.
• Policy
  • Improved Policy validation; The policy editor no longer allows saving policies with unknown elements.
  • Policy Name is now a required field during the creating of new policies.
  • Tag Drift Gate no longer fails with images analyzed with 4.9.x.
• The createScheduledQuery mutation now returns correct returns the createdAt, updatedAt, and account fields.
• A verbose warning log message in the Policy Engine Service, regarding sqlalchemy, has been attended to.
• Addressed an exception in the Report Service when loading an image with an empty dockerfile_mode.
• The report vulnerabilitiesByKubernetesContainer executes correctly even when node information is not present.
• The V2 API now specifies the version field in the ContentJAVAPackageResponse. This is the response for GET v2/images/{image_digest}/content/java.
• Fixed a scale issue where an image, which has been queued for analysis, can be garbage collected prior to being processed.

Deprecations

• The anchore-cli has been deprecated and removed from the docker.io/anchore/enterprise image
  • AnchoreCTL is available within docker.io/anchore/enterprise image today
  • AnchoreCTL is the only supported command line tool for interacting with Anchore Enterprise.
  • For more details, please see AnchoreCTL
• KAI (Kubernetes Automated Inventory) no longer be compatible with Enterprise v5.0.0. A new version of this agent, called anchore-k8s-inventory, is available now and compatible with Enterprise v4.7.0. You may start to migrate to this new agent today.
• Support for REM (Remote Execution Manager) has been deprecated. It is no longer be supported in Enterprise v5.0.0.
• Analyzer Service no longer supports multiple analysis threads. The concurrentTasksPerWorker value is no longer valid within the Enterprise Helm Chart. Analysis throughput should be increased by adding more analyzer pods instead.

UI Updates

Improvements

• The Anchore Enterprise Client now uses the Anchore Enterprise V2 API. This transition should be transparent to users. However, if you encounter any issues, please contact support.

• The Reports feature has been rebuilt to provide a more intuitive and streamlined experience for creating, scheduling, and managing reports. The new report manager is now the default view when you click the Reports icon in the main navigation bar. If any reports are already present, the Saved Reports tab will be displayed. If no reports are yet available, you will initially see the New Report tab. Once you have created at least one report, the Saved Reports tab will become available as the default.

  This component offers the following enhancements:

  • Report composition is simplified, combining the capabilities of the previous Quick Reports and Report Manager features.
  • Scheduling has also been simplified. Reports can either be generated on demand or scheduled to run at a specific time.
  • Templates can now be created at any time, either from an ad-hoc report or from a scheduled report, and are stored in their own dedicated tab. Custom (user) templates and system templates are separated into their own views.
  • Report data, whether scheduled or ad-hoc, can be downloaded in CSV or JSON format at any time.
  • Report schedules can be easily reconfigured or removed after their creation.
  • Individual report items can be removed.

  In addition to the above, performance improvements have been made to the report generation process.

  Note: In previous versions of the UI, users could create reports using entities known as queries, which were stored filter sets. These sets could be associated with one or more schedules, each containing multiple result items. In the new reports UI, the concept of queries within the Reports Manager has been replaced by storing individual reports under Saved Reports. Therefore, migrating to version 5.0.0 will have the following effects:

  • Queries that contain schedules will be converted into multiple reports—one for each schedule—with their associated result entries displayed when the report item is expanded.
  • Queries that do not contain schedules will be turned into custom templates.

• The Fix Observed Date is now displayed within the Vulnerabilities tab of the Images view. This date, which is the date Anchore observed a fix being available for a given vulnerability, is also included in the reports where applicable.

• Clicking the View Reports button in either the Images or Vulnerabilities views will take you directly to the Saved Reports tab in the Reports view. Here, you can view all reports containing data for the selected image or vulnerability.

• Minor improvements have been made to the display of summary data in the rule composition dialog of the Policy Editor.

• Service logging has been enhanced to provide information about connections made from the web service to the Anchore Enterprise API services. This information is displayed at the DEBUG level.

• There’s a more comprehensive presentation of error details when errors are logged and displayed in the UI.

• A new image-developer RBAC role has been added, which is applied to the rule-sets for the UI features. This role is intended for users who need to view images, vulnerabilities, policies, and policy evaluations, but do not need to create or edit them.

Fixes

• AppDB database migrations will not execute unless the app is connected to a running instance of Anchore Enterprise services.

• The application tour dialog no longer redirects users to the Dashboard view when displayed.

• Logging in will now present the user with a landing page appropriate for their RBAC role.

• Textual references to Anchore Engine have been replaced with Anchore Enterprise.

• An error will now be displayed if a user attempts to submit a repository that has already been analyzed.

• The issue where the UI sometimes did not update to reflect a logout event (even though the event was executed on the server) has been addressed.

• Notification endpoints that have been disabled by an administrator can no longer be selected in the Action Workbench feature of the Artifact Analysis view.

• Security enhancements have been made to the test connection operation within the Notifications view.

• Package size is now accurately displayed in the Package Detail popup within the Vulnerabilities view of Artifact Analysis.

• Multi-select and clear-all operations now function correctly in both the Events view and the Images view of Artifact Analysis when viewing repositories.

• Dashboard metrics now use inclusive terminology.

• Broken links to documentation in the Malware subtab of the Content view of Artifact Analysis have been addressed.

• Various supporting libraries have been updated to improve security and performance, and to remove deprecation warnings from both browser and server output logs. Redundant libraries have been removed to reduce the application’s startup time and overall size.

Recommended Component Versions

3 - Anchore Enterprise Release Notes - Version 4.9.5

Anchore Enterprise v4.9.5

Anchore Enterprise release v4.9.5 contains targeted fixes.
No database upgrade is needed.

Enterprise Service Updates

Fixes

• Fixes an issue with the V1 Schema that prevented a JIRA Notification Endpoint from being configured via the UI.
• Addresses an issue with the RedHat vulnerability data provider not automatically updating OVAL files which prevents getting accurate fix version information for appstream packages in RHEL 9.
• Addresses an issue with grype-db matching logic for RHEL 9, where they are no longer reporting a modularity, resulting in false positives. Specifically, RHEL 9’s default stream no longer reports a modularity.

UI Updates

Fixes

• The control used to test notifications in the Notifications view would return a 400 error when used. Now fixed.
• In previous versions, the Report Manager would not display report output on account of an internal page-redirection condition that was an artifact of pre-release 5.0 testing. This issue has now been addressed.
• Previously, the form that allowed you to edit a JIRA notification was not displaying the required fields. This issue has now been addressed (as described by the fix in the Enterprise Service Updates section above).

Recommended Component Versions

4 - Anchore Enterprise Release Notes - Version 4.9.4

Anchore Enterprise v4.9.4

Anchore Enterprise release v4.9.4 contains targeted fixes.
No database upgrade is needed.

Enterprise Service Updates

Fixes

• Fix an issue that prevented new Windows OS containers from being analyzed properly.
• The report vulnerabilitiesByKubernetesContainer executes correctly even when node information is not present.
• Prevent a deadlock when two agents are reporting inventory from the same Cluster/Namespace.
• Fix a grypedb digest mismatch that can occur when Policy Engine syncs with the Feed Service. The issue is seen as a ChecksumMismatchError in the policy-engine’s logs and results in a failure to sync the feeds.
• Fix an exception in the Report Service when loading an image with an empty dockerfile_mode.
• Ability to execute a software downgrade from a patch release to a release within the same Major.Minor version numbers. Also provides better log messages during upgrade.
• Image digests will now match when an image is analyzed within Enterprise (centralised analysis) and the image SBOM is imported via AnchoreCTL (distributed analysis).

Recommended Component Versions

5 - Anchore Enterprise Release Notes - Version 4.9.3

Anchore Enterprise v4.9.3

Anchore Enterprise release v4.9.3 contains targeted fixes.
No database upgrade is needed.

Enterprise Service Updates

Fixes

• Resolved a memory consumption issue in the Policy Engine Service that could occur when handling images with multiple vulnerabilities without fixes. This fix addresses the issue identified during vulnerability scanning, ensuring more efficient resource usage.

Recommended Component Versions

6 - Anchore Enterprise Release Notes - Version 4.9.2

Anchore Enterprise v4.9.2

Anchore Enterprise release v4.9.2 contains targeted fixes.
No database upgrade is needed.

Enterprise Service Updates

Fixes

• Improved the efficiency of Vulnerability Scans. Slower scan time has been linked to the policy-engine service hitting Out of Memory conditions under increased load.
• Fixed the Tag Drift Policy Gate which was failing on images analyzed by Enterprise v4.9.0 or later.
• Restored the Runtime Inventory Image TTL setting which keeps only the most recent set of inventory per namespace.
• Improved the memory profile and reduced memory usage for all the services of Anchore Enterprise.
• V2 API Fixes
  • POST /v2/images - prevent deprecated fields from being accepted in the V2 API
  • GET /v2/images/{image_digest}/check - returns both the overall final_action, which includes the result of the allow/deny lists, as well as the policy_action of the policy rule evaluation.
  • GET /v2/subscriptions - when the subscription_type is repo_update, now returns the subscription_value data in the V2 API format.
  • POST /v2/subscriptions - when the subscription_type is repo_update, prevents non-valid json to be added via the subscription_value data.
  • GET /v2/subscriptions/{subscription_id} - when the subscription_type is repo_update, now returns the subscription_value data in the V2 API format.
  • PUT /v2/subscriptions/{subscription_id} - when the subscription_type is repo_update, prevents non-valid json to be added via the subscription_value data.
  • Evaluation Details field of Policy Evaluations will contain a policy_action field. This field represents the policy result before applying image allow/deny lists

Recommended Component Versions

7 - Anchore Enterprise Release Notes - Version 4.9.1

Anchore Enterprise v4.9.1

Anchore Enterprise release v4.9.1 contains targeted fixes.
No database upgrade is needed.

Enterprise Service Updates

Fixes

• Fixes loading all bundles in the <service_dir>/bundles directory of the API service when new accounts are created`.
• Vulnerability records will be created for out-of-support entries from the RHEL Provider when none of the in-support versions are affected.
• Addressed a failure with grypedb syncing with Policy Engine.
  • Enterprise now properly handles the error case where a vulnerability provider fails to run. An example of a provider failing to run - GitHub Provider will fail if the Github API Key was not properly provided in the config.

Recommended Component Versions

8 - Anchore Enterprise Release Notes - Version 4.9.0

Anchore Enterprise v4.9.0

Anchore Enterprise release v4.9.0 contains targeted fixes and improvements. A Database update is needed.

Enterprise Service Updates

Improvements

• Anchore Enterprise V2 API is now available for use.
  • The V2 API has been provided for early adoption for any customer who has custom integrations or scripts that may directly access the V1 API. This will provide extra time to migrate to the new V2 API endpoints prior to the official Enterprise v5.0.0 release.
  • The V1 APIs were distributed across several files and have now been consolidated into the single V2 API.
    • Anchore API Swagger
  • The following V1 APIs have been deprecated:
    • Enterprise API Swagger
    • Engine API Swagger
    • Notifications Swagger
    • RBAC Manager Swagger
    • Reports Swagger
  • For more details about the Anchore Enterprise V2 API, and to view the V2 swagger, please visit API Usage
• Kubernetes and ECS Runtime Inventory ingest path received performance enhancements.
• Reports
  • Scheduled Queries now provide a executionsLimit filter
  • Improvement in both performance and memory consumption were completed on the following reports:
    • Vulnerabilities by Kubernetes Namespaces
    • Vulnerabilities by Kubernetes Containers
    • Vulnerabilities by ECS Containers
  • Added several new Metrics within the report service. These are now available via Prometheus.
• Configuration
  • Image import maximum size is now configurable. Current default size is 100 MB.
    • Docker Compose users can set the environment variable ANCHORE_MAX_IMPORT_CONTENT_SIZE_MB
    • Helm users can modify max_import_content_size_mb
  • Source repository import maximum size is now configurable. Current default size is 100 MB.
    • Docker Compose users can set the environment variable ANCHORE_MAX_IMPORT_SOURCE_SIZE_MB
    • Helm users can modify max_source_import_size_mb
  • Provided a configuration option to bypass object store content checks. This was provided to aid our customer support team during specific triage. Please contact customer support for additional information.
• Policy Engine can now capture and persist additional metadata for vulnerabilities reported by the vulnerability provider sync. The following observed dates are persisted:
  • The date on which a vulnerability within a provider namespace is first observed by Enterprise via the vulnerability provider sync.
  • The date on which a specific package fix is first observed by Enterprise via the vulnerability provider sync. This “fix observed date” will be used during policy eval of max days since fix to give a more consistent evaluation result across all newly analyzed image and source SBOMs.
• Support capture of vulnerability data for Ubuntu 23.04 (Lunar Lobster) and Ubuntu 23.10 (Mantic Minotaur) once publishing commences from Canonical.
• Provide support for vulnerability data for Mariner.
• If a Vunnel Provider fails, the system will provide a new sync using the previous data for the failing provider and the new data from the other providers. This change also provides improved messaging around failing providers.
• Improved Java matches for Source SBOMS by capturing more metadata during SBOM imports.

Fixes

• Reports
  • Handle an error when the service is loading data for ECS Container Report Table and Kubernetes Container Report Table in cases where a container stops being reported long enough for it to be removed from the Catalog, and is then reported again.
  • The report service no longer triggers an out of memory error when running larger runtime workloads.
• The Archive Image Delete force flag options now works even when the image is in the archiving state.
• ECS Inventory which contains both tasks as part of a service and tasks that are run standalone will be properly accepted.
• Fixed an issue seen with the Ubuntu provider failing to sync when the git repo has untracked files present.
• Addressed an issue where distroless images reported incorrect findings from other catalogers.
• Correctly handled the Ubuntu CVE Tracker change for labeling which indicated end of life. This could lead to unfixed CVEs to be missing from the data.
• Modifying the value of the Catalog’s resource_metrics cycle timer is now honored.
• API call POST /v1/enterprise/stateless/sbom/vuln/{vtype} now works as expected.
• Proper handling for vulnerability transitions from affected to not-affected within the RHEL provider.

UI Updates

Fixes

• Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

Recommended Component Versions

9 - Anchore Enterprise Release Notes - Version 4.8.1

Anchore Enterprise v4.8.1

Anchore Enterprise release v4.8.1 contains a new configuration option.
No database upgrade is needed.

Enterprise Service Updates

Improvements

• Configuration

  • New configuration options are available for customers who do not wish to generate the report data need to support the following reports:

    • Vulnerabilities by Kubernetes Namespace
    • Vulnerabilities by Kubernetes Containers
    • Vulnerabilities by ECS Containers

  • Docker Compose users can set one or more of the environment variables in the reports_worker to false:

    • ANCHORE_ENTERPRISE_REPORTS_GENERATE_VULN_K8S_NAMESPACE
    • ANCHORE_ENTERPRISE_REPORTS_GENERATE_VULN_K8S_CONTAINER
    • ANCHORE_ENTERPRISE_REPORTS_GENERATE_VULN_ECS_CONTAINER

  • Helm users can set one or more of the following in values.yaml to false:

    • anchoreEnterpriseReports.vulnerabilitiesByK8sNamespace
    • anchoreEnterpriseReports.vulnerabilitiesByK8sContainer
    • anchoreEnterpriseReports.vulnerabilitiesByEcsContainer

Recommended Component Versions

10 - Anchore Enterprise Release Notes - Version 4.8.0

Anchore Enterprise v4.8.0

Anchore Enterprise release v4.8.0 contains targeted fixes and improvements. A Database update is needed.

Enterprise Service Updates

Improvements

• Reporting

  • Vulnerabilities by Kubernetes Containers is a new report template which will allow you to view and filter on vulnerabilities found within a Kubernetes Container. The report will populate only if you have deployed the new anchore-k8s-inventory.
  • Vulnerabilities by ECS Containers is a new report template which will allow you to view and filter on vulnerabilities found within an ECS Container. The report will populate only if you have deployed the new anchore-ecs-inventory.
  • Vulnerabilities by Kubernetes Namespace report now displays the Anchore Account Name.

• Configuration

  • A new configuration option is available that can show a significant reduction in resource usage. It is available for customers that do not use the /v1/query/images/by_vulnerability API.
    • Setting this configuration option to false will:
      • Disable the /v1/query/images/by_vulnerability API and return a 501 code if called.
      • Disable the SBOM vulnerability rescans which occur after each feed sync. It is these rescans that populate the data returned by the API.
    • Customers who are using /v1/query/images/by_vulnerability API, are encouraged to switch to calling the ImagesByVulnerability query in the GraphQL API. This query provides equivalent functionality and will allow you to benefit from this new configuration option.
    • Docker Compose users can set environment variable, ANCHORE_POLICY_ENGINE_ENABLE_IMAGES_BY_VULN_QUERY, in the policy engine to false.
    • Helm users can set services.policy_engine.enable_images_by_vulnerability_api key in config.yaml

Fixes

• Improved operating system matching prior to determining if a CVE should be reported against an image.
• CVSS Scores from NVD are now preferred over other source. This provides a more consistent end user experience.
• Addressed a failure to properly generate the Policy Compliance by Runtime Inventory report while using the new anchore-k8s-inventory agent.
  A symptom was that the Compliance and Vulnerabiliy Count fields within the Kubernetes tab remained in Pending state.
• Switch archive delimiter in malware scan output from ‘!’ to ‘:’ to ensure shell copy-paste ease of use.
• Improved a few misleading internal service log messages.
• Fixed an issue that resulted in a scheduled query, with a qualifying filter, failing to execute. Examples of filters which will result in this failure:

UI Updates

• The Watch Repository toggles displayed in the registry and repository view tables under Images can now be suppressed when the enable_add_repositories property in config-ui.yaml is set to False for admin or standard accounts. This and other parameters contained in the UI configuration file are described here.
• The Vulnerabilities by ECS Container report template has been added that allows you to search for a specific vulnerability across ECS containers in order to view a list of clusters services, tasks and containers that are impacted by the vulnerability.
• The Vulnerabilities by Kubernetes Container report template has been added that allows you to search for a specific vulnerability across Kubernetes containers in order to view a list of clusters services, tasks and containers that are impacted by the vulnerability.

Fixes

• References to Anchore Engine have been removed and replaced app-wide with Anchore Enterprise Services
• A fix has applied for an issue where a read-only user was not able to manage registry credentials in another context even when they had a full-control role associated with that account
• An Account Name filter has been added to the Kubernetes Runtime Vulnerabilities by Namespace report template, and improved descriptions have been provided for the Label and Annotations filters
• Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

Recommended Component Versions

11 - Anchore Enterprise Release Notes - Version 4.7.1

Anchore Enterprise v4.7.1

Anchore Enterprise release v4.7.1 is a patch release that provides two targeted fixes.

Enterprise Service Fixes

• Updated to latest ClamAV LTS version, resolving FIPS enabled host incompatibilities.
• Database upgrades now succeed from Anchore Enterprise Releases older than v4.2.0.

Recommended Component Versions

12 - Anchore Enterprise Release Notes - Version 4.7.0

Anchore Enterprise v4.7.0

Anchore Enterprise release v4.7.0 contains targeted fixes and improvements. A Database update is needed.

Please Note: If you are upgrading from an Anchore Enterprise version prior to v4.2.0, there is a known issue that will require you to upgrade to v4.2.0 or v4.3.0 first. Once completed, you will have no issues upgrading to v4.7.0. Please contact Anchore Support if you need further assistance.

Enterprise Service Updates

Improvements

• Runtime Inventory
  • Anchore has introduced two new Runtime Inventory Agents for use with the v4.7.0 release of Anchore Enterprise. anchore-k8s-inventory and anchore-ecs-inventory will provide better access to your runtime environments. See Runtime Inventory for more details.
  • Runtime Inventory TTL was also improved to be more effective in helping you to manage expired inventory items.
• Reporting
  • Vulnerabilities by Kubernetes Namespace is a new template which will allow you to view and filter on vulnerabilities found within a Kubernetes Namespace. The report will populate only if you have deployed the new anchore-k8s-inventory.
• Feeds
  • Anchore Enterprise is now fully integrated with our Open Source applications of anchore/vunnel and anchore/grype-db.
  • Chainguard Linux Vulnerability Provider has been added to the list of feeds.
  • Support for the OVAL v2 RHEL Security Endpoint.
• Account email field is now editable via API.
• Vulnerability Package trigger, adds a new parameter that controls the behavior of vulnerabilities found in the base image. The new parameter can be set to trigger on vulnerabilities in the base image, trigger on vulnerabilities that are not in the base image, or to trigger only on vulnerabilities present in the base image.
• Container Image SBOM generation and import from AnchoreCTL without the need for Syft
  • Combined with AnchoreCTL 1.6.0, you can now analyze images fully using AnchoreCTL and import the results to Enterprise, including secret scans, filesystem metadata analysis, content searches and file retrieval with equivalent functionality to what Enterprise-backend analysis scans produce. The only exception is that malware scanning is not supported by AnchoreCTL-based analysis.

Fixes

• Enabling the Repo Watcher when there is already an image from the repo with an active subscription, no longer returns an error.
• Adding a source sbom which does has java packages without a metadata virtual path is handled correctly.
• Addressed an issue where Anchore Enterprise displayed multiple Binary Package Locations.
• Correctly handle an import of an image sbom which contains packages with no metadata.
• Improved handling of the Microsoft Windows product id during analysis of Windows containers.

UI Updates

Fixes

• Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

Recommended Component Versions

13 - Anchore Enterprise Release Notes - Version 4.6.0

Anchore Enterprise 4.6.0

Anchore Enterprise release v4.6.0 contains targeted fixes and improvements. A Database update is needed.

Please View: Upcoming Enterprise v5.0.0 Announcements

Please Note: If you are upgrading from an Anchore Enterprise version prior to v4.2.0, there is a known issue that will require you to upgrade to v4.2.0 or v4.3.0 first. Once completed, you will have no issues upgrading to v4.6.0. Please contact Anchore Support if you need further assistance.

Enterprise Service Updates

Improvements

• Runtime Inventory
  • New API Delete functionality for any runtime inventory context that is no longer being reported on by KAI.
    • /enterprise/inventories DELETE
  • The Inventory Watcher improved logging output at info level so that it is more concise.
  • The Inventory Watcher now contains additional global metrics
    • anchore_monitor_inventory_contexts_monitored_total - Total number of contexts monitored via subscriptions
    • anchore_monitor_inventory_images_total ( found ) - Total number of images from runtime inventory that are being watched
    • anchore_monitor_inventory_images_total ( success ) - Total number of images successfully added to the catalog
    • anchore_monitor_inventory_images_total ( fail ) - Total number of images that failed to be added to the catalog
• Policy Triggers
  • Vulnerability Package Trigger has a new parameter inherited from base. It provides more control on which vulnerabilities will be considered by the policy.
    • true shows vulnerabilities only inherited from the base image
    • false hides vulnerabilities inherited from the base image
  • We have deprecated various triggers using blacklist and whitelist terminology in favor of denylist and allowlist. The deprecated triggers will continue to work until they are removed in Enterprise v5.0.0. Note that existing allowlist entries for the deprecated triggers will continue to work until the policy is updated to use the new triggers at which time the trigger IDs will no longer match.
• Analysis Jobs
  • Improves the ability of the system to re-queue image analysis and image import jobs from shut-down analyzers to minimize the impact of scale-down operations on the set of analyzers. In addition to the existing analyzing state timeout behavior, the system can now detect an image was analyzed by a now-down analyzer as soon as the analyzer is reported as down, making the re-queue time a matter of minutes instead of hours.
  • Additional metrics were also added to help give more visibility into analysis
    • anchore_analyzer_status ( waiting ) - Analyzer is idle and is waiting to receive work from the queue
    • anchore_analyzer_status ( error ) - Analyzer is not able to process work
    • anchore_analyzer_status ( processing ) - Analyzer is currently processing work
    • anchore_analyzer_dequeue_latency - Indicator of the responsiveness of the queue service for this analyzer

Fixes

• Fixed an SSL Error for customers who are using custom certificates.
• Resolved problems in the Inventory Watcher when processing large inventories.
• Policy validation has been improved during initial creation of the policy bundle. This will provide a better feedback mechanism so that invalid policies can be fixed earlier.
• Addressed an issue where the python binary cataloger incorrectly returned multiple instances of a python package.

UI Updates

Fixes

• Deprecated policy triggers
  • A new warning indicator has been added to the policy rule list to flag triggers that are invalid or that have been deprecated. If you edit a policy rule containing a deprecated trigger, we also indicate that the currently selected trigger has been deprecated and replaced by another trigger, so that it is easy to know how to fix policies containing such triggers.
• Policy editor tables
  • We have upgraded the table widgets within the policy editor to make the columns resizable.
• Miscellaneous
  • Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

14 - Anchore Enterprise Release Notes - Version 4.5.0

Anchore Enterprise 4.5.0

Anchore Enterprise release v4.5.0 contains targeted fixes and improvements. There is no Database update needed.

Enterprise Service Updates

Improvements

• Introducing a new RBAC Role called report-admin. This is meant to be a companion role for users that need to work with scheduled queries but do not have other write permissions.
• Anchore Enterprise is now using Red Hat Universal Base Image 9 Minimal as its base image. This significantly reduces the number of packages provided by the operating system, thus reducing the vulnerability surface overall.

Fixes

• Fixed an issue that prevented image metadata from being correctly displayed for images with unsupported packaging systems (Arch Linux, etc).
• Properly identifies alpine:edge when evaluating the vulnerabilities.vulnerability_data_unavailable trigger.
• Fixed an issue that allowed admin users to perform some operations against non-existent accounts.
• Database upgrades now succeed from Anchore Enterprise Releases older than v4.2.0.
• Users who only have read-only permissions are correctly prevented from creating, updating and deleting scheduled report queries.

Deprecation Reminders

• The anchore-cli has been deprecated and will be removed from the docker.io/anchore/enterprise image during the v5.0.0 Release. AnchoreCTL is the only supported command line tool for interacting with Anchore Enterprise.

UI Updates

Improvements

• Artifact Analysis
  • In addition to our native JSON format, the Artifact Analysis view now allows Software Bill of Material (SBOM) data to be downloaded in both the Software Package Data Exchange (SPDX) format and the OWASP CycloneDX format.
  • The table in the Vulnerabilities tab now contains a Detected At column that indicates the analysis discovery time of the vulnerability. This data is now also present in the downloadable report data for this view.
• Policy Editor
  • The Policy Editor dialog now displays any rules that contain invalid or obsolete triggers in its summary table. These rules are similarly highlighted when the rule is edited for easy removal.
• Reports

  • From within the administrative account, both the Quick Reports and Report Manager controls now allow you to preview and retrieve report data from either the local account or from all accounts system-wide.

  • A new template has been added to our current set of system templates that surfaces policy compliance data against runtime inventory artifacts.

  • Additional fields have been added to our existing system templates:

    • Vulnerability-related templates now include a links field

    • Runtime-related templates now include an account field

    • All templates now include an inventory_type field

    Note: In order to surface these fields, new queries must be created using these updated system templates as their basis—they will not be present in any existing stored queries.'

Fixes

• System: User Management
  • Prior to this fix, updates to the user list would be inaccurate if a user was created by another user with full-control privileges from a switched account context. Now addressed.
• Logging
  • A minor issue has been addressed whereby active users that had their accounts deleted, or resided within an account that was disabled, would not be correctly logged after this event.
• Policy Manager: Rules
  • Gate rules created for Source artifacts will now only display the triggers associated with that artifact type. Prior to this fix, the entire set of triggers (for both Source and Image types) were shown in the dropdown.
• Report Manager: RBAC
  • Access control restrictions for report management operations have now been applied throughout this feature. The creation, management, and deletion of report schedules and their associated items are now gated by the RBAC roles associated with the reports service.
• Application Architecture
  • The Anchore Enterprise UI is now provisioned using Red Hat Universal Base Image 9 Minimal. This image significantly reduces the number of packages provided by the operating system, thus reducing the vulnerability surface overall.
• System: Login
  • Addressed an issue whereby logging in via an external IDP, as opposed to the SSO link on the Enterprise UI login page, would fail under certain circumstances.
• Miscellaneous
  • Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

15 - Anchore Enterprise Release Notes - Version 4.4.1

Anchore Enterprise 4.4.1

Anchore Enterprise release v4.4.1 is a patch release which solely addresses a critical vulnerability in the ClamAV malware scanner (CVE-2023-20032). The malware scanner is not enabled by default within Anchore Enterprise. If you have not enabled the malware scanner you are not exposed to this vulnerability.

Please Note: If you are upgrading from an Anchore Enterprise version prior to v4.2.0, there is a known issue that will require you to upgrade to v4.2.0 or v4.3.0 first. Once completed, you will have no issues upgrading to v4.4.1. Please contact Anchore Support if you need further assistance.

16 - Anchore Enterprise Release Notes - Version 4.4.0

Anchore Enterprise 4.4.0

Anchore Enterprise release v4.4.0 contains targeted fixes and improvements. A Database update will be required.

Please Note: If you are upgrading from an Anchore Enterprise version prior to v4.2.0, there is a known issue that will require you to upgrade to v4.2.0 or v4.3.0 first. Once completed, you will have no issues upgrading to v4.4.0. Please contact Anchore Support if you need further assistance.

Enterprise Service Updates

Improvements

• The AnchoreCTL binary for linux x86 is now packaged into the docker.io/anchore/enterprise image for use via direct ’exec’ invocation or to copy from the image into your environment without having to access external networks. The packaged binary will be the current release of AnchoreCTL at the time of release of Enterprise.

• Configuration Options

  • enable_package_db_load is a new configuration option that will allow users to disable the use of the package.verify policy trigger. Disabling this trigger, will prevent further additions in the image_package_db_entries table, which will reduce load on the database. In addition, users may now safely delete the existing entries in the table and reclaim database capacity usage. See Database for more details.
  • A new option for users to specify the endpoint used for the Ubuntu Feed Driver. See Feeds for more information.

• Enterprise API now supports the ability to download SBOMs in SPDX Format and CycloneDX Format.

  • /images/{imageDigest}/sboms/spdx-json
  • /images/{imageDigest}/sboms/cyclonedx-json
  • /sources/{source_id}/sbom/spdx-json
  • /sources/{source_id}/sbom/cyclonedx-json

• A new Image Ancestry Policy Gate has been added. Allows the user to verify that a specified image contains an approved base image. See Policy Checks for complete details.

• Binary detection is now consistent between uploaded SBOMs generated by AnchoreCTL and SBOMs generated by the backend Enterprise Service.

• Tech Preview: Enterprise Reporting provides a global endpoint which will allow administrators to generate queries that will include data from all accounts. See Reports from more details.

• Vulnerability data is now available from Feed Group - Ubuntu 22.10 (Kinetic Kudu).

Fixes

• Vulnerability feed group information is now populated at time of switch-over. This should address issues with displaying the vulnerability group record counts in systems with a large number of active images.
• Addressed an error path exception in the Application Version Vulnerability API.
• Addressed a parsing issue within the execution of Policy Gate retrieved files with Trigger content regex.
• Schedule Report generation will gracefully handle an error found in a report and continue with the generation of other reports.
• Properly account for rolling distros (currently Wolfi) when evaluating the vulnerabilities.vulnerability_data_unavailable trigger.
• Addressed an analysis failure during SBOM generation for certain images with cycles of soft links.

Deprecation Reminders

• The anchore-cli python client has been deprecated as of Enterprise Release v4.2.0. It will be removed from the docker.io/anchore/enterprise image during the v4.5.0 Release. AnchoreCTL is the only supported command line tool for interacting with Anchore Enterprise.

UI Updates

Improvements

• Reporting
  • Prometheus logging has now been added to the application with the following data now being captured and reported:
  • General node process metrics
  • Number of active sessions
  • Count of HTTP requests, split by endpoint and status code
  • HTTP request duration
  • Latency of each service, calculated during every health check cycle
• Configuration
  • Sessions will now preferentially use OAuth tokens to provide and maintain ongoing authentication state
  • In the event that the token dispensation is not possible when the user logs in, the system will fall back to using basic authentication
  • Added confirmation toast on dashboard widget creation
  • Updated various supporting libraries to improve security and performance
  • Redundant libraries have been removed to reduce the app startup time and overall size

Fixes

• Reporting
  • Schedules that contain queries with data enumerations can now be saved properly
• Configuration
  • Increased the opacity on both the filter input and the sort dropdown when either are in a disabled state-that is, when no application data exists
  • This ensures the text is legible while still clearly indicating the inactive state
  • Policy Editor Evaluation correctly updates after changes are applied
  • RBAC rules are now correctly applied to the radio button used to change the active bundle
  • Copy bundle modal would now allow all key events
  • Service errors and access control errors are now properly articulated

17 - Anchore Enterprise Release Notes - Version 4.3.0

Anchore Enterprise 4.3.0

Anchore Enterprise release v4.3.0 contains targeted fixes and improvements. A Database update will be required.

Enterprise Service Updates

Improvements

• Reporting Improvements
  • The runtimeInventoryImagesByVulnerability report query now supports various vulnerability filters such as Vulnerability Id.
  • Various vulnerability-related report queries, such as artifactsByVulnerability, tagsByVulnerability, now support filtering by one or more severities via the Severities option.
  • A new report query called runtimeInventoryUnscannedImages is now available. It provides the list of images in the runtime inventory that have not been analyzed.
  • See https://docs.anchore.com/current/docs/using/api_usage/reports/ for an overview of how to access reports via the API.
• API now supports the ability to query a list of vulnerabilities found for a specific Application Version. See https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchore_api for additional information about Applications.
• Introducing a new RBAC Role called repo-analyzer. It is meant to be a companion to the image-analyzer role and specifically provides the ability to create a repository subscription.
• Now importing the Wolfi Security Feed. Used in vulnerability matching for Wolfi OS Packages.

Fixes

• Fixed a failure during the cleanup of old versions of GrypeDB. This was seen to cause an issue during feed sync.
• When deploying with multiple instances of policy-engine, there will only be a maximum of two GrypeDB instances.
• Addressed an issue which prevented a scheduled query of a Runtime Inventory Images By Vulnerability from running.
• Fixed the unlikely condition where a deleted image is added back into the system, due to a subscription processing error.
• Image analysis properly displays all found versions of the same OS package.
• Increased accuracy of vulnerability matches on Debian source packages when the source package version differs from the binary package version. Requires re-analysis in order to populate necessary metadata for existing scans.
• Identifies improper SSO IDP Configuration during creation or modification of an existing configuration.

Deprecation Reminders

• The anchore-cli python client has been deprecated as of Enterprise Release v4.2.0. It will be removed from the Enterprise image during the v4.4.0 Release. AnchoreCTL is the only supported command line tool for interacting with Anchore Enterprise. It will be included in the Enterprise image during the v4.4.0 Release.

UI Updates

Improvements

• A new Quick Report for Unscanned Runtime Inventory Images is now available. It shows which images running in Kubernetes clusters have not yet been analyzed by Anchore so that users can verify all images are scanned in CI/CD.
• The Runtime Inventory Images by Vulnerability report type now supports various vulnerability filters such as Vulnerability Id. This makes it easier to focus efforts on zero-days (or other critical and well-known vulnerabilities) and find exactly which runtime contexts (and the images within) are impacted by a specific vulnerability.
• Various vulnerability-related reports (Artifacts by Vulnerability, Tags by Vulnerability, etc.) now support filtering by one or more severities via the Vulnerability Severities option.
• An improvement has been made to our cookie management for higher entropy via an autogenerated encryption key unique to each deployment and to allow administrators to change it if they wish.

Fixes

• Fixed a bug causing logins made directly via an IDP, as opposed to the SSO link on the Anchore login page, to fail with a 404 error.
• Improved fault-tolerance in the event of an invalid or malicious websocket request: using a scanner such as Nessus could under certain conditions lead to an application crash.
• Fixed a routing issue causing requests to /artifacts/image/ with a trailing slash to lead to a 404 page not found error.
• Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

18 - Anchore Enterprise Release Notes - Version 4.2.0

Anchore Enterprise 4.2.0

Anchore Enterprise release v4.2.0 contains targeted fixes and improvements. A Database update will be required.

Enterprise Service Updates

Improvements

• SSO feature enhancements includes
  • The ability for an Anchore administrator to create another user in the admin account who will authenticate using SSO/SAML enabling use of 2FA and other SSO security mechanisms.
  • A strict mode which will require SAML users to be configured in Anchore Enterprise prior to user login as an alternative to the existing behavior that creates Anchore users at login time only. This allows administrators to restrict login access for SSO users to only those users specifically allocated by the Anchore admin.
  • See https://docs.anchore.com/current/docs/configuration/sso/ for additional information about SSO.
• Adds detection of non-packaged node.js binaries during image analysis to support sbom and vulnerability scanning.
• The Reporting Service now offers the ability to show and filter on vulnerabilities that the vendor of an image distribution either disagrees with or has decided not to fix. This matches the ‘vendor_only’ filtering behavior of the vulnerability APIs and AnchoreCTL.

Fixes

• Fixed an issue where the analysis queue processing stops. This was seen in environments with multiple Catalog, Policy Engine, and Analyzer Containers running.
• Populates fix information per module for rpm-based feeds such as oracle, rhel, and centos. The rpm modularity is now taken into account when matching rpm packages to vulnerabilities.
• Make RedHat/CentOS AppStream modules fully supported for vulnerability matching with reduced false positives and more accurate fix versions.
• Improved error handling during SSO IDP Configuration changes.
• During the creation of an SSO default account, the default policy bundles are correctly populated.
• Improved error handling in the MSRC feed driver so that invalid records are skipped and processing will continue for other records.

Feature Removal

• Removed the Kubernetes Runtime Inventory Embedded mode, and associated cluster configuration APIs. This feature saw limited usage and the same goal can be accomplished by deploying KAI into the cluster directly in inventory mode. See https://docs.anchore.com/current/docs/configuration/runtime_inventory/ for more information about configuring KAI in agent mode.

Deprecation Reminders

• The anchore-cli python client will be deprecated as of Enterprise Release v4.2.0. AnchoreCTL will be the only supported command line tool for interacting with Anchore Enterprise.

UI Updates

Improvements

• The UI now supports the creation and configuration of administrators who can authenticate directly using Single Sign-On (SSO). In addition, administrators in deployments that have been configured to use exclusionary account assignment by disabling “Just-in-Time” account provisioning for SSO can now associate specific standard users with an individual IDP.
• For environments where analytical volume is extremely high, the Kubernetes page now provides an optimized presentational view that excludes information from the reporting services. This version of the view can be enabled via the file- or environment-based Enterprise Client application configuration parameters.
• The Vulnerabilities tab now provides a client-side filter for Vendor Only CVEs that is enabled by default. When disabled, the full vulnerability dataset is now displayed. Upon disabling the filter, a new Will Not Fix column is will be displayed within the results table.
• A Vulnerability Will Not Fix filter has been added to the following base templates in the Scheduled Reports view:
  • Images With Critical Vulnerabilities
  • Artifacts by Vulnerability
  • Tags by Vulnerability
  • Images Affected by Vulnerability

Fixes

• In previous versions, setting a boolean filter to true in Quick Reports would not get correctly passed to the web service. This is now fixed.
• Users with the policy-editor role should not have access to the Artifact Analysis view. Although the associated navbar icon was correctly disabled, users could still access the page (albeit in read-only mode) directly via the URL. This behavior has now been addressed.
• The Only Show toggles in the Vulnerabilities tab of the Artifact Analysis view provide a number of filters that can reduce the number of items displayed. When applied, the table updates accordingly—however, prior to this fix the graph and vulnerability severity summary counts did not. This issue has now been addressed.
• Prior to this fix, if a user encountered an error when saving a policy, there was no way for them to fix the error and save the policy again because the Save button remained disabled. Users can now attend to the error and save the policy.
• Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

19 - Anchore Enterprise Release Notes - Version 4.1.1

Anchore Enterprise 4.1.1

Anchore Enterprise release v4.1.1 contains targeted fixes and improvements.

Enterprise Service Updates

Improvements

• Introduced a Recommendation field that is available in the Policy Rule. This field will be visible in the image policy check results. It will allow the Policy Rule creator to provide a generic hint on how to fix policy findings.
• Improved the description of the “max days since creation” parameter within the vulnerability->package rule. It now states, “A grace period, in days, for a vulnerability match to be present after which the vulnerability is a policy violation”.

Fixes

• Fixed enterprise database schema upgrade process from 4.0.x to 4.1.0 schema when run on a fips-enabled host.
• Improved error message when providing invalid tag to the External API Inventory calls.
• Improved error messages around registry access failures.
• Improved detection and error handling of an image that contains an empty or unknown distro.
• Image analysis will succeed when the image contains an uncompressed layer.
• Image analysis will succeed when the image contains un-parsable rpmdb file entries.
• On a restart or a manual resync of the feed service, the system will maintain no more than 2 versions of the grype database records.
• Tag status is updated immediately in reporting data. Previously, the tag status updates maybe have been delayed.

Deprecation Reminders

• The Embedded Inventory Mode Feature, has been deprecated. During the future Enterprise Release v4.2.0, it will be removed.
• The anchore-cli python client will be deprecated as of the future Enterprise Release v4.2.0. AnchoreCTL will be the only supported command line tool for interacting with Anchore Enterprise.

UI Updates

Improvements

• A Recommendation field has been added to the policy rule editor to allow policy creators to provide bespoke remediation guidance. This information will be surfaced within the output for any matched rule within the Policy Compliance results table in the Artifact Analysis view.
• The service log output for the application has been overhauled. Administrators with access to the running app instance are now able to view detailed timestamped information—categorized by level—that describes the routes being accessed, connection and configuration details, and information about the major operations taking place within the runtime. Additional logging data will be added in subsequent releases.

Fixes

• The management of database connectivity details from the app has been updated to handle special characters in configuration strings.
• A Forbidden error is displayed when a non-administrative user tries to directly access the /system/notifications tab via URL. It also blocks a fetch for the LDAP configuration details for non-admins.
• Various supporting libraries have been updated in order to improve security and performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

20 - Anchore Enterprise Release Notes - Version 4.1.0

Anchore Enterprise 4.1.0

Anchore Enterprise release v4.1.0 contains targeted fixes and improvements. A Database update will be required.

4.1.0 Upgrade Notes

The 4.1 upgrade requires a new vulnerability database to be built by the feed service using a new schema. In the time between the new deployment startup and the completion of the first post-upgrade feed service data sync, the policy engine API will return errors for vulnerability scans. Once it receives the newly built vulnerability database from the upgraded feed service it will resume normal operation. Depending on the deployment, the data update and new db build may take several hours. The system will resolve this condition on its own but your maintenance window should take this into account.

Notes for new deployments

Due to improved error handling in the vulnerability scanner (see details below) new deployments will not provide vulnerability reports via the API until the first full vulnerability sync has occurred but images may be analyzed during this time. Once the first sync is completed (you can see using anchorectl feed list), the vulnerability scans will return successfully.

Enterprise Service Updates

Improvements

• Source to Image SBOM Drift
  • Introduces a new artifact relationship API which provides the ability to indicate that a container image was built from one or more specific source repository revisions. Allowing Anchore to show when the source repository’s SBOM packages are correctly found in the image SBOM.
  • Introduces a new policy gate and trigger which will raise drift findings in the policy compliance evaluations.
• Vulnerability False Positives Reduction
  • Introduces an Anchore vulnerability feed shown as ‘anchore:exclusions’. This is a curated feed of vulnerability matches which will be automatically excluded from results in order to reduce false positives.
  • The feed utilizes Version 4 of the Grype database schema which provides support for vulnerability match exclusion data.
• Application Name and Version Name improvements
  • Added uniqueness and non nullable constraints to the following fields:
    • Application.name must be unique per account
    • ApplicationVersion.version_name must be unique per application
  • Attempting to create or update these fields to a non-unique value will result in a 409 error.
  • During upgrade, if existing records are found to have the same value, they will be automatically renamed by appending ‘_N’ where ‘N’ is incremented for each conflict. For example, if there are two applications named “test” within an account, one will be renamed “test_1”.
• Accounts may now be created with a name that contains an underscore (_) as the last character.
• Tag subscriptions will now be removed when the last image for a tag is deleted from the system.
• Adds last_seen_in_days field to the archival rule exclusion block that allows images to be excluded from archive if there is a corresponding runtime inventory image where last_seen is within the specified number of days
• Image Vulnerabilities now provides the timestamp when each vulnerability was detected on the image. This is now available in the API and is indicated with the “detected_at” field.
• Reduced the number of Error Events generated when there is an issue accessing the registry. You will now only see on event generated per registry/repo. Previously there would be an event for each image.
• In order to reduce vulnerability false positives, it is recommended that users do not attempt vulnerability matches on go main modules with pseudo-version v0.0.0- or (devel) unless the true version has been specified via correction.

Fixes

• Subscriptions are now being properly cleaned up when images are deleted or archived.
• The API will return a proper error message if the caller attempts to delete an image, using the image ID, that is the latest of its tags and still has an active subscription.
• Providing an unsupported vulnerability type for API sources/{source_id}/vuln will result in a proper error message.
• Addressed an incorrect error events regarding Image Registry Lookups. This event was generated in error even when registry credentials were valid and the lookup succeeded.
• Errors that are detected during a vulnerability scan are now properly reflected in the API. Previously, it was possible that the scan would fail, but it would appear that the image had no vulnerabilities.
• Importing an image SBOM where the distro version is NULL or None, will now succeed.
• A max-images-per-account Archive Rule will correctly handle an image that has more than one tag associated with it.

Deprecations

• The Embedded Inventory Mode Feature has been deprecated as of this release. It will be removed from the Enterprise product during the future release of v4.2.0.
• Configuration Variable ‘ANCHORE_VULNERABILITIES_PROVIDER’ is no longer supported by Enterprise.
• Configuration Variable ‘ANCHORE_ENTERPRISE_FEEDS_THIRD_PARTY_DRIVERS_ENABLED’ is no longer supported by Enterprise.

Future Deprecations

• The anchore-cli Python client will be deprecated as of version 4.2 of Anchore Enterprise. AnchoreCTL contains all of the functionality of anchore-cli and is the default, supported tool for interacting with Anchore Enterprise as of 4.1.

UI Updates

Improvements

• In SSL-enabled environments, all requests made from client are automatically upgraded to use a secure connection.
• Account entries and user entries are now both permitted to contain spaces in their names. In addition, account names are now permitted to contain a trailing underscore (_) character.
• Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

Fixes

• Single sign-on (SSO) authentication now preserves the page URL. Prior to this update, the user would always be sent to the Dashboard view, but now the original location is used after the SSO authorization round-trip is complete.
• Due to a cookie misconfiguration, completion of the SSO round-trip would not always place the user inside an authenticated view, requiring a page refresh—this issue has now been addressed.
• The Whats's New tour dialog will now be displayed for new SSO users / SSO users logging in after a version update.
• When changing the displayed item range for any table within the Kubernetes view, under certain circumstances the app would whitescreen—this issue has now been fixed. In addition, the summary total of items shown for each table is now displayed correctly.
• The documentation link provided in the Add Cluster popup in the Kubernetes view is now correct.

21 - Anchore Enterprise Release Notes - Version 4.0.3

Anchore Enterprise 4.0.3

Anchore Enterprise v4.0.3 is a patch release containing targeted fixes and improvements. No database upgrade is necessary.

Enterprise Service Changes

Improvements

• Expanded capability for users with an image-analyzer role. The role now has the ability to create subscriptions.
• Added Amazon Linux 2022 vulnerability feed to the amazon driver. This will populate the amzn:2022 namespace.
• Support added for cataloging RPM databases with NDB and sqlite formats.
• Improved handling of manifest lists where the mediaType is missing.
• Details of Event Notifications have been improved for the following events:
  • user.image.analysis.pending
  • user.image.analysis.processing
  • user.image.analysis.complete
  • user.image_tag.added

Fixes

• The global archive rule for max number of images per account, will only consider images that have been analyzed and are in the active state.
• In some configurations, the global archive delete rule failed to run do to an error in the order of the rule processing. This issue has been corrected.

UI Updates

Improvements

• The Applications button in the navbar will remain highlighted when presented with the Artifact Analysis view for a source item, as sources are considered part of the navigation path for applications. In addition, this button will also now indicate the last application and version viewed (if applicable) in a popup on hover.
• Grab targets for Dashboard items widget have been increased inside for easier focus and manipulation.
• The legends associated with charts in the app have been removed in all instances where the meaning of the data is otherwise indicated.
• The createSubscription permission is now a requisite to use components that create subscriptions—this permission has also been added to roles where it was missing yet required in the context of the general purpose of that role (for example, image-analyzer).
• Non-alphanumeric characters are now permitted in the password used to authenticate against the AppDB service.

Fixes

• The Copy Allowlist modal within the Tools dropdown for items displayed within the Alowlists tab of the Policy Editor had an issue whereby focus would be drawn away from the Name input field, preventing the submission of a valid form. This behavior is now fixed.
• Due to a regression in our date component, removing a timestamp from the Edit Allowlist Items dialog in the Policy Editor or from the Add / Remove Allowlist Item dialog associated with compliance results in the Artifact Analysis view would result in an error on save. This has been fixed.
• The Copy Policy modal within the Tools dropdown for items displayed within the Policies tab of the Policy Editor would successfully copy a policy, but would fail to close after the operation concluded. This behavior is now fixed.
• The summary count of event items in the Events view now correlates to the number displayed after a severity filter (WARN / INFO) has been applied. Prior to this fix, the count would remain the same.
• Removing all filter boxes displayed within the Events view would also remove the Clear Filters button, preventing any filters previously applied from the boxes from also being removed. This behavior has now been fixed.
• An error in our payload validation system caused the notifications component to fail to update upon editing an entry. This issue has now been resolved.
• The RBAC permissions associated with policy-editor role are now correctly asserted when trying to navigate to Images or Applications using the main navigation bar (or when using the minimized icons in the topnav that appear when the main bar is out of view).
• Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

22 - Anchore Enterprise Release Notes - Version 4.0.2

Anchore Enterprise 4.0.2

Anchore Enterprise v4.0.2 is a patch release containing targeted fixes and improvements. No database upgrade is necessary.

Enterprise Service Changes

Improvements

• Expanded capability for users with an image-analyzer role. The role now has the ability to modify image subscriptions.
• Added support of space characters in usernames.
• It is now possible to create an account name that contains a forward slash character.
• Added support for policy bundle license gate triggers to differentiate between os and non os components during package license checks.
• Tech Preview: Added the ability to run a stateless vulnerability scan of a sbom via a new API call.
• Added new event types which improve visibility during the image analysis workflow.
  • user.image.analysis.pending
  • user.image.analysis.processing
  • user.image.analysis.complete
  • user.image_tag.added

Fixes

• Fixed the growth of log files beyond 10MB and collection of log files when reaching the maximum count of 10 files.
• Fixed the detection of vendored golang modules in built binaries.
• Fixed the analysis of images with binaries built by golang 1.18 to correctly identify the go modules used.
• Improved grypedb to exclude matching entries that have been withdrawn from GitHub Security Advisories.
• Improved grypedb to handle entries without primary vulnerability identifier which may be received from vulnerability feed services.
• Fix ability to update existing ECR registry credentials, no longer reports an 406 error.

UI Updates

Improvements

• The content types within the SBOM tab under Artifact Analysis in the UI are now presented vertically to prevent them being truncated at narrower screen widths.
• It is now possible to create an account name that contains a forward slash character
• In order to improve the filtering and sorting operations within the Mappings tab of the Policy Editor in the UI, source and image mappings are now stored within their own dedicated subtabs.
• Various supporting UI libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

Fixes

• When resizing the table columns in the UI Applications view, the action controls could be made to overflow the bounds of their cell—this is now fixed.
• Items added via anchorectl would occasionally cause an app exception when viewed from within the Applications view in the UI. This issue has now been addressed.
• The JSON entry in the SBOM Report download menu in the UI within the Artifact Analysis view had an extraneous tail pointer, which has now been removed.
• The button to download a report from the Vulnerabilities tab in the Artifacts view in the UI now correctly reads Vulnerability Report instead of Compliance Report.
• The no-results condition in the content view for Malware under the SBOM tab of the Artifact Analysis view in the UI did not disambiguate between no results being found vs. malware scanning not being enabled. If malware scanning is not enabled, the message now indicates this and provides a link to the documentation for this feature.
• As of release 4.0.0, the default behavior when creating a new policy bundle was to add a default source rule and mapping, however this interfered with the upgrade path for users who wanted to upload a pre 4.0.0 bundle to the system. These default entries are no longer added.
• The information and recent creation indicator labels within the Stored Report Items component of the advanced Reports view in the UI are now correctly aligned.
• Switching account context within the UI and then attempting to download a report would result in a fatal app error due to missing privileges on the call that fetches the data. This issue has now been addressed.
• A slight error in the alignment of the header within the UI date picker component has been addressed.

23 - Anchore Enterprise Release Notes - Version 4.0.1

Anchore Enterprise 4.0.1

Anchore Enterprise v4.0.1 is a patch release containing targeted fixes and improvements. No database upgrade is necessary.

Fixes

• Fixes issues with vulnerability data matching for a small set of distros including Ubuntu, Oracle Linux, and Amazon Linux. All customers are recommended to upgrade to include this patch.

AnchoreCTL

The latest version of AnchoreCTL is 0.2.0. AnchoreCTL is dependent on Syft v0.39.3 as a library.

AnchoreCTL v0.1.4 is vulnerable to CVE-2022-1766, which was fixed in v0.1.5+. We strongly encourage users to upgrade to the latest version.

The current features that are supported are as follows:

• Ability to add sboms via anchorectl using stdin to provide an existing SBOM without re-creating it.
• Source Repository Management: Generate an SBOM and store the SBOM in Anchore’s database. Get information about the source repository, investigate vulnerability packages by requesting vulnerabilities for a single analyzed source repository, or get any policy evaluations.
• Download full image SBOMs for images analyzed with Enterprise 4.0.0.
• Compliance Reports: View and operate on runtime compliance reports, such as STIGs, created by the rem tool.
• Corrections Management: View and modify corrections information to help reduce false positives in your vulnerability results.
• Image Management: View, list, import local analysis, and request image analysis by the system.
• Runtime Inventory Management: Add, update, and view cluster configurations for Anchore to scan, as well as for the inventory reports themselves.
• System Operations: View and manage system information for your Enterprise deployment.

24 - Anchore Enterprise Release Notes - Version 4.0.0

Anchore Enterprise 4.0.0

The Anchore Enterprise 4.0.0 release offers significant new supply chain security features expanding the Anchore Enterprise SBOM management platform beyond container scanning. Users can now generate and continuously monitor SBOMs for their source code repositories to identify vulnerability and security risks. Policy rules that are specific to managing source code are now available in the Policy Engine. Multiple source code and container image SBOMs can also now be grouped together as an Application that can be managed as a single set enabling generation of SBOMs representing a total application or service.

Additional new SBOM capabilities enable users to observe and limit SBOM drift between container image builds. Users can use policy rules to enforce immutable container best practices or help detect potentially malicious activity.

AnchoreCTL, the integration tool for use in CI/CD pipelines, has also been updated to include Source Repository Management.

A number of performance improvements have also been made to improve the response of the GUI, reporting service, as well as the efficiency of the queue processing processes.

Version 4.0.0 also includes other improvements and fixes.

New Features

The following new features are included in Enterprise 4.0.

SBOM Management

You can now generate SBOMs using AnchoreCTL as part of a command line or CI/CD workflow, through pulling content from a registry, or by submitting an artifact to the Anchore API.

SBOMs can be managed using the command line, API or GUI, where contents can be grouped together, annotated, viewed, or searched. Artifact metadata, vulnerability information, and policy evaluations can also be viewed and managed through the same interfaces.

All SBOMs can be downloaded into a variety of formats, either individually or collectively, to be sent to security teams, customers or end-users.

Applications

You can now build applications in Anchore Enterprise. Applications are the top-level building block in a hierarchical view, containing artifacts like packages or image artifacts. Applications can represent any project your teams deliver. Each application is associated with one or more application versions which track the specific grouping of artifacts that comprise a product version.

Anchore Enterprise lets you model your versioned applications to create a comprehensive view of the vulnerability and security health of the projects your teams are building across the breadth of your Software Delivery Lifecycle.

By grouping related components into applications, and updating those components across application versions as projects grow and change, you can get a holistic view of the current and historic security health of the applications from development through built image artifacts.

SBOM Drift

You can now 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.

There is a new gate called: tag_drift

The triggers are:

• packages_added
• packages_removed
• packages_modified

Legacy Vulnerability Scanner No Longer Supported

The legacy vulnerability scanner is no longer included as an option when installing or upgrading Anchore Enterprise.

If you currently have Enterprise configured to use the legacy vulnerability scanner, you will not be able to successfully upgrade and start the system without explicitly configuring the default vulnerability scanner.

You can remove that configuration variable so the system can default to the current vulnerability scanner.

If you choose not to upgrade, instead performing a new installation of Enterprise, the vulnerability scanner will be configured by default.

Improvements

• Analyzers no longer wait 5 seconds between analysis tasks if the last queue check had work available.
• Adds global image count metrics to the set of available prometheus metrics.
• Adds new internal reports_worker service that processes async tasks for reporting data.
• Adds reporting task (data load, refresh, etc) to the set of available prometheus metrics.
• System can be configured to automatically delete events older than a specified age to help manage data growth.
• Go modules detected and reported from within binaries.
• Removes old and unsupported PG8000 DB driver from container image. Database connection strings starting with “pg8000:” will no longer work.
• Default PostgreSQL version used in the Quickstart docker-compose.yaml is updated from 9.6 to 12. Anchore’s Postgres requirements are unchanged.
• Reporting service can be configured to remove reporting data for images deleted or archived.
• Reporting service data update performance improvements and scalability improvements.

Fixes

• Resolved data leaks from the grypedb feeds driver that could occur when process terminated by OS.
• Resolved reporting service refresh issue.
• Reporting service no longer looks at or attempts to refesh deleted image data. Reporting procedures now operate on data sets where the analysis state is analyzed and image state is active.
• There was an issue with the Debian driver providing empty content. The grype-db-builder now builds all Debian data in the feeds service.
• The NVD CVSS scores known issue from the 3.3.0 release has been fixed. NVD CVSS scores are now present in the API responses for the request to get a detailed information query about a vulnerability feed record.
• Stale feeds policy trigger issue fixed.
• Report worker tag refresh issue fixed.
• Fixes vulnerability scanning failures for container images with no known distro.

Known Issues

• The vulnerability scanner needs to be explicitly configured for Grype. If it is configured for v1 (legacy) vulnerability scanner, you will get an error during upgrade.

  • Workaround:

    Helm chart: Set services->policy_engine->vulnerabilities->provider to grype. Docker-compose: The environment variable ANCHORE_VULNERABILITIES_PROVIDER=grype must be present for the policy-engine service.

• Image drift only supports comparison of images analyzed by 4.0.0. Images analyzed prior to upgrade do not support drift computation and will result in a policy evaluation warning message.

• Image SBOM downloads do not include content hints entries or detected binaries (python, go) that are not installed via a package manager.

Enterprise UI Changes

• New Applications tab. Observe applications in Enterprise and see a summary of the artifacts that have been collected into an application. From the application view, you can drill down into the source repositories or container images that make up the application, and browse their SBOMS.
• View applications and application versions from source repositories and image containers. The information is categorized by applications, with sub-categories of application versions available.
• You can download an SBOM report in JSON format for everything in an application.
• View information about an artifact, such as the policies set up, the vulnerabilities, SBOM contents,and metadata information.
• From the Policies tab, set up policies and policy bundles for source repositories.

Fixes

• Fixed inventory view performance issues with large data sets.
• Report manager now returns preview results.
• The inventory service error now returns the appropriate 500 error message.
• Fixed how the ordering of policy bundle mappings are displayed within a table.
• Increased the LDAP filter character limit.
• Package names within the Vulnerability tab are now sorted alphanumerically.

Upgrading

Upgrading to Anchore Enterprise 4.0.0 involves a database upgrade that the system will handle itself. It may cause the upgrade to take several minutes.

If you currently have Enterprise configured to use the legacy vulnerability scanner, you will not be able to successfully upgrade and start the system without explicitly configuring the default vulnerability scanner.

You can remove that configuration variable so the system can default to the current vulnerability scanner.

If you choose not to upgrade, instead performing a new installation of Enterprise, the vulnerability scanner will be configured by default.

AnchoreCTL

The latest version of AnchoreCTL is 0.1.4. AnchoreCTL is dependent on Syft v0.39.3 as a library.

The current features that are supported are as follows:

• NEW! Source Repository Management: Generate an SBOM and store the SBOM in Anchore’s database. Get information about the source repository, investigate vulnerability packages by requesting vulnerabilities for a single analyzed source repository, or get any policy evaluations.
• NEW! Download full image SBOMs for images analyzed with Enterprise 4.0.0.
• Compliance Reports: View and operate on runtime compliance reports, such as STIGs, created by the rem tool.
• Corrections Management: View and modify corrections information to help reduce false positives in your vulnerability results.
• Image Management: View, list, import local analysis, and request image analysis by the system.
• Runtime Inventory Management: Add, update, and view cluster configurations for Anchore to scan, as well as for the inventory reports themselves.
• System Operations: View and manage system information for your Enterprise deployment.

25 - End-of-Life Releases

25.1 - Anchore Enterprise Release Notes - Version 3.3.0

Anchore Enterprise 3.3.0

This release offers Rocky Linux support and various UI updates.

Version 3.3.0 also includes other improvements and fixes.

Rocky Linux support

Anchore Enterprise can now scan Rocky Linux images for vulnerabilities.

Configure maximum number of parallel workers

Asynchronous parts of the image deletion workflow in the backend can now be parallelized. You may now configure the maximum number of parallel workers in the catalog configuration.

Fixes

• Images that had Go content and hints enabled were failing analysis. This has been fixed.
• Images reported via runtime inventory that also had port numbers in the registry host URL were failing to parse properly, which caused scan failures. This issue has been fixed.
• NuGet packages were not matched to vulnerabilities correctly. This is now fixed.
• With the Grype provider, NVD and vendor CVSS scores were missing for records in non-NVD namespaces. This is now fixed.
• Migration code was added to clean-up the unused feed records, and fixed artifacts and vulnerabilities records for the github:os group.

Known Issue

NVD CVSS scores may not be present in the API responses for the request to get a detailed information query about a vulnerability feed record.

• There is a workaround to get this information. See the Workaround section below for more details on the workaround.
• This is only present for a subset of records NVD records.
• It does not impact the vulnerability reports or findings for images. It only impacts the next-gen vulnerability scanner, so users still on the legacy scanner are not impacted.

Details

The /query/vulnerabilities API response contains an nvd_data attribute for each vulnerability in the result. The value of the attribute represents the NVD assigned CVSS scores. This field is not correctly populating for a small subset of vulnerabilities in the system. Instead of a list of results, the value is a null reference as shown below. Note: This known issue only affects vulnerabilities that exclusively belong in the nvd namespace with Grype as the vulnerabilities provider (next-gen v2 scanner). It does not affect the legacy vulnerability provider.

% curl -u user:password "http://localhost:8228/v1/query/vulnerabilities?id=CVE-2019-15780"
{
    "page": "1",
    "returned_count": 1,
    "total_count": 1,
    "vulnerabilities": [
    {
        "affected_packages": [
        {
            "name": "formidable_form_builder",
            "type": "unknown",
            "version": "< 4.02.01",
            "will_not_fix": false
        }
        ],
        "description": "The formidable plugin before 4.02.01 for WordPress has unsafe deserialization.",
        "id": "CVE-2019-15780",
        "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-15780",
        "namespace": "nvd",
        "nvd_data": null,
        "references": [
        {
            "source": "N/A",
            "url": "https://wordpress.org/plugins/formidable/#developers"
        },
        {
            "source": "N/A",
            "url": "https://raw.githubusercontent.com/Strategy11/formidable-forms/master/changelog.txt"
        },
        {
            "source": "N/A",
            "url": "https://pentest.co.uk/labs/advisory/cve-2019-15780/"
        },
        {
            "source": "N/A",
            "url": "https://wpvulndb.com/vulnerabilities/9935"
        }
        ],
        "severity": "Critical",
        "vendor_data": []
    }
    ]
}

Workaround

The API supports a namespace query parameter to filter results based on the namespace. Supply the namespace with an nvd value to view the NVD CVSS scores, as shown in the following example.

% curl -u user:password "http://localhost:8228/v1/query/vulnerabilities?id=CVE-2019-15780&namespace=nvd"
{
    "page": "1",
    "returned_count": 1,
    "total_count": 1,
    "vulnerabilities": [
    {
        "affected_packages": [
        {
            "name": "formidable_form_builder",
            "type": "unknown",
            "version": "< 4.02.01",
            "will_not_fix": false
        }
        ],
        "description": "The formidable plugin before 4.02.01 for WordPress has unsafe deserialization.",
        "id": "CVE-2019-15780",
        "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-15780",
        "namespace": "nvd",
        "nvd_data": [
        {
            "cvss_v2": {
            "base_metrics": {
                "base_score": 7.5,
                "expolitability_score": 10,
                "impact_score": 6.4
            },
            "severity": "High",
            "vector_string": "AV:N/AC:L/Au:N/C:P/I:P/A:P",
            "version": "2.0"
            },
            "cvss_v3": null,
            "id": "CVE-2019-15780"
        },
        {
            "cvss_v2": null,
            "cvss_v3": {
            "base_metrics": {
                "base_score": 9.8,
                "expolitability_score": 3.9,
                "impact_score": 5.9
            },
            "severity": "Critical",
            "vector_string": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.0"
            },
            "id": "CVE-2019-15780"
        }
        ],
        "references": [
        {
            "source": "N/A",
            "url": "https://wordpress.org/plugins/formidable/#developers"
        },
        {
            "source": "N/A",
            "url": "https://raw.githubusercontent.com/Strategy11/formidable-forms/master/changelog.txt"
        },
        {
            "source": "N/A",
            "url": "https://pentest.co.uk/labs/advisory/cve-2019-15780/"
        },
        {
            "source": "N/A",
            "url": "https://wpvulndb.com/vulnerabilities/9935"
        }
        ],
        "severity": "Critical",
        "vendor_data": []
    }
    ]
}

Enterprise UI Changes

• Multi-image selection and deletion now possible for RepositoryView.
• The login page banner can now be edited. You can now edit the banner on the login page to provide customized information, such as how to log in, whether to use SSO or email addresses, and support contact information.
• Failed images can now be removed from a repository.
• The context of the policy bundle test results view is now preserved as a user changes to different tabs.

Fixes

• JSON and CSV downloads from the Policy Compliance tab now include the policy bundle name and data.
• Compliance tables now correctly filter based on column data.

Upgrading

Upgrading to Anchore Enterprise 3.3.0 involves a database upgrade that the system will handle itself. It may cause the upgrade to take several minutes.

AnchoreCTL

The latest version of AnchoreCTL is 0.1.3. AnchoreCTL is dependent on Syft v0.20.0 as a library.

The current features that are supported are as follows:

• Compliance Reports: View and operate on runtime compliance reports, such as STIGs, created by the rem tool.
• Corrections Management: View and modify corrections information to help reduce false positives in your vulnerability results.
• Image Management: View, list, import local analysis, and request image analysis by the system.
• Runtime Inventory Management: Add, update, and view cluster configurations for Anchore to scan, as well as for the inventory reports themselves.
• System Operations: View and manage system information for your Enterprise deployment.

25.2 - Anchore Enterprise Release Notes - Version 3.2.1

Anchore Enterprise 3.2.1

v3.2.1 is a patch release of Anchore Enterprise containing targeted fixes and improvements. No database upgrade is necessary.

Enterprise Service Changes

Fixes

• Feed syncs no longer fail for GitHub groups.
• Images failing analysis due to specific unexpected python package format issue fixed in Syft to ensure analysis can complete.
• Content hints now correctly scan non-OS packages for vulnerabilities.
• The Syft invocation during image analysis now uses the analyzer unpack directory consistent with other analysis data IO instead of the OS default temp directory.

Enterprise UI Changes

Fixes

• Image Analysis: Vulnerabilities. RPM packages were displayed as RedHat packages in the Vulnerabilities tab, and they used the RedHat icon for SuSE images. The RPM icon is now used, and the package type is now simply described as RPM.
• Image Analysis: Ancestry. Image ancestry fetch errors are now gracefully handled inline and do not block image analysis calls if they occur.
• Image Selection: Add Image/Add Repository. Opening the Add Registry dialog from the Add Image or Add Repository dialogs would cause the tooltips on the initial dialogs to flicker if you attempted to view them after dismissing the Add Registry dialog. This is now fixed.
• Kubernetes Inventory: Analyze Image. On initial presentation of the list of any images detected within a namespace, the buttons that allowed you to analyze new images would be disabled. This was due to an RBAC permission error. This issue is now fixed.
• LDAP: Connectivity. LDAP authentication connection timeouts have now been externalized in order to allow customers to directly configure these thresholds, if necessary. These values can be set via the file- or environment-based Enterprise Client application configuration parameters.
• Miscellaneous. Various supporting libraries have been updated to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have also been removed to reduce the app startup time and overall size.

Upgrading

No database upgrades are required for this update.

25.3 - Anchore Enterprise Release Notes - Version 3.2.0

Anchore Enterprise 3.2.0

This release brings the Next-Gen (v2) vulnerability scanner, based on Grype, from Tech Preview into full support and makes it the default for new Anchore Enterprise deployments.

Version 3.2.0 also includes other improvements and fixes.

New Features

Next-Gen scanner is now the default vulnerability scanner

Anchore Enterprise now uses the Next-Gen scanner, based on Grype, for vulnerability scanning. The new scanner replaces the legacy vulnerability scanner, but legacy remains available.

Only new installations will default to the new scanner. Upgrades for existing deployments will use the same scanner as the pre-upgrade deployment unless specifically configured to change.

See Vulnerability Scanner for more information.

SUSE Linux Enterprise Server (SLES) support

Anchore Enterprise can now scan SLES and OpenSUSE images for vulnerabilities.

Allow trigger IDs to be added to allow lists

To allow list a package and version rule, a mechanism to allow list items other than vulnerabilities has been added to the app.

Fixes

Dependency updates to resolve vulnerability findings.

Enterprise UI Changes

Added

• New Secret Search content tab. Secret Search results are now available within the Image Analysis → Contents page. These artifacts are already calculated during analysis, but were not previously visible in the UI.
• New Content Search content tab. Content Search results are now available within the Image Analysis → Contents page. These artifacts are already calculated during analysis, but were not previously visible in the UI.
• New Retrieved Files content tab. Retrieved Files results are now available within the Image Analysis → Contents page. These artifacts are already calculated during analysis, but were not previously visible in the UI.
• Add / Edit Registry Credentials feature now is accessible from the Account menu. Since the Registry Credentials are at the account level, they were moved from the System view to the top-right Account menu. It is also accessible from within the Analyze Repository / Tag modals.
• View package metadata from the Vulnerabilities tab main table. As a SecOps user, you can now see more information about a package listed with a vulnerability in the Vulnerabilities tab main table. You can click the Package column entry to assess the impact, and determine if the vulnerability match may be a false positive.
• Analyzing images can now be removed in bulk via the Analysis Cancellation / Repository Removal dropdown.
• Content tab data is now cached. Content type tabs within the Image Analysis → Contents page are now lightly cached for performance.
• Permit gates other than vulnerabilities to be added to an allowlist. This includes package version triggers, and more.
• Descriptions can be added upon allowlisting a trigger from within the Image Analysis → Policy Compliance tab.

Fixes

• View Reports tab now available for any user with listImages permissions.
• Severities filter is now properly handled for scheduled Runtime Inventory Images by Vulnerability queries.
• Table columns are automatically resized. When table column widths are greater than the total width of its container, they automatically resize to avoid overlap of text.
• LDAP user mappings are now removed upon account deletion.
• Miscellaneous: Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

Upgrading

With the new scanning engine there may be slightly different vulnerability results due to improved accuracy. It is highly recommended for you to reach out and partner with Anchore Support for planning and managing the upgrade to ensure minimal disruption for your workflows and workloads.

Upgrading to Anchore Enterprise 3.2.0 involves a database upgrade that the system will handle itself. It may cause the upgrade to take several minutes.

• Upgrading Anchore

25.4 - Anchore Enterprise Release Notes - Version 3.1.2

Anchore Enterprise 3.1.2

v3.1.2 is a patch release of Anchore Enterprise containing targeted fixes and improvements. No database upgrade is necessary.

Enterprise Service Changes

Fixes

• The Syft /tmp directory clean-up error is now fixed.
• Anchore Enterprise now runs on FIPS-enabled hosts.

Enterprise UI Changes

Fixes

No changes to the Anchore UI from 3.1.1.

Upgrading

No database upgrades are required for this update.

• Upgrading Anchore

25.5 - Anchore Enterprise Release Notes - Version 3.1.1

Anchore Enterprise 3.1.1

v3.1.1 is a patch release of Anchore Enterprise containing targeted fixes and improvements. No database upgrade is necessary.

Enterprise Service Changes

Note: the Content Hints feature now only supports adding new packages to the analysis report and can no longer modify or update package records found by the package analyzers. This is to ensure unintended conflicts do not occur.

Fixes

• Some RPMs content in hints file causes analysis to fail
• Feeds service driver for MSRC safely handles unexpected data from upstream
• Feed service MSRC driver should not require a Microsoft API key
• Ubuntu feed service driver git repo sync error
• Github feed service driver incorrectly categorizes some data
• Sometimes get error when trying to analyze image due to finding unsupported package types
• Remove unused nvd scores from normalized vulnerability records
• Alpine feeds driver to use CVSS v3 for severity scoring instead of CVSS v2
• Events not generated correctly if an image digest has multiple tags
• Ensure content hints do not conflict with findings from analyzers and only add entries and cannot modify existing analysis finings
• SSL Error handling in swift objectstorage driver
• Syft/Stereoscope cache in /tmp not cleaned up after image analysis
• Adds will_not_fix field to vulnerability report API response
• Adds will_not_fix field to /query/vulnerabilities response
• Wrong tag may be used for image download during analysis if the digest is mapped to multiple tags
• Dependency updates to resolve non-impacting vulnerability findings
• Additional minor bug fixes and enhancements

Enterprise UI Changes

Fixes

• Socket protocol now enforceable via configuration to avoid false positives with application scanners
• Allow expiration of allowlist item to be set via Vulnerabilities table view in Image Analysis
• Security vulnerability in package WS addressed
• Add/Edit User & Add/Edit LDAP User Mapping modal content overflows issue fixed
• Enable System button for users with correct requisite permissions
• Users without correct permissions can no longer directly access app routes via URL
• Default allowlist expiration now set to 30 days
• Items with vulnerabilities inherited from base image can now be excluded by filter in Vulnerabilities view in Image Analysis
• Users can now be prevented from accessing the app for a configurable amount of time after a configurable number of invalid login attempts
• Improved internal field validation to prevent unexpected input in AppDB report routes
• Additional minor bug fixes and enhancements

Upgrading

No database upgrades are required for this update.

AnchoreCTL

• Updates vendor_only option to default to true for consistent experience with users coming from anchore-cli

• Upgrading Anchore

25.6 - Anchore Enterprise Release Notes - Version 3.1.0

Anchore Enterprise 3.1.0

This release adds new capabilities for automated runtime inventory scanning, runtime container compliance checks, a new vulnerability scanner option in tech preview, a new enterprise CLI, as well as other improvements and fixes.

New Features

Runtime Kubernetes Inventory Scanning with UI Support

Building on the runtime inventory features in the 3.0 release, Anchore can now automatically analyze images reported as in use in kubernetes clusters so that you can easily assess the security risks not only of image in your CI pipelines, but also in production in your clusters. Additionally, the UI now supports visualizations of kubernetes inventories and the vulnerability and policy compliance status of the inventory by namespace or cluster.

See Runtime Kubernetes Inventory for more information.

Runtime Compliance Checks for Containers

Anchore now includes the ability to execute and collect runtime compliance checks using industry standard tooling such as OpenSCAP to provide evaluation of running containers’ STIG compliance or any other compliance specification that can be described and checked using XCCDF profiles.

See Compliance Checks for more information on this feature.

New CLI with Integrated Pipeline Scanning Support

The new anchorectl tool provides a new Enterprise-focused CLI experience with support for local analysis of images to import into your deployment. Using the new tool you can also perform other Enterprise operations such as interacting with new compliance reports and viewing or configuring inventory scanning.

Tech Preview Features

A new vulnerability scanner based on Grype is now available in tech preview. See Vulnerability Scanner V2 for more information. This update is not configured by default and must be set by opt-in using a configuration value.

Enterprise Service Changes

This release contains a database schema update to version 0.0.8 for the enterprise schema and 0.0.15 for the engine schema. The upgrade process will modify the db schema and update some tables in the reporting service for any existing runtime inventory records. Unless you have a very large number of inventory records, the upgrade should complete in seconds to minutes depending on your database size.

Owned Package Filtering Control

A new configuration option: services.analyzer.enable_owned_package_filtering: is now available in the analyzer service configuration. By default, the analyzer will filter packages that are determined at analysis time to be “owned” by a parent package when that package installs all the files of the child package. That behavior can be disabled by setting this configuration value to “false”.

The default filtering removes false positives associated with packages installed by distro packages that install language packages like python, npms, or gems and have backports applied by the distro maintainer with no corresponding language package version change. However, if you package your own applications as rpms, debs, or similar and need to ensure all included packages are scanned directly against NVD sources, then you can disable this behavior.

Added

• New tech-preview vulnerability scanner
• Improved alpine vulnerability scanning by using NVD matches for OS packages for CVEs that are not yet present in Alpine SecDB
• Analyzer service configuration option to control package-ownership filtering. Allows exposing all packages regardless of ownership relationship

Fixed

• Adds missing fields and fixes errors in the swagger spec for the API
• Restores file package verification data ingress during image load to fix a regression
• Malware policy gate can fail causing policy eval error when malware not enabled and other rules precede malware rule in a policy
• JSON serialization error in internal policy engine user image listing API
• “package_cpe23” field missing in vulnerabilities
• Ensure python38 used in the Dockerfile build, and set tox tests to only run py38
• User to not be able to delete some notification configurations when they should be able based on RBAC role

Improved

• Performance of GET operations between services improved by better streaming memory management for large payload transfers
• Use UBI 8.4 as base image in Docker build
• Updates skopeo version used to 1.2.1, allowing removal of the ’lookuptag’ field in the POST /repositories call for watching repositories that do not have a ’latest’ tag
• RedHat packages for an Out-of-Support distro release version now indicated as being vulnerable if a newer distro release version is supported and indicated as affected for the package.

Additional minor bug fixes and enhancements

Known Issues/Errata

Note: the policy engine feed sync configuration is now in the policy engine service configuration as part of the provider configuration. The provided helm charts, docker-compose.yaml and default configurations handle this change automatically.

Deprecations

The affected_package_version query parameter in GET /query/vulnerabilities is not supported in the V2 scanner (aka Grype mode) and has known correctness issues in the legacy mode. It is deprecated and will be removed in a future release.

Enterprise UI Changes

Added

• From the new Kubernetes Runtime Inventory view you can now inspect the spread of compliance and vulnerability information reported by the KAI agent across all detected Kubernetes clusters and namespaces in your deployment topology
• Information relating to any items detected by the runtime agent is now surfaced in the repository- and tag-level views within the Image Selection hierarchy

Improved

• If the reporting service fails, feature components that require this service as a dependency will be disabled in the navigation bar until service recovery
• Pie-chart components have been restructured to present selected information inclusively when segments are clicked—other segments are now disabled

Fixes

• Printable view assembly issues addressed in Image Analysis Vulnerability and Compliance views—charts now render correctly in portrait mode
• The alerts banner is now subject to RBAC and will not appear if the fetch alert permission is not detected
• Clipping issues resolved in the creation date popup in the Policy Bundle view
• Supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs

Additional minor bug fixes and enhancements

Upgrading

• Upgrading Anchore

25.6.1 - Runtime Compliance API

Overview

You can use the Anchore runtime compliance API to gain insight into the security compliance of runtime environments. Tools responsible for executing compliance checks on a running environment are the intended consumers of this general-purpose API, such as the Security Technical Implementation Guides (STIGs) that users can run on a Kubernetes cluster using Anchore’s Remote Execution Manager (REM). These tools can upload the results of an execution to Anchore through this new compliance API, which allows users to leverage additional Anchore functionality like reporting and correlating the runtime environment to images analyzed by Anchore. This enables deeper understanding and insight into an image’s lifecycle and the ongoing security of the runtime environments deploying them.

Usage

The Compliance API can be found in the Enterprise API swagger specification. This API allows for the creation and retrieval of runtime compliance checks and any document reports provided in the creation calls.

The following is an example of the body of an API call to create a runtime compliance check using the Compliance API to be submitted as a multipart form to support file upload:

{
  "check_type": "oscap", // type of compliance check to report
  "result": "pass", // overall result of compliance check
  "pod": "postgres-9.6", // k8s or kubernetes pod the compliance check was run against
  "namespace": "dev", // the namespace of the pod
  "image_tag": "9.6", // tag of the image that the pod is running
  "image_digest": "sha256:a435b8edc3bdb4d766818dc6ce22ca3a5e6a922d19ca7001afd1359d060500eb", // the digest of the running image
  "start_time": "2021-03-22T15:12:24.580054", // start time of the compliance run
  "end_time": "2021-03-22T16:02:24.580054" // end time of the compliance run
  "result_file": "path_to_file",
  "report_file": "path_to_file
}

Two fields are required for the creation of runtime compliance checks. The type field references the type of scan that generates the report. The only supported option is oscap, which stands for OpenSCAP. The other required field is image_digest, which represents the image used by the container that the runtime compliance check was run against.

While not required, the status attribute is used to designate whether the given compliance check has passed or failed. There are several additional metadata fields provided to further contextualize the runtime check, such as the pod and namespace that the check was run against.

One of the other key functionalities of this API is the ability to attach a report_file and a result_file to the created runtime compliance checks. This can be the direct output generated by the runtime tool itself, such as an OpenSCAP XML document. This allows for entire reports to be stored within Anchore using the object storage, which allows for a number of options for how and where this data will be preserved.

Once created, runtime compliance checks can be retrieved using the GET endpoint specified in the Swagger spec. The corresponding result and report files can be retrieved by pulling the file_ids from a runtime compliance check and querying the endpoint for runtime compliance results using the specified result_id.

25.6.1.1 - Enterprise Compliance Checks

Remote Compliance Check

Anchore Enterprise Remote Execution Manager (REM) enables an operator to run a compliance check for a defined container within a Kubernetes Cluster. REM contains functionality to perform package management such as installation and removal of OpenSCAP, retrieval of generated results files, and upload capabilities to the compliance API. There is also a provided local data-store if upload functionality is disabled or unavailable.

• Installation
  • MacOS
  • Debian
  • RPM
  • Tar
  • Windows
• Usage
  • Completion
• Configuration
• Pod Configuration
• Compliance Tool Installation
• Running a Compliance Check
• Custom STIG Targets
• Auditing Uploads
• Database Utilities

Installation

REM releases are uploaded to a public AWS S3 bucket.

To install REM, you can use either the AWS CLI or cURL to retrieve both the binary and the default configuration for REM.

Retrieving the default configuration file is the same regardless of which operating system you’re using:

curl -o rem.yaml https://anchore-rem-releases.s3-us-west-2.amazonaws.com/v0.1.9/rem.yaml

macOS dmg

curl -o rem.dmg https://anchore-rem-releases.s3-us-west-2.amazonaws.com/v0.1.9/rem_0.1.9_darwin_amd64.dmg

macOS Tar

curl -o rem.tar.gz https://anchore-rem-releases.s3-us-west-2.amazonaws.com/v0.1.9/rem_0.1.9_darwin_amd64.tar.gz

Debian

curl -o rem.deb https://anchore-rem-releases.s3-us-west-2.amazonaws.com/v0.1.9/rem_0.1.9_linux_amd64.deb

RPM

curl -o rem.rpm https://anchore-rem-releases.s3-us-west-2.amazonaws.com/v0.1.9/rem_0.1.9_linux_amd64.rpm

Linux Tar

curl -o rem.tar.gz https://anchore-rem-releases.s3-us-west-2.amazonaws.com/v0.1.9/rem_0.1.9_linux_amd64.tar.gz

Windows

curl -o rem.zip https://anchore-rem-releases.s3-us-west-2.amazonaws.com/v0.1.9/rem_0.1.9_windows_amd64.zip

Usage:

REM can work well out-of-the-box with minimal required configurations.

At the very least, REM needs to be able to authenticate with the Kubernetes API, know which command to run, and know which pod and container to connect to. If you have a Kube Config at ~/.kube/config, REM will use that by default.

To see how to configure REM with these minimal details, see the Pod Configuration section

Shell Completion

REM supports completion for BASH, Zsh, and Fish shells. Run rem completion -h for more information.

Configuration

REM will search for the configuration file in a few locations:

The following examples are listed in the order of precedence.

From the CLI you can pass a -f or --config flag with the path to the configuration file.

> rem -f /tmp/anchore/config.yaml

Setting an Environment variable:

> export REM_CONFIGPATH="/tmp/anchore/config.yaml"

Current directory of execution:

./rem.yaml
.rem/config.yaml

User home directory path:

~/.rem.yaml

XDG configured directory path:

rem/config.yaml

It is always recommended to use the configuration file that is attached to each release as an artifact. The example configuration file in the repository is a good reference for explaining which configuration key does what.

Pod configuration

This section will describe the minimum required configuration required for REM to work.

In the file, you can specify kubernetes pod information in the following section:

# This section tells REM the execution details for the STIG check report:
# Pod Name, Namespace, and Container Name are required so that REM knows where to exec the stig check
report:
  podName: "centos"
  nameSpace: "default"
  containerName: "centos"

  # These must be set via the file, and correspond to the command being executed in the container
  # For example, if your compliance check command looks like this:
  #   oscap xccdf eval --profile <profile> --results /tmp/anchore/result.xml --report /tmp/anchore/report.html target.xml
  # The values should for --results and --report should match the values of these configurations.
  # The file paths defined here are also where REM downloads the files from the container. You can think of it like this:
  #    docker cp container:/tmp/anchore/report.html /tmp/anhore/report.html
  reportFile: "/tmp/anchore/report.html" 
  resultFile: "/tmp/anchore/result.xml"

# REM supports Kubernetes Configuration in the following manner:
#   1. If you have a Kubeconfig at ~/.kube/config, you don't need to set any of these fields below, REM will just use that
#   2. If you want to explicitly specify kubernetes configuration details, you can do so in each field below (ignore path)
#   3. If you are running REM within Kubernetes, set path to "use-in-cluster" and set cluster to the cluster name and you don't need to set any of the other fields
kubeconfig:
  path: "" # set to "use-in-cluster" if running REM within a kubernetes container
  cluster: ""
  clusterCert: # base64 encoded cluster cert
  server:  # ex. https://kubernetes.docker.internal:6443
  user:
    type:  # valid: [private_key, token]
    clientCert: # if type==private_key, base64 encoded client cert
    privateKey: # if type==private_key, base64 encoded private key
    token: # plaintext service account token

As an alternative, or a way to override the setting in the configuration file on the command line, you can pass a few flags to set new values.

Here, <cmd> is the full oscap command to execute within the container, and the args before the double hyphen '--' are telling REM where to run the command
$ rem kexec -n <namespace> -p <pod> -c <container> -k <kubeconfig-path-override> -- <cmd>

Example (this will use kubeconfig at ~/.kube/config)
$ rem kexec -n default -p anchore-pod -c anchore-container -- oscap xccdf eval --profile standard --result /tmp/result.xml --report /tmp/report.html target.xml 

Note: The double hyphen -- is important because it tells REM that all subsequent flags should be passed to the container command

A full list of the options supported by the rem kexec command can be found by running the command with the -h or --help option i.e.

rem kexec --help

Compliance Tool Installation

Enable the following section in the configuration file.

command:
  .
  ..
    oscap:
      # This boolean flag tells REM whether or not to try to install OpenSCAP into the container (if the command is oscap)
      installEnabled: true
    
      # This boolean flag tells REM whether or not to try to uninstall OpenSCAP from the container
      # (after the oscap command runs and the result/report files get downloaded)
      uninstallEnabled: true

After the installation option has been enabled this will allow the operator to manually install the compliance tool or allow REM to automatically install the missing tool needed to run the compliance check.

note: uninstallEnabled can be set to false if you intend on leaving the tool available.

Running the following will install OpenSCAP but this is not mandatory.

> rem kexec install oscap

Run a compliance check

There are two options on how to run the check. The first is from the command line. The second method is to have REM read it from the configuration file.

From the command line

> rem kexec oscap -- xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --fetch-remote-resources --results /tmp/anchore/result.xml --report /tmp/anchore/report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

From configuration file

command:
  # If no command is specified through arguments passed to the application on the command line, this command will be used
  # Each element of the list is interpreted as part of the command
  # I.E. echo 'hello-world' > /tmp/test.txt would look like:
  #   cmd:
  #     - echo
  #     - 'hello-world' > /tmp/tst.txt
  cmd: oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --fetch-remote-resources --results /tmp/anchore/result.xml --report /tmp/anchore/report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

Once the check has completed the report and results file should be located in the set path passed into openSCAP.

Custom STIG targets

REM has the option to allow the operator to specify a custom target by setting a path under customTargetPath.

# If a custom OSCAP profile is desired, specify it's path here
# Note: this will be placed into a /tmp/anchore/ directory in the container at runtime, so the command being executed
customTargetPath: <local path to target>/custom.xml

Audit uploads

REM has an audit database which is used to track which compliance checks have been successfully run, this also serves as a method to ensure fault tolerance in the case where reports have not been uploaded do to unavailable service connections to Enterprise. REM will mark those uploads as incomplete allowing the operator to issue a flush command and push the remainders to Enterprise.

Database subcommand

To list the current state for all past transactions issue the following command:

> rem db list

In order to retreive detailed information about a transaction use the db get command with the id:

> rem db get 1

To push all results which have been marked as not uploaded, issue the follow command:

note: the –dryrun flag will show you the records which will be processed

> rem db upload

25.6.2 - Tech Preview - V2 Vulnerability Scanner

Tech Preview: V2 Vulnerability Scanner

A new vulnerability scanning engine, based on Grype improves performance, reduces database load, and provides better vulnerability matching results. It includes a new vulnerability feed sync process integrated into the enterprise feed service that also provides faster feed syncs from the feed service to the policy engine.

Tech Preview Status

Note: The v2 scanner is intended for use in sandbox or staging environments in the current release. It is not possible to run both vulnerability scanners at the same time. This configuration is picked up at bootstrap, and cannot be changed on a running system.

1. The new mode must be set at deployment time, the scanner is configured at service startup.
2. Switching modes in a deployment is not supported.
3. Downgrading from the v2 scanner back to the legacy scanner is not supported.
4. Some features of the policy system are not yet supported in this mode:
5. vulnerability gate triggers not supported for the new scanner. They will return incorrect results when used.
   1. vulnerability_data_unavailable
   2. stale_feed_data policy
6. Windows container scanning is not yet supported. Support will be added in the next feature release.
7. Proprietary vulnerability feeds are not yet supported in this scanner. Support will be added in the next feature release.

Running with docker-compose

1. Install or update to Anchore Enterprise 3.1.0
2. Add the following environment variable to the policy engine container section of the docker compose file:

    policy-engine:
      ...
      environment:
      ...
      - ANCHORE_VULNERABILITIES_PROVIDER=grype

3. Redeploy the services.

Running with helm

1. Install or update to Anchore Engine 0.10.0.
2. Update the following value in your values.yaml configuration file. See the chart README for more details on configuring this file:

    anchorePolicyEngine
      ...
      vulnerabilityProvider: grype
    

3. Redeploy the services

    helm upgrade

After making the relevant change above and redeploying, the system will start up with the v2 vulnerability scanner enabled and will sync the latest version of grype db as built by your local feed service. Note that legacy feeds will no longer be synced while the v2 scanner is configured. All vulnerability data and scanning will now come from the ‘grypedb’ feed.

Vulnerability Feed Data and Syncs

The v2 scanner has its own feed sync mechanism that generates a Grype vulnerability DB from your locally installed feed service instead of https://ancho.re as used by Grype itself. This results in a much faster sync process since the DB is packaged as a single database file. It also reduces load on the Engine DB since the scanner matching and syncs do not require large amounts of writes into the Engine DB. The Grype vulnerability DB is built from the same sources as the legacy service, so there is no reduction in scan coverage or vulnerabilities sources supported.

The feed synced by the Grype provider is identified as feed name ‘grypedb’ when using the feed listing API or anchore-cli system feeds list CLI command.

25.7 - Anchore Enterprise Release Notes - Version 3.0.3

Anchore Enterprise 3.0.3

v3.0.3 is a patch release of Anchore Enterprise containing targeted fixes and improvements. No database upgrade is necessary.

Enterprise Service Changes

Fixes

• Better vulnerability listing API call performance
• Fixes regression in 3.0.0+ that made “hints” feature cause analysis errors of images for some package types
• Large image analysis load failures from catalog to policy engine due to connection timeout. Makes timeout configurable.
• Updates internal Syft to 0.15.1 to reduce java package CVE false positives and include CPE permutations that replace hyphens with underscores for better matching
• Adds missing recent ubuntu release vulnerability feeds (20.10, 21.04)
• Fixes Ubuntu feed mappings from name to version via configuration
• Adds new debian releases for vulnerability feeds and makes new ones configurable without software upgrades

Enterprise UI Changes

Fixes

• Adds package path to vulnerability listing table to differentiate findings packages in multiple locations
• Report manager timezone string conversion error
• The CSV report data for an image that is a descendant of a base image would not show the Inherited From Base column header in the output if the dataset contained items that were false
• In the Print Report view for Vulnerabilities in Image Analysis, the appearance of the View Report button was obscuring the values held in the Vulnerability ID column
• The Anchore Service Version (previously, Anchore Engine Version) in the About Anchore Enterprise Client modal will now update dynamically if the services are upgraded in the background

Additional minor bug fixes and enhancements

Upgrading

• Upgrading Anchore

25.8 - Anchore Enterprise Release Notes - Version 3.0.2

Anchore Enterprise 3.0.2

v3.0.2 is a patch release of Anchore Enterprise containing targeted fixes and improvements. No database upgrade is necessary.

A flaw has been discovered in Anchore Enterprise versions 3.0.0 and 3.0.1 that partially effects java software detection and GHSA vulnerability matching. If a container image has java artifacts that are embedded within java artifacts (i.e. jars in jars), AND certain embedded java artifacts have certain forms of malformed metadata, Anchore analysis can fail to report on the top level java artifact and all artifacts embedded within. The fingerprint of this issue is apprent as the SBOM (content) reports from Anchore would show incomplete or missing java packages when compared to the same reports generated from Anchore Enterprise versions prior to 3.0.0. In addition, while Anchore Enterprise uses several vulnerability data feeds when performing matches against java artifacts, another flaw was discovered that prevented Anchore Enterprise from matching java artifacts with records from the GHSA data feed (other feeds, including NVD, Third-party, and OS feeds were still being consulted). The fingerprint for this issue would manifest as missing GHSA matches when compared to results from versions of Anchore Enterprise prior to 3.0.0. Both flaws have been addressed in Anchore Enterprise version 3.0.2.

Enterprise Service Changes

Fixes

• Fixes issue where java artifacts are not being matched against records from GHSA feed - synthesize pom properties contents in syft mapper. See https://github.com/anchore/anchore-engine Issue #950
• Updates syft to 0.14.0 to fix missing java elements from image SBOM, for embedded java artifacts combined with malformed pom.properties metadata. See https://github.com/anchore/syft Issue #349

Enterprise UI Changes

Fixes

• Updates to the security model surrounding the stored data presented in the LDAP mapping management view.
• Within System > Accounts, Role dropdowns are no longer truncated by the boundary of the user management dialog and will now display all entries without needing to scroll the list.
• Various supporting libraries have been updated in order to improve security, performance, and also to remove deprecation warnings from browser and server output logs. Redundant libraries have been removed to reduce the app startup time and overall size.

Upgrading

• Upgrading Anchore

25.9 - Anchore Enterprise Release Notes - Version 3.0.1

Anchore Enterprise 3.0.1

v3.0.1 is a patch release of Anchore Enterprise containing targeted fixes and improvements. No database upgrade is necessary.

Enterprise Service Changes

Adds

• Adds new “inventory-agent” RBAC role with minimal permissions for use with KAI agents deployed in kubernetes clusters
• Adds wildcard support for GraphQL query filters in reporting service

Fixes

• Increases the TTL for kubernetes runtime inventory items to 120 days from 1 day after last being seen
• Fixes RHEL/UBI images imported to engine using syft have different distro name that skips OS vuln checks by mapping them to the proper “rhel” namespace and adding support for “redhat” namespaces.
• Fixes false positive vulnerabilities due to application packages (npm, python, etc) being installed via rpms, debs, or other distro packages. Filters those “owned” packages from analysis leaving the parent rpm/deb/apk for vulnerability matching.
• Fixes SSO login not working after upgrade from 2.4.x to 3.0.0 with “invalid_client” error
• Fixes analysis failures due to python package manifest format issues causing Syft errors
• Fixes image ancestor lookup failures due to ancestor being deleted or not found
• Fixes ubuntu feed driver failures during data fetch processing

Enterprise UI Changes

Fixes

• Fixes bulk delete image count limitations during repo cleanup
• Fixes potential SSO issues due to Redis connection errors
• Fixes potential LDAP connection update failures

Additional minor bug fixes and enhancements

Upgrading

• Upgrading Anchore

25.10 - Anchore Enterprise Release Notes - Version 3.0.0

Anchore Enterprise 3.0

This represents a significant update in Enterprise, requiring database upgrades and adds new components to the system including an optional deployable agent for gathering runtime image inventory from Kubernetes clusters.

New Features

Runtime Kubernetes Inventory

Anchore now can receive inventory reports from a new agent that runs in the kubernetes cluster and reports which images are used in which namespaces. The new agent is KAI, and it can run within your Anchore deployment or in another kubernetes cluster to return which images are in-use over time. This allows Anchore to show which images are in use and facilitates focused triage and attention on in-use images to ensure you are addressing security findings in this most critical images first.

See Runtime Kubernetes Inventory for more information.

Action Plans and Remediation Recommendations

Anchore now provides fix suggestions for policy violations and a notification delivery mechanism so you can quickly and conveniently send notifications (email, Slack, MS Teams, Github, Jira, etc) to the image maintainer so they can take corrective action for policy findings such as updating packages, modifying the Dockerfile, or rebuilding on a new base image.

See Remediation recommendations for more information.

Policy Violation Alerts

The UI and API now present stateful alerts that will be raised for policy violations on tags to which you are subscribed for alerts. This raises a clear notification in the UI to help initiate the remediation workflow and address the violations via the remediation feature. Once all findings are addressed the alert is closed, allowing an efficient workflow for users to bring their image’s into compliance with their policy.

Improved Pipeline Scanning Integration

Anchore now has the ability to accept SBoM and image metadata from analysis run inside your CI/CD pipelines or local to developer machines and load it into the system for processing without requiring images to be pushed to an image registry. This enables more efficient scanning inside the pipelines and less data transfer to decrease the overall time to result. Analysis results are provided by Syft which is integrated into Anchore itself for SBoM generation of packages as well.

See Pipeline and Local Analysis for more information.

Feature Enhancements and Improvements

Configurable Image Maximum Allowed Size Limit

A new configurable maximum image size has been added to the system to enable administrators to ensure that very large images are not admitted into Anchore causing potential QoS or resource usage issues.

See Configuring Maximum Allowed Image Size

Enhanced Analysis Archive Rule Flexibility

New capabilities in the analysis archive rules allow more efficient description of what to archive and what to exclude as well as the ability to set rules to limit the number of images in each account to help with capacity management. These new capabilities include new selectors for exclusions to rules so that broader rules can be use to select candidates for archival and just exclusions set for specific images, tags, or repos.

See [Analysis Archive Rules]

Enterprise Service Changes

In Enterprise 3.0, the system now requires the deployment configuration to explicitly set a default admin password and will fail system initialization if one is not found in the configuration. This is automatically configured for users of the helm chart and our Quickstart docker-compose.yaml, but if you have a custom deployment template and create a new deployment of Anchore, you must ensure that the default_admin_password field is set in the config.yaml used by the catalog component.

Added

• Adds ability to block large images based on configurable max size
• Adds configurable image max size value to optionally limit size of images analyzed by system
• Adds corrections API to support artifact metadata corrections for false positive management
• Adds kubernetes inventory ingress API and agent to run in kubernetes clusters to track image inventory
• Adds additional archive analysis rule exclusions to allow rules to be broader but have specific exclusions so that fewer rules can be used
• Adds API to upload analysis SBoM generated by Syft and imported as image for remote analysis without Anchore retrieving the image content directly
• Adds CPEs used for vulnerability matching against NVD and VulnDB data to the image content output itself for greater transparency in matching
• Use Python 3.8 instead of Python 3.6
• Update base image for containers to UBI 8.3 from UBI 8.2

Improved

• Improved - Updated output messages and description for vulnerability_data_unavailable trigger and stale_feeds_data trigger to clarify only OS packages impacted.
• Improved - Do not allow selectors to be empty unless using max_images_per_account_rule.
• Improved - Updates Syft to version 0.12.4 to fix several issues in image analysis including empty package names/versions in invalid package.json files and java jar parent references being Nil.
• Improved - Require user to set explicit default admin password at bootstrap instead of defaulting to a value if none found.
• Improved - Update Authlib to 0.15.2 from 0.12.1
• Improved - Update PyYAML to 5.4.1
• Improved - Update Passlib to 1.7.4
• Improved - Update to use Python 3.8
• Improved - Update base image to UBI 8.3.

Fixes

• Fixed - Failed analysis due to incorrect manifest mime types due to bug in buildah that caused incorrect content type to be in the manifest at build time.
• Fixed - External API service swagger spec for GetRegistry response is inconsistent with actual returned JSON.
• Fixed - Fixed analysis archive rules that did not fire if delete transition rule present.
• Fixed - Force re-analysis of tag and digest rejected if create_at_override timestamp not provided.

Additional minor bug fixes and enhancements

Known Issues/Errata

1. False Positive Management feature incompatible with legacy Engine report/query routes Using the GET /query/images_by_vulnerability endpoint for querying all images with a specific vulnerability using the legacy Engine API does not support the new False Positives management feature. It is recommended to use the Enterprise Reporting Service GraphQL API to get the same information that does support the corrections.

2. Change to now require an explicitly set default admin password at system bootstrap may cause issues with some deployment templates If your deployment template (chart, docker-compose, etc) does not ensure that the config.yaml for services includes default_admin_password explicitly set to a value, the system will no longer bootstrap with a built-in default. This does not affect our updated helm chart or quickstart docker-compose.yaml files, those have been updated appropriately.

Enterprise UI Changes

Added

• New compliance landing page
• Alerts view in dashboard
• Alerts selection for repositories and tags
• Remedation workflow and Actions Workbench
• Kubernetes runtime inventory reports
• “Last Seen” timestamp in image analysis to overlay runtime inventory in analysis view

Improved

Fixes

• Updated dependencies

Additional minor bug fixes and enhancements

Upgrading

• Upgrading Anchore

25.11 - Anchore Enterprise Release Notes - Version 2.4.1

Anchore Enterprise 2.4.1

v2.4.1 is a patch release of Anchore Enterprise containing targeted fixes and improvements. No database upgrade is necessary.

Enterprise Service Changes

Added

• Ability to set pool_recycle and other SQLAlchemy engine parameters via config in db_engine_args section of config.yaml
• Updates image build to support dynamic UID mapping in OpenShift

Fixes

• RedHat CVE normalization in feed service did not ensure only one fix record per vulnerability in all cases
• Orphaned feed service driver tasks left in ‘running’ when the system shuts down are now cleaned up on restart and marked as failed
• Fixes small size limit of data scanned by ClamAV, adds default 4GB max size and configuration options to make it smaller. Errors if image is larger than that (ClamAV does no support larger sizes)
• Report ClamAV malware findings that do not include a file path as ‘unknown’ rather than skipping
• Policy engine should return HTTP 400 with instructive message on invalid bundle upload instead of HTTP 500
• Vulnerability fix version not correct for vulnerabilities with multiple fixes
• NPM and Gem packages not matching GHSA sources properly
• Update urllib3 to 1.25.9 to address CVE-2020-26137 even though Anchore not affected by that issue
• Deactivating or deleting repo subscription does not halt in-progress repository scans and can result in analysis being added after the subscription is removed

Additional minor bug fixes and enhancements

Enterprise UI Changes

Improved

• Only show enabled feeds and groups via system health
• Updates image build to support dynamic UID mapping in OpenShift

Fixes

• Repositories with no watch subscription can cause UI errors during deletion
• Lack of error message in case of creating/updating password with value that is too short to pass validation
• Switching account contexts breaks scheduled query recomposition flow

Additional minor bug fixes and enhancements

Upgrading

• Upgrading Anchore

Built on Anchore Engine v0.8.2: Anchore Enterprise is built on top of the open-source Anchore Engine, which has received new features and updates as well See Anchore Engine Release Notes for information on new features, bug fixes, and improvements in Anchore Engine.

25.12 - Anchore Enterprise Release Notes - Version 2.4.0

Anchore Enterprise 2.4.0

Features & changes of note:

• Malware scanning capabilities
• Image ancestry and comparison of an image’s policy and vulnerability findings with a base image
• New analyzers for binaries not delivered in packages,
• A “content hints” capability in the analyzers so developers or image builders can pass metadata to augmentation analysis results
• UI improvements for scanning and deleting repositories with warnings for very large repositories
• Asynchronous deletion of images
• A new enterprise extension to the external API, available with base route: /v1/enterprise/

Malware Scanning

Anchore Enterprise now integrates ClamAV for optional (disabled by default) malware scanning of image content during the analysis phase and with policy rules to trigger on findings. This is particularly useful for using Engine to validate external images in an image catalog or “golden repo” where you must guard against both vulnerable and malicious code from external sources.

For more information see: Malware Scanning

Image Ancestry and Base Image Comparisons for Vulnerabilities and Policy Findings

Anchore now provides an API and UI enhancements to show an image’s base image as well as any images in its ancestry. Using this information, Anchore can now also show which vulnerabilities and policy findings are inherited from an image’s base. This allows quicker triage, analysis, and remediation of image findings. See Base Images.

New Binary Content Type

A new binary analyzer will check for and inspect binaries that are often installed outside of package managers. This supports a common use-case of language or runtime-specific base images such as Python and Go images where the runtime is installed via an archive and thus no package db entry exists. The analyzer supports specific binaries that it searches and can get metadata for: Go, Python, and BusyBox.

Once detected, these are checked for vulnerabilities, just like regular packages using the NVD and other non-OS vulnerability sources.

Content Hints

A new “hints” feature allows users to pass specific metadata into the analyzers to help identify and augment content that existing analyzers would not have been discovered. This feature is useful if you have libraries statically compiled into another binary or installed outside of a package manager that you want to tell Anchore about so you can get vulnerability matches for and include them in the image’s content manifests. This is accomplished with a specific JSON file present in the image: /anchore_hints.JSON. The entries are merged into the analyzer results to augment their findings for different content types.

For more information, see: Content Hints

Changed Image Deletion Behavior

Image deletion is now an asynchronous operation and the image_status property in the image record now has possible states ‘active’ and ‘deleting’. Deletion of an image by API call will transition the image record to a deleting status as indicated by the image_status property. Images in that state will be deleted by an asynchronous process on a duty cycle. This approach helps manage database load under a high volume of delete operations and also makes the client-perceived response time much lower.

NOTE: Responses for GET /images and GET /summaries/imagetags do not include images in the deleting state by default, though new query parameters allow those images to be returned in those calls if desired (image_status=deleting or image_status=all)

New API Extension for Enterprise

The engine API is updated to version 0.1.15 There is also a new enterprise extension to the API, available at /v1/enterprise/ that has its own version (0.1.0) and has calls specific to the Enterprise edition. These calls include the new base-image comparison and ancestry API calls.

The swagger spec for this is available from the service using the route: /v1/enterprise/swagger.json

Enterprise Service Changes

Added

• Changed image deletion to asynchronous behavior to make API more responsive and throttle db load during image deletes.
• New dry-run mode for repository scan request to return list of tags that would be scanned without scanning or persisting the record.
• Support for a “hints” JSON file in the image. JSON file to pass additional metadata to augment analyzer findings.
• Adds API support for deleting multiple images in a single call.
• Support for malware scanning using ClamAV and new ‘malware’ content type in API and policy gate to trigger on findings as well as scan not run. Disabled by default.
• Support for content type ‘binary’ with analyzers to detect specific binaries: Python, Golang, Busybox not installed by package manager.
• Query parameter filters for GET /images calls to filter by image_status and analysis_status.
• Ability to indicate which vulnerability findings are inherited from the base image.
• Ability to indicate which policy findings are inherited from the base image.
• API call to return the ancestor images (parent and base images) for an image.

Improved

• Change image analysis queue processing behavior to fair share across accounts.
• Removes image_to_get property in GET body of /images route, since body in GET operations is not standard behavior.

Fixes

• Handle scratch images correctly in files gate behavior.
• Add missing fields in swagger JSON spec for GET /query/vulnerabilities.
• Better handling of java packages missing certain metadata in MANIFEST.MF files.

Additional minor bug fixes and enhancements

Enterprise UI Changes

Added

• New image count summaries to Image Analysis pages
• Warning during “Analyze Repo” workflow if repo to be added has a lot of images, allowing users to cancel operation before the analysis is requested to avoid unintentional workload.
• “Whats New” message on initial login and available in the “About Enterprise Client” selection from Account dropdown in top right of screen.
• “Binary” content type in Image Contents tab
• “Golang” content type in Image Contents tab
• “Malware” content type in Image Contents tab
• Ability to cancel all pending analyses from a single repository
• Download for report preview data as JSON and CSV
• Show image’s base image in Image Overview page
• Shows which vulnerabilities are inherited from the base image in the Vulnerabilities view
• Shows which policy findings are inherited from the base image in the Compliance view
• Images can be deleted via the UI
• Repository deletion (deletes all image analyses for that repository)

Improved

• Order accounts by name in Associate Accounts pop-up
• Analysis status is its own column to allow sorting by analysis status in repository view of tags
• Adds total image counts to repository view, main page, and tag listing
• Improved error handling in GraphQL responses for Reports
• Custom control for relative time filters in reporting

Fixes

• Some table cell truncations for image digests and other fields in the Image Analysis tab
• Changelog showing entries when no change is apparent
• Re-analysis of images that failed analysis
• Version mismatch after container restart
• Results shown after whitelisting an item with an inactive bundle

Additional minor bug fixes and enhancements

Upgrading

• Upgrading Anchore

Built on Anchore Engine v0.8.1: Anchore Enterprise is built on top of the open-source Anchore Engine, which has received new features and updates as well See Anchore Engine Release Notes for information on new features, bug fixes, and improvements in Anchore Engine.

25.13 - Anchore Enterprise Release Notes - Version 2.3.2

Anchore Enterprise 2.3.2

Adds features as well as bug fixes and improvements. Highlighted features are: new parameters in the Reporting service’s GraphQL API for specifying time ranges using a relative window (e.g last 30 days), and a new CVE blacklisting rule in the policy language to trigger if specific CVEs are found.

Improved

• Improved - Adds retry wrapper on image download operations on analyzer. Implements #483
• Improved - Updates serialize-javascript dependency to 4.0.0 to bring in fix for CVE-2020-7660 (Anchore unaffected)
• Improved - Adds HEALTHCHECK to UI image
• Improved - Removes npm installation from UI image to remove all the unused artifacts it brings in

Bug Fixes

• Fix - Adds release to version string for all os package types if one is present. Fixes #504
• Fix - Fixes global analysis archive rule application for non-admin accounts. Fixes #503
• Fix - Fixes LDAP service tab fails if account mappings cannot be retrieved from service API
• Fix - Fixes multiple vulnerability fix records from RHEL driver by collapsing to a single fix for correct semantics
• Fix - Updates Alpine SecDB driver to use new source (https://secdb.alpinelinux.org) for data and new download process. Adds Alpine 3.12 support
• Fix - Some db tables not created correctly for certain upgrade paths

Additional minor bug fixes and enhancements

• Built on Anchore Engine v0.7.3: Anchore Enterprise is built on top of the OSS Anchore Engine, which has received new features and updates as well See Anchore Engine Release Notes for information on new features, bug fixes, and improvements in Anchore Engine

Upgrading from Anchore Enterprise 2.3.1

• Upgrading Anchore

25.14 - Anchore Enterprise Release Notes - Version 2.3.1

Anchore Enterprise 2.3.1

Adds features as well as bug fixes and improvements. Highlighted features are: new parameters in the Reporting service’s GraphQL API for specifying time ranges using a relative window (e.g last 30 days), and a new CVE blacklisting rule in the policy language to trigger if specific CVEs are found.

Added

• Added - New reporting GraphQL parameters for relative time-windows on reports (e.g. last 30 days) as alternative to absolute date ranges for all queries with start/end parameters.
• Added - CVE Blacklisting via new policy rule.
• Added - New “licenses” field in API response for content (pkgs etc) that is an array type for easier parsing. Supplements existing “license” field that is a comma-delimited list in a single string.
• Added - Configuration option to disable Repository Add feature in UI
• Added - Support for custom links/content on UI login page

Improved

• Improved - Update base docker image to UBI 8.2 from 8.1.
• Improved - Faster rhel feed driver execution via parallelized data download
• Improved - Renamed “Registries” to “Registry Credentials” for more clarity in UI
• Improved - Ask user if they are sure they want to add a full repository of tags in UI to prevent accidental add of large numbers of tags in UI
• Improved - Alphabetical ordering of account data in context list in UI
• Improved - Ability to copy and paste full tag string in image analysis page in UI
• Improved - Enable vulnerabilities tab even if image has no vulnerabilities in UI

Bug Fixes

• Fix - Ability to whitelist VulnDB IDs in policy editor in UI
• Fix - PDF generation from vulnerabilities fix to not be truncated in UI
• Fix - Protect against LDAP service tab whitescreen based on service response in UI
• Fix - Fixes previewing saved query with invalid filter value shows nothing in UI
• Fix - Fix formatting error on compliance report in UI
• Fix - Filter entry persists between tabs in UI
• Fix - Fixes error viewing vulnerabilities for .NET Core images
• Fix - Fixes payload handling for MS Teams integration for notifications.
• Fix - Fixes rhel feeds driver to handle updates in upstream data properly
• Fix - package_type parameter now handles GHSA matches correctly as non-os types.
• Fix - Correctly finds java content in cases where file permissions prevent a read.
• Fix - Updates pyyaml dependency to 5.3.1.
• Fix - Updates several npm dependencies of the UI.
• Fix - Fixes API documentation in swagger spec for registry digest-style POST /image call.
• Fix - Fixes db upgrade failure during upgrades of deployments that still have the ’nvd’ data from the deprecated driver.
• Additional minor bug fixes and enhancements

• Built on Anchore Engine v0.7.2: Anchore Enterprise is built on top of the OSS Anchore Engine, which has received new features and updates as well See Anchore Engine Release Notes for information on new features, bug fixes, and improvements in Anchore Engine

Upgrading from Anchore Enterprise 2.3.0

• Upgrading Anchore

25.15 - Anchore Enterprise Release Notes - Version 2.3.0

This release focuses on enabling the Microsoft ecosystem within Anchore to allow the same analysis flow and pipelines that you use for linux images to be applied to Windows images as well for a consistent approach across ecosystems. It also includes several enhancements to the reporting and event management features of the UI.

New Features

• Windows Container Image Support

  • Analyze and get vulnerabilities for Windows OS-based containers. Anchore ingresses Microsoft vulnerability data via the MSRC
  • No requirement to run Anchore itself on windows or other changes to the infrastructure needed to deliver this feature

• NuGet/.NET Package Support (Tech Preview)

  • Detection and inclusion in analysis output as well as vulnerability scans

• GitHub Advisories vulnerability data

  • See Configuring GitHub advisories for information on configuring the new feed including creating a GitHub token the driver can use for API calls to GitHub.

• Scheduled Reports

  • Create report templates for easy re-use of your most frequently used reports
  • Schedule reports for generation and get notifications when they are ready, delivered via Slack, email, webhooks, and the other supported notification integrations Enterprise provides.

• Event Management in the UI

  • Improved sorting, filtering, and deletion of events in the UI directly

• Improved RHEL/CentOS vulnerability matching using CVE-based feeds instead of RHSA-based data

  • To help provide early detection of vulnerabilities before a fix is available or for issues where a fix is not issued, Anchore now uses RedHat’s CVE information instead of RHSA information
  • This also provides improved whitelist consistency between RHEL/Centos and images based on other distros since CVEs are consistent
  • For more details see RHSA-to-CVE Feed Change

• Improved feed data and configuration management via APIs and CLI

  • New APIs and CLI commands allow dynamic configuration of which feeds to sync and the ability to enable/disable and delete feed data without updating configuration files or restarting containers.
  • See CLI Feeds configuration

• Built on Anchore Engine v0.7.1: Anchore Enterprise is built on top of the OSS Anchore Engine, which has received new features and updates in the 0.7 series. See Anchore Engine Release Notes for information on new features, bug fixes, and improvements in Anchore Engine for versions v0.7.0 and v0.7.1.

Changes

Starting in 2.3.0 all services except the UI in an Enterprise deployment must:

• Have the license.yaml available in /license.yaml inside the image. This is currently how the Notifiations, Reports, and RBAC services are run, and is now extended to all services.

• Be started with the anchore-enterprise-manager command instead of anchore-manager. This ensures that enterprise extensions and functionality is properly loaded and available.

• The docker-compose.yaml is no longer built into the image, but is available in the Docker Compose guide via a link to download. The image versions will be set to the release version matching the documentation version.

These changes are all configured by default in the new Docker Compose guide and are also enabled in the updated Helm chart for this release.

As with previous releases, we recommend upgrading with the newest deployment templates rather than just changing the image references in existing templates.

Bug Fixes and Enhancements

• Fixed user deletion and role removal failures
• Uses NVD severity for Debian vulnerabilties when ‘urgency’ field not set in the upstream data
• Updates alpine feed driver to ensure severies are set using newer nvd2 driver data instead of older nvd driver that may have had stale data due to old NVD XML feed
• Adds new ‘–no-auto-upgrade’ option to anchore-enterprise-manager to start services that will not upgrade the db automatically, enabling more control over the upgrade process
• Fixed Report CSV/JSON download missing records in UI
• Fixed scrollbar functionality issue in Policy Bundle editor in UI
• Fixed missing scrollbar for context switching in UI
• Fixed problem with sorting vulnerability columns in UI causing hangs and missing links
• Updates to dependencies
• Fixes in the Anchore Engine v0.7.0 release notes and v0.7.1 release notes

Upgrading from Anchore Enterprise 2.2 to 2.3.0

This is a significant upgrade. Backups should be taken, and downtime expected to complete the process.

NOTE The upgrade from 2.2.x to 2.3.0 will take several minutes at least for the database schema upgrade and involves a data migration can take longer to fully transition the RHSA data to CVE data. Part of this process is done during the database upgrade, but part of the process can only complete after the upgraded feed service is able to run and sync the new RedHat CVE data. Because of this, there will be an interval where RHEL-based images will have no vulnerabilities listed. That will automatically resolve itself once the feed syncs, and all affected images will have CVE-based vulnerability matches as expected, but depending on deployment environment and number of images in the database, this may take a long time (hours potentially).

See RHSA-to-CVE Feed Change for more information on the change and upgrade implications.

To upgrade, use the new version of the Helm chart or docker-compose provided with this release. The new chart and compose files contain all needed configuration changes. See Enterprise Upgrade to 2.3.0 for details on this specific upgrade process and how to update your own deployment templates if you are not using the official Helm chart.

25.15.1 - RHSA to CVE Feed Changes for RHEL-Based Images

Starting in Enterprise 2.3.0, Anchore Enterprise uses the RedHat Security API for CVEs for vulnerability matches for RHEL, CentOS, and UBI images. This is a change from previous releases that utilized the API for Advisories (RHSAs) instead.

What Changed

In short, rhel:* replaces centos:* in the vulnerability feed for matches against RHEL-based distros such as CentOS and UBI.

Specifically, in Enterprise 2.2.x, all RHEL-based images (CentOS, RHEL, UBI) used data from the RedHat Security Advisories API. This data populated the centos:* groups of the vulnerabilities feed, as seen when you run anchore-cli system feeds list or via the UI’s system page showing feed syncs.

Changed for Enterprise 2.3.0, RHEL-based images will match against a new feed source by default: data from the RedHat CVE API . This new source populates the rhel:* groups of the vulnerabilities feed. The centos:* groups are no longer used for matches by default.

Reason for Change

The CVE source provides the ability to match vulnerabilities that have not yet been fixed upstream or via backports by Redhat as well as information on vulnerabilities that will not be fixed. Both of these classes of vulnerability are not covered in the RHSA data because that data is generated by fix releases. Overall, the change gives better matches earlier in the vulnerability triage and fix process so you can make better decisions about issues that affect your images.

Upgrade

During upgrade Anchore will change the matching logic to transition images to use the new feed groups. This update involves:

Completed Automatically During DB Upgrade:

1. Updating db schema to support new enable/disable flags for feeds and groups.
2. Disabling the existing centos:* feed groups from future syncs by setting the groups to disabled status.
3. Updating the internal mappings for distros to use the new groups.

When the system starts, all RHEL/CentOS/UBI images will still have RHSA matches, but the centos:* groups will be disabled so no new updates arrive for those groups.

After upgrade, when the system is running the new version:

1. Feed service will sync the new data from the source
2. Policy engine syncs from feed service to get new data
3. Once the rhel:* groups sync in the policy engine, all RHEL/CentOS/UBI pre-upgrade analyzed images will now show both CVE and RHSA matches.
4. Images analyzed after the upgrade will only match CVEs.

The output from a CLI feed listing should look roughly like (note the disabled centos groups and synced rhel groups:

anchore@c4799ee0b36e enterprise]$ anchore-cli system feeds list
Feed                   Group                     LastSync                          RecordCount        
...               
vulnerabilities        centos:5(disabled)        2020-05-15T16:33:53.165136        1171               
vulnerabilities        centos:6(disabled)        2020-05-15T16:33:47.819467        1219               
vulnerabilities        centos:7(disabled)        2020-05-15T16:33:48.007930        1044               
vulnerabilities        centos:8(disabled)        2020-05-15T16:33:51.662811        255                
...                
vulnerabilities        rhel:5                    2020-05-15T22:23:56.300077        7237               
vulnerabilities        rhel:6                    2020-05-15T22:23:55.343614        6833               
vulnerabilities        rhel:7                    2020-05-15T22:23:56.040785        5893               
vulnerabilities        rhel:8                    2020-05-15T22:23:56.561123        1472               
...             

You can optionally flush the old RHSA matches by using the anchore-cli to delete the centos group data, which will remove the both the feed data and vulnerability matches for the RHSAs, leaving only the CVE matches.

To accomplish this, via the cli run:

[anchore@c4799ee0b36e enterprise]$ anchore-cli system feeds delete vulnerabilities --group centos:5
Group                     LastSync        RecordCount        
centos:5(disabled)        pending         0                  

[anchore@c4799ee0b36e enterprise]$ anchore-cli system feeds delete vulnerabilities --group centos:6
Group                     LastSync        RecordCount        
centos:6(disabled)        pending         0                  

[anchore@c4799ee0b36e enterprise]$ anchore-cli system feeds delete vulnerabilities --group centos:7
Group                     LastSync        RecordCount        
centos:7(disabled)        pending         0                  

[anchore@c4799ee0b36e enterprise]$ anchore-cli system feeds delete vulnerabilities --group centos:8
Group                     LastSync        RecordCount        
centos:8(disabled)        pending         0                  

Listing will now show:

anchore@c4799ee0b36e enterprise]$ anchore-cli system feeds list
Feed                   Group                     LastSync                          RecordCount        
...                
vulnerabilities        centos:5(disabled)        -                                 0                  
vulnerabilities        centos:6(disabled)        -                                 0                  
vulnerabilities        centos:7(disabled)        -                                 0                  
vulnerabilities        centos:8(disabled)        -                                 0                  
...                
vulnerabilities        rhel:5                    2020-05-15T23:45:04.969330        7237               
vulnerabilities        rhel:6                    2020-05-15T23:45:03.552281        6833               
vulnerabilities        rhel:7                    2020-05-15T23:45:04.678325        5894               
vulnerabilities        rhel:8                    2020-05-15T23:45:05.232375        1473               
...      

At this point all RHSA matches for all images in the DB have also been removed, leaving only the CVE matches from the new RedHat CVE source.

Feed Service Driver Configuration

The new RHEL CVE feed is enabled in the feed service by default. No changes to configuration are necessary to enable it.

Policy Engine Configuration

No changes to the policy engine configuration are needed to enable the new data because it is delivered as new groups in the existing vulnerabilities feed, which syncs all groups automatically.

Rolling Back

If you need to restore the old behavior see the rollback guide

25.15.2 - Reverting Back to use RHSA Data

NOTE: This section is only for very specific situations where you absolutely must revert the matching system to use the RHSA data. This should not be done lightly. The newer CVE-based data is more accurate, specific, and provides a more consistent experience with other distros.

If your processing of anchore output relies on RHSA keys as vulnerability matches, or you have large RHSA-based whitelists that cannot be converted to CVE-based, then it is possible, though not recommended, to migrate your system back to using the RHSA-based feeds (centos:* groups).

Here is the process. It requires the Anchore CLI with access to the API as well as direct access to the internal policy engine API endpoint. That may require a docker exec or kubectl exec call to achieve and will be deployment/environment specific.

1. Revert the distro mapping records that map centos, fedora, and rhel to use the RHEL vuln data.

   1. With API access to the policy engine directly (output omitted for brevity), remove the existing distro mappings to RHEL data. These are the used by Anchore:

   curl -X DELETE -u admin:foobar http://localhost:8087/v1/distro_mappings?from_distro=centos
   curl -X DELETE -u admin:foobar http://localhost:8087/v1/distro_mappings?from_distro=rhel
   curl -X DELETE -u admin:foobar http://localhost:8087/v1/distro_mappings?from_distro=fedora
   

   1. Continuing with API access to the policy engine directly, replace the removed mappings with new mappings to the centos feeds:

   curl -H "Content-Type: application/json" -X POST -u admin:foobar -d'{"from_distro":"centos", "to_distro":"centos", "flavor":"RHEL"}' http://localhost:8087/v1/distro_mappings
   curl -H "Content-Type: application/json" -X POST -u admin:foobar -d'{"from_distro":"fedora", "to_distro":"centos", "flavor":"RHEL"}' http://localhost:8087/v1/distro_mappings
   curl -H "Content-Type: application/json" -X POST -u admin:foobar -d'{"from_distro":"rhel", "to_distro":"centos", "flavor":"RHEL"}' http://localhost:8087/v1/distro_mappings
   

   Note: if something went wrong and you want to undo the progress you’ve made, just make the same set of calls as the last two steps in the same order but with the to_distro values set to ‘rhel’.

   1. Now, ensure you are back where you have access to the main Anchore API and the Anchore CLI installed. Disable the existing rhel feed groups

   anchore-cli system feeds config vulnerabilities --disable --group rhel:5
   anchore-cli system feeds config vulnerabilities --disable --group rhel:6
   anchore-cli system feeds config vulnerabilities --disable --group rhel:7
   anchore-cli system feeds config vulnerabilities --disable --group rhel:8
   

   anchore-cli system feeds delete vulnerabilities --group rhel:8
   anchore-cli system feeds delete vulnerabilities --group rhel:7
   anchore-cli system feeds delete vulnerabilities --group rhel:6
   anchore-cli system feeds delete vulnerabilities --group rhel:5
   

   1. Enable the centos feed groups that have the RHSA vulnerability data

   anchore-cli system feeds config vulnerabilities --enable --group centos:8
   anchore-cli system feeds config vulnerabilities --enable --group centos:7
   anchore-cli system feeds config vulnerabilities --enable --group centos:6
   anchore-cli system feeds config vulnerabilities --enable --group centos:5
   

   NOTE: if you already have centos data in your feeds (verify with anchore-cli system feeds list) then you’ll need to delete the centos data groups as well to ensure a clean re-syncin the next steps. This is accomplished with:

   anchore-cli system feeds delete vulnerabilities --group centos:5
   anchore-cli system feeds delete vulnerabilities --group centos:6
   anchore-cli system feeds delete vulnerabilities --group centos:7
   anchore-cli system feeds delete vulnerabilities --group centos:8
   

   1. Now do a sync to re-match any images using rhel/centos to the RHSA data

   [root@d64b49fe951c ~]# anchore-cli system feeds sync
   
   WARNING: This operation should not normally need to be performed except when the anchore-engine operator is certain that it is required - the operation will take a long time (hours) to complete, and there may be an impact on anchore-engine performance during the re-sync/flush.
   
   Really perform a manual feed data sync/flush? (y/N)y
   Feed                   Group                  Status         Records Updated        Sync Duration        
   github                 github:composer        success        0                      0.28s                
   github                 github:gem             success        0                      0.34s                
   github                 github:java            success        0                      0.33s                
   github                 github:npm             success        0                      0.23s                
   github                 github:nuget           success        0                      0.23s                
   github                 github:python          success        0                      0.29s                
   nvdv2                  nvdv2:cves             success        0                      60.59s               
   vulnerabilities        alpine:3.10            success        0                      0.27s                
   vulnerabilities        alpine:3.11            success        0                      0.31s                
   vulnerabilities        alpine:3.3             success        0                      0.31s                
   vulnerabilities        alpine:3.4             success        0                      0.25s                
   vulnerabilities        alpine:3.5             success        0                      0.26s                
   vulnerabilities        alpine:3.6             success        0                      0.25s                
   vulnerabilities        alpine:3.7             success        0                      0.26s                
   vulnerabilities        alpine:3.8             success        0                      0.35s                
   vulnerabilities        alpine:3.9             success        0                      0.28s                
   vulnerabilities        amzn:2                 success        0                      0.26s                
   vulnerabilities        centos:7               success        1003                   34.91s               
   vulnerabilities        centos:8               success        199                    9.15s                
   vulnerabilities        debian:10              success        2                      0.50s                
   vulnerabilities        debian:11              success        4                      60.53s               
   vulnerabilities        debian:7               success        0                      0.30s                
   vulnerabilities        debian:8               success        3                      0.34s                
   vulnerabilities        debian:9               success        2                      0.38s                
   vulnerabilities        debian:unstable        success        4                      0.39s                
   vulnerabilities        ol:5                   success        0                      0.31s                
   vulnerabilities        ol:6                   success        0                      0.29s                
   vulnerabilities        ol:7                   success        0                      0.41s                
   vulnerabilities        ol:8                   success        0                      0.28s                
   vulnerabilities        rhel:5                 success        0                      0.28s                
   vulnerabilities        rhel:6                 success        0                      0.43s                
   vulnerabilities        ubuntu:12.04           success        0                      0.45s                
   vulnerabilities        ubuntu:12.10           success        0                      0.25s                
   vulnerabilities        ubuntu:13.04           success        0                      0.24s                
   vulnerabilities        ubuntu:14.04           success        0                      0.37s                
   vulnerabilities        ubuntu:14.10           success        0                      0.25s                
   vulnerabilities        ubuntu:15.04           success        0                      0.42s                
   vulnerabilities        ubuntu:15.10           success        0                      0.23s                
   vulnerabilities        ubuntu:16.04           success        0                      0.35s                
   vulnerabilities        ubuntu:16.10           success        0                      0.33s                
   vulnerabilities        ubuntu:17.04           success        0                      0.33s                
   vulnerabilities        ubuntu:17.10           success        0                      0.31s                
   vulnerabilities        ubuntu:18.04           success        0                      0.42s                
   vulnerabilities        ubuntu:18.10           success        0                      0.37s                
   vulnerabilities        ubuntu:19.04           success        0                      0.45s                
   vulnerabilities        ubuntu:19.10           success        0                      0.32s                
   [root@d64b49fe951c ~]# anchore-cli image vuln centos os
   Vulnerability ID        Package                            Severity        Fix                     CVE Refs              Vulnerability URL                                      Type        Feed Group        Package Path        
   RHSA-2020:0271          libarchive-3.3.2-7.el8             High            0:3.3.2-8.el8_1         CVE-2019-18408        https://access.redhat.com/errata/RHSA-2020:0271        rpm         centos:8          pkgdb               
   RHSA-2020:0273          sqlite-libs-3.26.0-3.el8           High            0:3.26.0-4.el8_1        CVE-2019-13734        https://access.redhat.com/errata/RHSA-2020:0273        rpm         centos:8          pkgdb               
   RHSA-2020:0575          systemd-239-18.el8_1.1             High            0:239-18.el8_1.4                              https://access.redhat.com/errata/RHSA-2020:0575        rpm         centos:8          pkgdb               
   RHSA-2020:0575          systemd-libs-239-18.el8_1.1        High            0:239-18.el8_1.4                              https://access.redhat.com/errata/RHSA-2020:0575        rpm         centos:8          pkgdb               
   RHSA-2020:0575          systemd-pam-239-18.el8_1.1         High            0:239-18.el8_1.4                              https://access.redhat.com/errata/RHSA-2020:0575        rpm         centos:8          pkgdb               
   RHSA-2020:0575          systemd-udev-239-18.el8_1.1        High            0:239-18.el8_1.4                              https://access.redhat.com/errata/RHSA-2020:0575        rpm         centos:8          pkgdb               
   

Note in the last command output that the OS vulnerabilities are again showing ‘RHSA’ matches. The restoration to RHSA-based vuln data is complete.

25.16 - Anchore Enterprise Release Notes - Version 2.2.0

Anchore Enterprise 2.2.0

Building upon the Anchore Enterprise 2.0 release, Anchore Enterprise 2.2 adds major new features and architectural updates that extend integration / deployment options, security insights, and the evaluation power available to all users.

New Features

• Integration with Github, Jira, Slack and Microsoft Teams: Anchore Enterprise Notifications is a new capability offered in version 2.2, bringing the ability to flexibly configure your Enterprise deployment to send proactive system, user, and workload level notification events to a variety of third party systems.

• System Dashboard and Feed Sync Status: New system dashboard in the Enterprise GUI which makes it easier to review the status of your Anchore Enterprise deployment, troubleshoot issues and understand the roles of the various services.

• Harbor Support: Anchore Enterprise 2.2 is fully supported by the latest release of the CNCF’s Harbor project (v1.10++) – an open source container and artifact registry.

• Built on Anchore Engine v0.6: Anchore Enterprise is built on top of the OSS Anchore Engine, which has received new features and updates as well See Anchore Engine Release Notes for information on new features, bug fixes, and improvements in Anchore Engine

Upgrading from Anchore Enterprise 2.1

• Upgrading Anchore

25.17 - Anchore Enterprise Release Notes - Version 2.1.0

Anchore Enterprise 2.1.0

Building upon the Anchore Enterprise 2.0 release, Anchore Enterprise 2.1 adds major new features and architectural updates that extend integration / deployment options, security insights, and the evaluation power available to all users.

New Features

• GUI report enhancements: Leveraging Anchore Enterprise’s reporting service, there is a new set of configurable queries available within the Enterprise GUI Reports control. Users can now generate filtered reports (tabular HTML, JSON, or CSV) that contain image, security, and policy evaluation status for collections of images.

• Single-Sign-On (SSO): Integration support for common SSO providers such as Okta, Keycloak, and other Enterprise IDP systems, in order to simplify, secure, and better control aspects of user management within Anchore Enterprise

• Enhanced authentication methods: SAML / token-based authentication for API and other client integrations

• Enhanced vulnerability data: Inclusion of third party vulnerability data feeds from Risk Based Security (VulnDB) for increased fidelity, accuracy, and live-ness of image vulnerability scanning results, available for all existing and new images analyzed by Anchore Enterprise

• Policy Hub GUI: View, list and import pre-made security, compliance and best-practices policies hosted on the open and publicly available Anchore Policy Hub

• Built on Anchore Engine v0.5: Anchore Enterprise is built on top of the OSS Anchore Engine, which has received new features and updates as well See Anchore Engine Release Notes for information on new features, bug fixes, and improvements in Anchore Engine

Upgrading from Anchore Enterprise 2.0

• Upgrading Anchore

25.18 - Anchore Enterprise Release Notes - Version 2.0.0

Anchore Enterprise 2.0.0

Building on top of the existing Anchore Enterprise 1,2 release, Anchore Enterprise version 2.0 adds major new features and architectural updates. The overarching purpose of the new features and design of the 2.0 version of Anchore Enterprise is to directly address the challenges of continued growth and scale by extending the enterprise integration capabilities of Anchore, establishing an architecture that grows alongside our users’ demanding throughput and scale requirements, and offering even more insight into users’ container image environments through rich new APIs and reporting capabilities, all in addition to the rich set of enforcement capabilities included with Anchore Enterprise’s flexible policy engine.

New Features

• GUI Dashboard: new configurable landing page for users of the Enterprise UI, presenting complex information summaries and metrics time series for deep insight into the collective status of your container image environment.

• Enterprise Reporting Service: entirely new service that runs alongside existing Anchore Enterprise services that exposes the full corpus of container image information available to Anchore Engine via a flexible GraphQL interface

• LDAP Integration: Anchore Enterprise can now be configured to integrate with your organization’s LDAP/AD identity management system, with flexible mappings of LDAP information to Anchore Enterprise’s RBAC account and user subsystem.

• Red Hat Universal Base Image: all Anchore Enterprise container images have been re-platformed atop the recently announced Red Hat Universal Base Image, bringing more enterprise-grade software and support options to users deploying Anchore Enterprise in Red Hat environments.

• Anchore Engine v0.4: Anchore Enterprise is built on top of the OSS Anchore Engine, which has received many new features and updates as well. See Anchore Engine Release Notes for information on new features, bug fixes, and improvements in Anchore Engine

Upgrading from Anchore Enterprise 1.2

If using the trial docker-compose method, or the production Helm chart method of deploying Anchore Enterprise, upgrading from 1.2 to 2.0 follows the normal upgrade procedure for Anchore Enterprise. However, if you are deploying Anchore Enterprise manually or using another orchestration environment, there are new dependencies and considerations to take into account for deploying Enterprise 2.0. Please visit the upgrade section for more information.

• Upgrading Anchore