Chapter 4. Known issues
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 theERR_INCOMPLETE_CHUNKED_ENCODINGerror 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
IncompleteBodyerror when using OpenShift Data Foundation -
Red Hat’s OpenShift Data Foundation does not support compression logic that uses the
aws-sdkRust client. When using OpenShift Data Foundation as an object store for RHTPA, you can get a409response code, along with anIncompleteBodyerror 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_idfield. 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.