Known issues and limitations

Edit online

Get a quick overview of the known issues and limitations for IBM® Concert.

Known issues are identified bugs or unexpected behaviors currently under investigation or scheduled for resolution in future updates. These issues are actively tracked by the development team and will be addressed in upcoming releases.

Limitations refer to constraints or currently unsupported capabilities due to design, security, or technical reasons. They are not bugs but rather boundaries of what the platform can currently support.

Being aware of known issues and limitations helps you:
  • Plan effective workarounds for your implementation
  • Avoid spending time troubleshooting known problems
  • Make informed decisions about feature usage
  • Understand the current capabilities and boundaries of the platform

For information about supported deployment models, processor architectures, upgrade paths, and IBM Concert platform compatibility, see Supported deployment models, upgrades, and platform compatibility.

For information about new features, enhancements, and resolved issues, see What's new in IBM Concert.

Known issues

Edit online

SBOMs downloaded from IBM Concert 2.3.x might fail to upload into IBM Concert 3.0.1

Edit online

Application SBOMs that are generated and downloaded from IBM Concert 2.3.x might fail to upload into IBM Concert 3.0.1 because of differences in the supported SBOM format.

Impact
  • Upload of an application SBOM that was generated in IBM Concert 2.3.x can fail.
  • The upload operation displays a validation error, and the SBOM is not imported.

Workaround

Before uploading an application SBOM that was downloaded from IBM Concert 2.3.x, edit the downloaded SBOM as follows:
  • Remove any service entries that do not contain the endpoints field.
  • Remove the corresponding dependency entries for those services.
  • Remove any port field whose value is 0.

Save the modified SBOM and upload it again.

IBM Power offline CVE remediation

Edit online

When using offline advisory files for IBM Power CVE remediation, advisory files may not always contain latest advisories.

Workaround - You are advised to wait for IBM team to update the offline advisory files periodically or use watsonx.ai assisted remeidation.

WebSphere Liberty discovery can fail for non-root users on VM deployments

Edit online

In WebSphere Liberty environments that are deployed on virtual machines (VMs), server registration and discovery can fail when a non-root user account is used.

This issue can occur even when tunneling is configured successfully. In affected environments, Concert cannot establish the required secure communication with the WebSphere Liberty server and registration fails with SSL certificate validation errors, such as:

The server cannot be registered with the IBM WebSphere Automation service. The server was unable to communicate with the service due to incorrect SSL configuration.

Impact

  • WebSphere Liberty server registration fails when using a non-root user account.
  • Vulnerability discovery, assessment, and remediation workflows cannot be performed for the affected server.
  • The failure occurs only in specific VM-based Liberty environments where tunneling is required.

Scope

  • Applies to WebSphere Liberty environments running on virtual machines (VMs).
  • Applies when registration is performed using a non-root user account.
  • Does not affect environments that do not require tunneling.

Workaround

There is currently no supported workaround. Use a root user account for WebSphere Liberty server registration where permitted, or wait for a future release that addresses this limitation.

Auto discovery: Node component scanning

Edit online

When Node component scanning is enabled, Concert scans the Kubernetes node components, such as kubelet and CRI‑O, for vulnerabilities and package information. This is not a full VM scan and does not include operating system–level package assessment.

In Concert Workflows 3.0.1, the Ansible Builder block might return an error if the Python version and path are not specified

Edit online
If you use the Ansible Builder block (which is part of the Ansible® FaaS integration) in a workflow, the following error message might be shown when you run the workflow: 
ERROR - Missing Ansible or Ansible Runner for selected Python

  An Ansible and/or Ansible Runner installation cannot be found in
  the final builder image using the following Python interpreter:

    /usr/bin/python3

Workaround

In the block's Execution Environment field, specify the Python version and path by including the python_interpreter attribute and the package_system and python_path sub-attributes, for example: 
---
version: 3
dependencies:
  python_interpreter:
    package_system: python3.12
    python_path: /usr/bin/python3.12

In Concert Workflows 3.0.1, an error might occur when the admin user logs in for the first time

Edit online

On a newly deployed Concert Workflows 3.0.1 instance, when the default pre-created admin user logs in for the first time, an error might be shown in the UI. This issue does not occur when logging in with other users, and does not recur on subsequent logins for the admin user.

This issue applies to VM-based and OCP-based deployments of Concert Workflows 3.0.1. A fix is planned for a future release.

Workaround

Refresh the page (F5), or log out and log back in.

Known limitations

Edit online

Upgrading from earlier IBM Concert releases to version 3.0.0 is not supported

Edit online

Version 3.0.0 supports new installations only. Direct upgrade from earlier IBM Concert releases is not supported in this release. Existing deployments that are running previous versions must remain on their current release until an upgrade path becomes available in a future release.

SaaS deployment is not available in version 3.0.0

Edit online

IBM Concert version 3.0.0 is available only for on-premises deployments. Deployment as a Software as a Service (SaaS) offering is not supported in this release.

IBM Power support is not available in version 3.0.0

Edit online

IBM Power support is not available in IBM Concert version 3.0.0. Installation on IBM Power (ppc64le) virtual machines is not supported.

Secure Coder workspace scans might not detect vulnerabilities in non-dominant languages

Edit online

When running a Mend SAST workspace scan in Concert Secure Coder, vulnerability detection is based on the dominant programming language in the workspace. In repositories that contain multiple programming languages, files that belong to non-dominant languages might not be fully analyzed during the scan.

Impact

  • Vulnerabilities and security exposures in files that use non-dominant languages might not be detected.
  • Scan results can differ from expectations in mixed-language repositories.
  • Some CVEs and exposure findings might not appear in the Secure Coder scan results even though they exist in the source files.

Scope

  • Applies to Concert Secure Coder workspace scans that use Mend SAST.
  • Affects repositories that contain files from multiple programming languages.
  • Does not affect repositories that primarily contain a single programming language.

Workaround

To ensure that vulnerabilities are detected for a specific language:
  • Place the files that you want to scan in a workspace that primarily contains that language.
  • Open the language-specific workspace in Visual Studio Code or IBM Bob.
  • Run the Mend SAST scan again.

For example, if you want to scan Python files, run the scan from a workspace that primarily contains Python content.

IBM Concert Secure Coder in the browser supports package dependency vulnerability remediation only

Edit online

For IBM Concert version 3.0.0, Secure Coder in the browser supports remediation of package dependency vulnerabilities only.

Impact

  • Browser-based remediation is available only for package dependency vulnerabilities.
  • Remediation of other vulnerability types is not supported in this release.

Scope

Applies to the IBM Concert Secure Coder browser experience.

Applies to both virtual machine (VM) and Red Hat OpenShift Container Platform (OCP) deployments.

Additional considerations

A new remediation session is created each time a user accesses Secure Coder in the browser.

Secure Coder might intermittently fail to update dependency lock files such as package-lock.json. Review generated changes before merging pull requests and update lock files manually if required.

Fixpack installation may fail after applying JDK iFixes in WebSphere 8.5.5 environments

Edit online

In IBM WebSphere Application Server (tWAS) version 8.5.5 environments, installing a JDK iFix before applying a server fixpack can cause the fixpack installation to fail.

Impact

  • Fixpack installation fails after a JDK iFix has been applied.
  • The remediation workflow may not complete successfully and the action status can remain in a failed state.
  • This behavior affects environments where multiple JDK iFixes are installed as part of dependency resolution.

Scope

  • Applies to IBM WebSphere Application Server (tWAS) 8.5.5 environments.
  • Occurs when a JDK iFix is installed before applying a fixpack.
  • Typically observed in environments using IBM Installation Manager for patching.

Cause

When a JDK iFix is installed, it may also resolve or replace other existing JDK iFixes as dependencies. During subsequent fixpack installation, the installer may attempt to uninstall certain JDK fixes internally. If those fixes were not directly installed as standalone Installation Manager packages (but instead introduced as dependencies), the uninstall operation can fail, resulting in fixpack installation failure.

Workaround

There is no Concert-specific workaround.

Follow IBM WebSphere installation guidance for patch sequencing where applicable. In general, avoid applying JDK iFixes before fixpack installation in environments where dependency resolution may impact installation integrity.

Concert Workflows and FIPS-enabled environments

Edit online
  • You can deploy Concert Workflows in VMs and Red Hat OpenShift Container Platform clusters that are are enabled for compliance with the Federal Information Processing Standards (FIPS). However, you cannot deployConcert Workflows in FIPS-enabled Amazon Elastic Kubernetes Cluster (EKS) or Rancher Kubernetes Engine 2 (RKE2) clusters.
  • In Concert Workflows deployments in FIPS-enabled environments, the following capabilities are not supported:
    • The AI workflow assistant.
    • The FaaS workflow integration (including the Python FaaS and Ansible FaaS blocks).
    • The use of external databases (such as MySQL or PostgreSQL) or an AWS S3 bucket for data and object storage.

In Concert Workflows, management of Arista devices that run EOS 4.23 or earlier versions is no longer supported

Edit online

In workflows that use Napalm integration blocks, support for the management of devices that run the Arista EOS operating system is now limited to devices that run Arista EOS 4.24 or later versions. Note that EOS 4.25 and earlier versions are no longer supported by Arista. For more information, see EOS Life Cycle Policy in the Arista support documentation.

In Concert Workflows, integrations that require version updates are not automatically highlighted or updated

Edit online

In the Integrations page, when you click Check for updates, the integrations that require version updates are not automatically highlighted. In addition, when you select one or more integrations, then click the Update option, the selected integrations are not updated to their latest versions.

Workaround

To load a newer version of an integration into your instance, complete these steps:
  1. Connect to IBM Automation Library.
  2. Click Integrations.
  3. Click your chosen integration.
  4. In the integration details page, download your preferred version.
  5. In your Concert Workflows instance, in the Integrations page, import the downloaded integration. For more information, see Integrations.

In 3.0.1, IBM Power-based remote workers that connect to an x86-based Concert Workflows instance cannot execute certain workflow blocks

Edit online
When a remote worker that is installed on an IBM Power (ppc64le)-based host is connected to an x86-based instance of Concert Workflows, the following workflow blocks are not supported and will fail when executed on the remote worker:
  • Common > JSON > jq

Workaround

Avoid using the affected blocks in workflows that run on IBM Power-based remote workers until full cross-architecture compatibility is available.

Auto-discovery failures for private clusters configured with both proxy and custom CA certificate (SaaS)

Edit online
When performing auto-discovery of private ROSA, OpenShift, Kubernetes, or similar clusters in IBM Concert SaaS using:
  • A proxy configuration (HTTP or SOCKS5), and
  • A custom CA certificate,
One or more discovery jobs may intermittently fail during the scanning phase. The failure has been observed in jobs such as:
  • kube_metric_scan
  • kube_misconf_scan
Although the cluster connection is successfully established, the underlying security scanning tool used during discovery (Trivy) may occasionally return a non-zero exit status, causing the associated discovery task to fail.

Workaround

Retry the discovery operation. In most observed cases, rediscovery completes successfully without any changes to the cluster, proxy, or CA certificate configuration.

did not identify cluster accessibility, proxy connectivity, certificate validation, or infrastructure health issues. The behavior appears to originate from intermittent failures in the third-party scanning tool used during discovery and is currently being investigated for future improvements.

Single-cluster auto-discovery boundary

Edit online

The automated resilience and infrastructure discovery mechanism is limited to scanning and pulling components from a single cluster environment per discovery job run.

Workaround

For logical application deployments that naturally span across multiple distinct cluster topologies or virtual machines, you can manually update the deployment's primary deployment SBOM configuration to aggregate and map the cross-cluster component resources into the environment inventory.

Resilience custom rule-based actions treat action subtype values as case-sensitive

Edit online

When you create a custom rule-based action, Concert treats the action_subtype value as case-sensitive. For example, actionand Action are treated as different action subtypes and can result in separate actions.

Impact

Duplicate actions can appear in the Action center when action subtype values differ only by capitalization.

Scope

This limitation applies only to custom rule-based actions.

Workaround

Use consistent capitalization for each action_subtype value when you define custom rule-based actions.

Resilience custom rule-based actions can be generated for requirements that are not at risk

Edit online

Concert generates a custom rule-based action when the configured rule condition is met, even when the associated requirement is not identified as being at risk. In this situation, the View action button is available for the requirement.

Impact

Actions can appear for requirements that are not identified as being at risk.

Scope

This limitation applies only to custom rule-based actions.

Workaround

Review rule conditions before you create a custom rule-based action. Configure conditions that generate actions only for the intended requirement states.

Resilience assessment comparisons are not retained after leaving the Compare assessments page

Edit online

Assessment comparison results are available only while you remain on the Compare assessments page. If you leave the page or refresh the browser, Concert discards the comparison and you must recreate it.

Impact

You cannot reopen or continue a previous assessment comparison after leaving or refreshing the page.

Scope

This limitation applies to comparisons created on the Compare assessments page.

Workaround

Download the comparison as a JSON file before you leave or refresh the page. To continue comparing assessments in the UI, recreate the comparison.

GenAI remediation guidance for Resilience custom libraries depends on content quality

Edit online

The accuracy and confidence of GenAI resilience actions depend on the quality of the requirement and metric descriptions in the custom library. Incomplete, ambiguous, or insufficient descriptions can reduce the relevance of the generated recommendations.

Impact

GenAI recommendations and confidence values might be less accurate or less relevant.

Scope

This limitation applies to GenAI resilience actions that are generated from custom libraries.

Workaround

Provide clear and detailed descriptions for requirements and metrics when you create a custom library. Follow the guidance in Guidelines for configuring custom libraries

Resilience Primary profiles cannot be removed from an application deployment

Edit online

After you designate a resilience profile as the Primary profile for an application deployment, you cannot remove the Primary profile assignment without selecting another profile. You can replace the current Primary profile with another available resilience profile.

Impact

An application deployment must retain a Primary profile after one is assigned.

Scope

This limitation applies to Primary profile assignments for application deployments.

Workaround

Select another resilience profile and designate it as the Primary profile for the application deployment.