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

Red Hat Trusted Documentation Team

Abstract

Welcome to Red Hat Trusted Profile Analyzer's official release notes for version 2.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.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.1. 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:

Automated labeling of AIBOMs and CBOMs
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.

Some components are missing from the analysis/latest/component API endpoint response
With this release, the analysis/latest/component API endpoint no longer excludes Software Bill of Materials (SBOM) documents with an ultimate top root of "upstream". By using this endpoint to search for specific packages, you will now receive the expected results. This is because the top root is now the top level product root, ensuring the endpoint returns accurate data. As a result, searching for parts by using the analysis/latest/component API endpoint will return the correct result set, regardless of whether SBOMs reference the "upstream" ancestor.
After deleting a SBOM the dashboard shows errors
Before this update, if an SBOM referenced in user preferences was removed, an unable to connect error occurred, and the corresponding SBOM’s vulnerability doughnut chart was replaced with an alert icon. With this release, the application now proactively handles deleted SBOMs, and the affected part on the dashboard resets to its default state. Users have the option to select a different SBOM to track.
Querying the latest API endpoint omitted ancestors
Before this update, the query system for the latest endpoint had inconsistent implementations between filling the cache and collecting nodes from it. This inconsistency, at times, prevented the return of items that matched the query filter, depending on the cache state. With this release, we have ensured that the implementation between cache filling and node collection is consistent. As a result, all expected nodes will now be retrieved actively.
Missing results returned by API endpoint
Before this update, the analysis/latest/component API calls provided incomplete result sets for components. This led to missing components appearing in the API response. With this release, we fixed the issue with the analysis/latest/component API, ensuring that for every component returned by the analysis/component endpoint, a single and latest version is now returned by the analysis/latest/component API when using the same search criteria. As a result, both endpoints now work consistently, and the analysis/latest/component API’s response includes one version of every component returned by the analysis/component endpoint.
Metrics not matching the correct API calls
In this update, the /recommend and /analyze endpoints were actively registered, causing OpenTelemetry to match /v2/purl/{key} instead of /v2/purl/recommend. Consequently, no requests were actively being reported by OpenTelemetry to the /analyze and /recommend endpoints, but to the /purl/{key} and /vulnerability/{key} endpoints instead. With this release, the /purl/recommend and /vulnerability/analyze endpoints have been proactively moved before the conflicting endpoints. As a result, metrics are now actively reporting for all endpoints.
Improved the handling of circular references in SBOM documents
In this update, a Software Bill of Materials (SBOM) with circular links within their package or component structure will now be actively processed. Before this update, such SBOMs, including their non-circular parts, were passively ignored or missing from the result set. With this release, the system will track visited nodes and halt processing when a node is re-visited, returning all discovered items, but adding a warning field on the re-discovered node. As a result, more SBOMs will actively participate in the processing of the analysis endpoint. Only when an actual loop is encountered will information be actively omitted to prevent an infinite recursion, and a warning will be added.
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. Before this update, vulnerabilities that use the new schema loaded with the following error message: data did not match any variant of untagged enum. With this update, we fixed this bug.
Downloads fail for Zstandard-compressed files uploaded before 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. This incompatibility was fixed by ensuring the output streams are properly shut down after writing all buffered data.
Poor performance when retrieving vulnerabilities for an SBOM
When retrieving large amounts of vulnerabilities for 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 vulnerabilities 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.
Removing orphaned documents
In this update, the document storage no longer lags behind the database, eradicating orphaned documents and thus actively optimizing storage usage. Previously, unnecessary storage was consumed due to the inconsistency between document storage and the database.

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.
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. Consequently, 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.
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.
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 imported 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 is actually a bug. With this release, we removed and deprecated this delete API end point.

Legal Notice
Copy link

Copyright © Red Hat.
Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . 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, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.
The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.
All other trademarks are the property of their respective owners.
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

© 2026 Red HatBack to top