Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Release Notes

Red Hat Trusted Profile Analyzer 2.2

Release notes for Red Hat Trusted Profile Analyzer 2.2

Red Hat Trusted Documentation Team

Abstract

Welcome to Red Hat Trusted Profile Analyzer's official release notes for version 2.2!
The release notes describes new features, enhancements, known issues, bug fixes, and deprecation implemented for the Red Hat Trusted Profile Analyzer 2.2 software release.

Chapter 1. Introduction
Copy link

Red Hat’s Trusted Profile Analyzer (RHTPA) is a proactive service that assists in risk management of Open Source Software (OSS) packages and dependencies. The Trusted Profile Analyzer service brings awareness to and remediation of OSS vulnerabilities discovered within the software supply chain.

The Trusted Profile Analyzer software Release Notes documents new features and enhancements, bug fixes, and known issues for the latest version, 2.2. We add the newest items to the top in each chapter, as we build upon the official release notes over the lifecycle of the major, and minor releases.

New for this release
  • Installing the RHTPA Operator for Red Hat’s OpenShift Container Platform is production ready.
  • The ability to delete Software Bill of Materials (SBOM) documents from RHTPA.
  • The ability to generate SBOM documents from container images stored in Quay.
  • A new API endpoint for fetching package recommendations and remediation.
  • Improved performance for retrieving package data from SBOM documents.

Chapter 2. New features and enhancements
Copy link

A list of all major enhancements, and new features introduced in this release of Red Hat Trusted Profile Analyzer (RHTPA).

The features and enhancements added by this release are:

Support for the CycloneDX 1.6 specification
The Trusted Profile Analyzer service automatically applies labels based on the Software Bill of Materials (SBOM) type, either CycloneDX or SPDX. With this release we introduced two new labels. These labels will be applied when a CycloneDX-formatted SBOM is ingested that contains a specific component type. The presence of a machine-learning-model component results in an aibom label being applied. The presence of a cryptographic-asset component will result in an cbom label being applied.
Improved license search capabilities
In this release, the RHTPA user interface (UI) now showcases software license data prominently, treating it as a primary component. A new License screen presents all unique license expressions from all Software Bill of Materials (SBOM) documents within the application, accompanied by a count of packages and SBOMs that reference each expression. The UI has been enhanced with filters on the SBOM and Package list screens, enabling users to search for license expressions, thereby facilitating management of license compliance within their application portfolio. This update broadens RHTPA’s core functionality to encompass software license management.
Upload functionality has moved in the RHTPA console
The Upload section has been removed from the navigational side bar, and has moved to the SBOMs and Advisories sections. On the SBOMs page, you have a new Upload SBOM button, and on the Advisories page you have a new Upload Advisory button.
New API endpoint for recommendations
In this update, we implemented a new API endpoint for fetching package recommendations. This API endpoint gives remediation of vulnerabilities for the requested packages. The API endpoint accepts a list of package URLs for analysis, and for each package URL, RHTPA tries to find the trusted package version, improving the overall package management process.
The Trusted Profile Analyzer Operator is generally available
With the release of RHTPA 2.2, the Trusted Profile Analyzer Operator for Red Hat OpenShift is no longer a Technical Preview feature, and is generally available (GA). The Trusted Profile Analyzer Operator is ready for production workload.
SBOM document generator for container images stored in Quay
With this update, users can now select a collection of container images from Quay, have them extracted, and generate Software Bill of Materials (SBOM) documents for each container image by using Syft. This feature can be useful for users who need to generate SBOM documents from container images missing an SBOM, and then uploads it to your RHTPA instance. This streamlines the process of SBOM document generation and management.

Chapter 3. Bug fixes
Copy link

In this release of Red Hat Trusted Profile Analyzer (RHTPA), we fixed the following bugs. In addition to these fixes, we list the descriptions of previously known issues found in earlier versions that we fixed.

Poor performance for retrieving packages for an SBOM
When retrieving thousands of packages from a Software Bill of Materials (SBOM) document was causing poor performance, taking several minutes to load the data into RHTPA. With this release, we have optimized the query, resulting in thousands of packages to load in seconds instead of minutes.
The default value for spec.image prevents the RHTPA Operator from upgrading
The default value for spec.image in the custom resource (CR) template contains a hard-coded image version for the RHTPA service container. Any user-created CR configuration that uses this value will not be upgraded automatically, preventing the RHTPA Operator from upgrading. With this release, we removed this value from the CR template. To resolve this issue for existing CRs, you need to remove image key from spec. For example, running the following command patches the CR template: 
$ oc patch rhtpa/trustedprofileanalyzer-sample --type=json -p '[{"op":"remove", "path":"/spec/image"}]'
Copy to Clipboard Toggle word wrap
Improved performance when deleting SBOM documents
In this update, the RHTPA API call that deletes Software Bill of Materials (SBOM) documents, now operates more efficiently by eliminating the Garbage Collector from its execution path. Before this update, the Garbage Collector was triggered with each API call, causing extended completion times for the deletion call. The Garbage Collector tries to identify, and delete all orphaned packages, rather than deleting the packages referenced by a specific SBOM document. For this release, we decoupled the Garbage Collector from the API call doing the SBOM deletion, doing this significantly improving the API’s responsiveness.
The rhtpa-operator-controller-manager pod in a reconciliation loop
In this update, we modified the RHTPA Operator Controller Manager to trigger reconciliation every minute, instead of every second. This change reduces the frequency of operator-generated changes to RHTPA deployments, resulting in fewer events and log entries. This reduction makes manual configuration changes less prone to collisions. Additionally, the increased time window for applying changes is now more conducive to manual adjustments.
Importer pod stays in a pending state
When starting the importer pod, OpenShift does not have a default storage class set for Persistent Volume Claims (PVC). This causes the PVC to go into a pending state. We fixed this issue by adding the modules.importer.storageClassName and storage.storageClassName fields. You can configure these fields before or after deploying RHTPA on Red Hat OpenShift. This allows the PVC to become active as expected.
An error occurs when an image tag expires while importing images from Quay
Changes to container images within the Quay registry during the execution of the RHTPA Quay importer could previously result in images expiring or being deleted, causing Quay importer failures. With this release, we fixed the importer to proactively manage potential image or image tag issues, enabling it to complete without interruption and report issues with individual images in its comprehensive log report.

Chapter 4. Known issues
Copy link

Resolved known issues for this release of Red Hat Trusted Profile Analyzer (RHTPA):

A list of unresolved known issues found in this release:

Running parallel RHTPA instances on the same Red Hat OpenShift cluster is not supported
The RHTPA Operator is using a cluster-scoped service account and role mapping for operating properly. Having multiple running instances of RHTPA can cause reconciliation problems for existing custom resources (CR) in other namespaces, resulting in an unstable environment. Because of this, running parallel RHTPA instances on the same Red Hat OpenShift cluster is not supported by Red Hat.
Bulk SBOM uploads partially fails when handling large number of items
When uploading Software Bill of Materials (SBOMs) in bulk through the RHTPA API, the importer might send a large volume of concurrent requests to the backing S3 or object storage, which can cause errors if the importer is processing a high number of items. To workaround these errors during bulk ingestion, temporarily stop or scale down the importer so that it does not process items in parallel when uploading SBOMS or other importers are running. As a result, all SBOMs are successfully imported into the TPA system.
The first vulnerability score is chosen when a higher score is available
When a vulnerability has multiple advisories, the first Common Vulnerability Scoring System (CVSS) score is chosen instead of the highest score. Currently, there is no workaround for this issue.
Downloads fail for Zstandard-compressed files uploaded prior to RHTPA 2.2
Upgrading to RHTPA 2.2 results in the inability to download existing Software Bill of Materials (SBOM) documents and advisory files that were uploaded with storage compression set to the Zstandard (storage.compression=zstd). This is due to an incompatibility between the older Zstandard (Zstd) compression used in RHTPA 2.1.1 and earlier, and the newer Zstd library introduced in version 2.2. Affected download attempts return the ERR_INCOMPLETE_CHUNKED_ENCODING error message. Currently, there is no workaround available.
CVE importer error for vulnerabilities that use schema 5.2.0
An implementation of a new Common Vulnerabilities and Exposures (CVE) schema, version 5.2.0, was done recently. The CVE list project, along with the Trusted Profile Analyzer’s CVE data importer uses this schema for formatting vulnerability information. Vulnerabilities that use the new schema load with the following error message: data did not match any variant of untagged enum. Currently, there is no workaround for this issue.
Package details missing for SBOM documents containing a machine-learning model
The Software Bill of Materials (SBOM) ingestion process does not discriminate between component types, resulting in machine-learning models being stored as packages. Submitting an SBOM document with a machine-learning model, the relationship between that component and its parent SBOM is not reflected in RHTPA’s data model. This results in the data not displaying properly within RHTPA’s user interface. To workaround this issue, machine-learning model components can be observed on the SBOM Packages screen. The relationship from SBOM to package is visible within the user interface, but the reverse is not.
Cryptographic methods appear as package names
The Software Bill of Materials (SBOM) ingestion process does not discriminate between component types. Uploading an SBOM document containing a cryptographic asset can lead to unusual appearances on the SBOM packages page. The package name field is filled with the cryptographic method name. Currently, there is no workaround for this issue.
License information does not comply with SPDX specification standards
The embedded license information within a package or component of a Software Bill of Materials (SBOM) does not comply with the SPDX specification standards. Because of this issue, RHTPA marks the package URL license details as NOASSERTION. Currently, there is no workaround for this issue.
A custom Quay source with self signed certificate does not import data
When you set a custom Quay source with self signed certificate, the data is not import into RHTPA. This is because the trust anchor for data importers is missing. The workaround for this issue is to mount the Root CA certificate to the importer pod.
An IncompleteBody error when using OpenShift Data Foundation
Red Hat’s OpenShift Data Foundation does not support compression logic that uses the aws-sdk Rust client. When using OpenShift Data Foundation as an object store for RHTPA, you can get a 409 response code, along with an IncompleteBody error message. This issue resides within the OpenShift Data Foundation code base. To workaround this issue, we removed the compression logic capability from RHTPA’s source code when using OpenShift Data Foundation. This workaround results in Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX) documents uploading without errors.
Large number of vulnerabilities reported
The logic that correlates vulnerability data between advisories and large Software Bill of Materials (SBOM) documents can cause pages to load slowly, and display large number of vulnerabilities. Currently, there is no workaround for this issue.
Searching by SBOM version gives inconsistent results
When using Software Bill of Materials (SBOM) version numbers as search criteria, you can get inconsistent results. In some cases, the search engine can find SBOM version numbers that have the version number in the file name or in the document_id field. In other cases, the search engine finds no matching SBOM versions, even with a valid SBOM version number. There is currently no workaround for this issue.
Load balancer can drop an idle connection during large uploads
When uploading large sets of data, for example 350 MB, by using the RHTPA API, a load balancer might drop the connection if it appears idle. In this case, the upload still completes, but the client does not receive a response. To prevent this, split uploads into smaller parts, for example 10-20 MB, to ensure both upload and response succeed.
No support for CPE version 2.3
The Common Platform Enumeration (CPE) specification and Software Bill of Materials (SBOM) formatted with string bindings does not render properly in the RHTPA console, and when exporting license information. There is currently no workaround for this issue.
Trusted Profile Analyzer 2.2 requires Helm version 3.17 or later
To install RHTPA 2.2, you must use Helm version 3.17 or later to deploy the Trusted Profile Analyzer service on the Red Hat OpenShift Container Platform.
No support for CVSS v4 scores
Currently, there is no support for Common Vulnerability Scoring System (CVSS) version 4 scores in RHTPA.
Advisories with an environment or temporal score fails to upload
A Common Security Advisory Framework (CSAF) document with a Common Vulnerability Scoring System (CVSS) vector that has an environment or temporal score can fail when uploading it to RHTPA. Because of this upload failure, you cannot see the advisory within the RHTPA console. Currently, there is no workaround for this issue.

Chapter 5. Deprecated functionality
Copy link

An overview of deprecated functionality in all supported releases up to this release of Red Hat Trusted Profile Analyzer (RHTPA).

Deleting vulnerability information by using the API endpoint has been removed
When ingesting an advisory into RHTPA, the vulnerabilities are also ingested, and deleting advisories also deletes the related vulnerabilities. Using the RHTPA API endpoint to delete vulnerabilities information iss actually a bug. With this release, we removed and deprecated this delete API end point.

Legal Notice
Copy link

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat