This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

End-of-Life Releases

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.

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.

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

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

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

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

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.

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

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.

The new mode must be set at deployment time, the scanner is configured at service startup.
Switching modes in a deployment is not supported.
Downgrading from the v2 scanner back to the legacy scanner is not supported.
Some features of the policy system are not yet supported in this mode:
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
Windows container scanning is not yet supported. Support will be added in the next feature release.
Proprietary vulnerability feeds are not yet supported in this scanner. Support will be added in the next feature release.

Running with docker-compose

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

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

Redeploy the services.

Running with helm

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

    anchorePolicyEngine
      ...
      vulnerabilityProvider: grype

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.

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

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

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

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

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

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.

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.

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

14 - Anchore Enterprise Release Notes - Version 2.3.1

Anchore Enterprise 2.3.1

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

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.

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:

Updating db schema to support new enable/disable flags for feeds and groups.
Disabling the existing centos:* feed groups from future syncs by setting the groups to disabled status.
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:

Feed service will sync the new data from the source
Policy engine syncs from feed service to get new data
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.
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

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.

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

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

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

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

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

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.

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

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

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