Known issues and limitations

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

Staying updated

Check the Release notes regularly to stay informed about enhancements and newly added features.

Important: IBM Concert version 3.0.0 is available only for new on-premises deployments on supported x86-based environments. Upgrade from earlier IBM Concert releases, SaaS deployments, and IBM Power support are not available in this release.

Known issues

Draft comment:
For each Known Issue or Known Limitation, structure the content using: Concept tag → Title → Conbody. Please check the following example:
Draft comment:
Open the concept tag > in title: Concert‑provided workflows cannot be imported from the Workflows UI
Draft comment:
Conbody: In Concert Workflows 2.2.0, Concert‑provided workflows appear in the UI as available for import. However, attempting to import them fails with the error message “No workflows found in the archive.
Draft comment:
As a workaround or to resolve this issue, users must manually download workflows from GitHub and import them.

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

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.

Known limitations

Draft comment:
Title: Concurrent access to multiple Concert instances using the same user ID is not supported
Draft comment:
Conbody: A single user ID cannot access more than one IBM Concert instance at the same time within the same browser session. Signing in to another Concert instance logs you out of the first instance. <you can add a link if required. For more information, see ....>

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

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.

Known limitation: SaaS deployment is not available in version 3.0.0

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.

Known limitation: IBM Power support is not available in version 3.0.0

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

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

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.

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

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.

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

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.

Known limitations for Concert Workflows and FIPS-enabled environments

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

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

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.

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

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.

Auto discovery: Node component scanning

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.