Administration Guide

Red Hat Trusted Profile Analyzer 2

General administration for the Trusted Profile Analyzer service

Red Hat Trusted Documentation Team

Abstract

This Administration Guide gives System Administrators guidance on how to maintain the Trusted Profile Analyzer service running on Red Hat platforms.

Preface

Welcome to the Red Hat Trusted Profile Analyzer (RHTPA) Administration Guide! This guide is intended for administrators and DevSecOps teams responsible for managing software supply chain security using Red Hat Trusted Profile Analyzer.

Chapter 1. Overview of Red Hat Trusted Profile Analyzer

Red Hat Trusted Profile Analyzer (RHTPA) is a product within the Red Hat Trusted Software Supply Chain suite that helps organizations manage their software supply chain security and risk management. It empowers DevSecOps teams to assess risk across custom, third-party, and open source components without slowing development or increasing operational complexity. The Trusted Profile Analyzer service gives you a centralized, unified view of your application’s security profile, also called a Single pane of glass (SPOG) view. The underlying RESTful application programming interfaces (APIs) power this SPOG view and provide the foundation for the RHTPA web console and notification services.

Exhort is the Trusted Profile Analyzer backend endpoint. It receives API requests to retrieve analysis data, including package dependencies and vulnerabilities. The Red Hat Dependency Analytics (RHDA) integrated development environment (IDE) plugin uses this endpoint to generate vulnerability reports within the IDE framework.

The Trusted Profile Analyzer service operates by aggregating, managing, and analyzing the following critical security documentation:

  • Software Bill of Materials (SBOMs): Stores, indexes, and queries SBOMs for all your custom, third-party, and open source software components, creating a shared system of record. It supports formats like CycloneDX and SPDX.
  • Vulnerability Exploitability eXchange (VEX) : A security advisory issued by a software provider for specific vulnerabilities within a product.
  • Common Vulnerabilities and Exposures (CVE) : Indicates a product’s exposure to attacks and malicious activities by giving it a score between 1 to 10, where 1 is the lowest exposure level and 10 is the highest exposure level.

The Trusted Profile Analyzer service can regularly import advisory and vulnerability data, and uses this data to cross-references data from SBOM documents. This helps teams interpret the impact by using metrics, such as the Common Vulnerability Scoring System (CVSS), to guide their remediation efforts.

Chapter 2. Data importers

You can use the Red Hat Trusted Profile Analyzer data importer to fetch advisory, vulnerability, and SBOM data from multiple remote sources for analysis. Then RHTPA uses this data to give you more insights when analyzing your Software Bill of Materials (SBOM) and Common Security Advisory Framework (CSAF) documents.

Available importers

By default, RHTPA comes configured with the following importer sources:

  • Red Hat CSAFs
  • Red Hat SBOMs
  • Common Vulnerabilities and Exposures (CVE) list version 5
  • GitHub advisory database
  • Quay

By default, the Red Hat CSAF, Red Hat SBOM, and Quay data importers are disabled. These importers can run a long time before finishing, but you can enable any of these data importers at anytime. The Quay data importer scans the Quay registry looking for existing SBOMs for RHTPA to analyze.

Scheduling
By default, the set schedule for each importer source to run is 1 day. This means an enabled importer source runs once a day. After a successful initial running of the importer, the next scheduled run is 24 hours from the time the importer job finished.
Computing resources

Computing resources, and setting limitations on those resources in Red Hat OpenShift Container Platform is important to ensure the application runs stable and performs as expected. The default resource request is 1 CPU and 8 GB of RAM, for both the importer and API server deployments. There are no resource limits by default.

You can either reduce the resource requirements, at the cost of stability, or give more resources to the cluster, supporting the workload. Pods can fail to start, or become stuck in a "Pending" state, if computing requirements are not adequate to support the workload.

Chapter 3. Creating a software bill of materials manifest file

Create a Software Bill of Materials (SBOM) manifest file to provide Red Hat Trusted Profile Analyzer (RHTPA) with the package data needed for security analysis. RHTPA can analyze both CycloneDX and Software Package Data Exchange (SPDX) SBOM formats by using the JSON file format. Many open source tools are available to you for creating Software Bill of Materials (SBOM) manifest files from container images, or for your application. For this procedure we are going to use the Syft tool.

Important

Currently, Trusted Profile Analyzer only supports CycloneDX version 1.3, 1.4, 1.5, and 1.6, along with SPDX version 2.2, and 2.3.

Important

The Syft binary is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. See the support scope for Red Hat Technology Preview features for more details.

Procedure

  1. To create an SBOM by using a container image.

    CycloneDX format
    syft IMAGE_PATH -o cyclonedx-json@1.5
    $ syft registry:example.io/hello-world:latest -o cyclonedx-json@1.5
    SPDX format
    syft IMAGE_PATH -o spdx-json@2.3
    $ syft registry:example.io/hello-world:latest -o spdx-json@2.3
    Note

    Syft supports many types of container image sources. See the official supported source list on Content from github.com is not included.Syft’s GitHub site.

  2. To create an SBOM by scanning the local file system.

    CycloneDX format
    syft dir: DIRECTORY_PATH -o cyclonedx-json@1.5
    syft file: FILE_PATH -o cyclonedx-json@1.5
    $ syft dir:. -o cyclonedx-json@1.5
    $ syft file:/example-binary -o cyclonedx-json@1.5
    SPDX format
    syft dir: DIRECTORY_PATH -o spdx-json@2.3
    syft file: FILE_PATH -o spdx-json@2.3
    $ syft dir:. -o spdx-json@2.3
    $ syft file:/example-binary -o spdx-json@2.3

Chapter 4. Scanning a software bill of materials file

You can scan software bill of materials (SBOM) documents by using the Red Hat Trusted Profile Analyzer service on the Hybrid Cloud Console or your own RHTPA instance. The Trusted Profile Analyzer service can analyze a standard SBOM, Artificial Intelligence Bill of Materials (AIBOM) containing language models, and Cryptographic Bill of Materials (CBOM) containing keys, certificates, and libraries.

Important

Red Hat does not retain a copy of your scanned SBOM documents.

Prerequisites

  • An existing CycloneDX 1.3, 1.4, 1.5, 1.6 or Software Package Data Exchange (SPDX) 2.2, 2.3 document files.

Procedure

  1. Open a web browser.
  2. Go to the Trusted Profile Analyzer console URL for your running RHTPA instance.
  3. Log in to the Trusted Profile Analyzer console with your credentials.
  4. Click SBOMs from the navigation menu.
  5. Click the Generate vulnerability report button.
  6. You can drag and drop your SBOM file directly to this page, or click the Browse Files button, then choose the SBOM file you want to scan.
  7. After RHTPA scans the SBOM file, you get a summary of the analysis, and any specific vulnerability information for the packages included in your SBOM file.

Chapter 5. Searching for vulnerability and license information

You can use Red Hat Trusted Profile Analyzer (RHTPA) service to find information about Software Bill of Materials (SBOM) documents, software license expressions, Common Vulnerabilities and Exposures (CVE), and advisories for Red Hat products and software packages.

Trusted Profile Analyzer searches imported data for latest vulnerability details and applies current SPDX specifications to define license expressions within SBOM documents.

Prerequisites

  • A running RHTPA service hosted on Red Hat Enterprise Linux or Red Hat OpenShift.

Procedure

  1. Open a web browser, and log in to the RHTPA console.
  2. From the home page, click Search from the navigational menu.
  3. In the search field enter your search query.
  4. On the search results page, you can view SBOM documents, software packages, vulnerabilities, and advisories related to your search query. You can also filter these results by date range, SBOM format, and license expression.

Chapter 6. Downloading and viewing license information

Red Hat Trusted Profile Analyzer ({acroynm}) can analyze both CycloneDX and Software Package Data Exchange (SPDX) SBOM documents. You can download and view license information from uploaded Software Bill of Materials (SBOM) documents, in CycloneDX or SPDX format. To learn more about the differences between the two licenses formats for CycloneDX and SPDX, see the additional resources section.

Prerequisites

  • Installation of {acroynm} service on Red Hat OpenShift or Red Hat Enterprise Linux.
  • An uploaded CycloneDX 1.3, 1.4, 1.5, and 1.6 or SPDX 2.2, 2.3 document.

Procedure

  1. Open a web browser, and log in to the {acroynm} console.
  2. From the home page, click Search from the navigational sidebar.
  3. Find your SBOM from the list.
  4. Click the options menu icon, and click Download License Export.
  5. Extract the license information from the downloaded .zip file.
  6. Open the comma-separated values (CSV) file to view it.

    Note

    The license reference CSV file only applies to SPDX-formatted SBOMs.

Chapter 7. Editing labels for SBOMs and advisories

Labels can help you organize, and find your SBOM and advisory information quickly. You can manage your custom labels for Software Bill of Materials (SBOM) documents and advisories by editing the SBOM and advisory information within Red Hat Trusted Profile Analyzer ({acroynm}).

Prerequisites

  • Installation of the RHTPA service.
  • A web browser.
  • User credentials to access to the RHTPA console.

Procedure

  1. From the RHTPA console home page, click either SBOMs or Advisories on the navigation menu.
  2. On the row for the SBOM or advisory you want to edit labels for, click the overflow menu at the end of the row, and click Edit labels.
  3. On the Edit labels page, you can add or remove labels.

    1. To add a new label, start typing the label name in the Label field, and click the Add button.
    2. To remove a label, look under the Labels of SBOM section, click the X on the label you want to remove.
  4. When finished editing the labels for SBOMs or advisories, click the Save button.

Chapter 8. Deleting an SBOM document or an advisory

You can delete Software Bill of Material (SBOM) documents and advisories stored in the Red Hat Trusted Profile Analyzer (RHTPA) service. This procedure goes step-by-step on how to delete an SBOM document or advisory using the RHTPA web-based console.

Prerequisites

  • A running RHTPA service hosted on Red Hat Enterprise Linux or Red Hat OpenShift.
  • Access to the RHTPA console.

Procedure

  1. Open a web browser, and log in to the RHTPA console.
  2. From the home page, click SBOM or Advisories from the navigational menu.
  3. Find your SBOM or advisory in the list, click the options menu icon, and click Delete.
  4. A confirmation dialog is given, click the Delete button.
  5. Verify that the SBOM or advisory is no longer displayed in the list.

Chapter 9. Configuring Microsoft Entra ID as an OpenID Connect provider for Trusted Profile Analyzer

You can use Microsoft Entra ID as your OpenID Connect (OIDC) provider for the Red Hat Trusted Profile Analyzer (RHTPA) service. You can decide to configure Microsoft Entra ID during the deployment of RHTPA, or at a later time.

Note

Integrating Microsoft Entra ID into RHTPA requires no subscriptions.

Prerequisites

  • Red Hat OpenShift Container Platform 4.16 or later.
  • Access to the OpenShift web console.
  • A Microsoft Azure account with permissions to create application registrations.
  • A Microsoft Entra ID tenant.

Procedure

  1. Create an API application registration.

    1. Go to the Content from portal.azure.com is not included.Azure portal and navigate to Microsoft Entra ID > App registrations > New registration.
    2. Fill out the following fields for your application registration:

      • Name : Add a descriptive name for your application registration, such as RHTPA API.
      • Supported account types : Choose the appropriate option, Single tenant or Multi-tenant, based on your requirements.
      • Redirect URI : Leave blank, as this is not required for the API.
    3. Click Register to create the application registration.
    4. After the application registration is created, make note of the Application (client) ID and Directory (tenant) ID values from the application overview page. You will need these values later.
  2. Configure the application registration to expose an API.

    1. In the application registration overview page, navigate to Expose an API.
    2. Click Add next to Application ID URI, accept the default value, and click Save.
  3. Define the scopes for client requests.

    1. In the Expose an API section, click Add a scope.
    2. Create a scope for creating documents using the following values:

      • Scope name : create:document
      • Who can consent? : Admins and users
      • Admin consent display name : Create documents in RHTPA
      • Admin consent description : Allows the application to create documents in RHTPA
      • User consent display name : Create documents in RHTPA
      • User consent description : Allows the application to create documents in RHTPA
      • State : Enabled
    3. Click Add scope to save the scope.
    4. Create a scope for reading documents using the following values:

      • Scope name : read:document
      • Who can consent? : Admins and users
      • Admin consent display name : Read documents in RHTPA
      • Admin consent description : Allows the application to read documents in RHTPA
      • User consent display name : Read documents in RHTPA
      • User consent description : Allows the application to read documents in RHTPA
      • State : Enabled
    5. Click Add scope to save the scope.
    6. Create a scope for updating documents using the following values:

      • Scope name : update:document
      • Who can consent? : Admins and users
      • Admin consent display name : Update documents in RHTPA
      • Admin consent description : Allows the application to update documents in RHTPA
      • User consent display name : Update documents in RHTPA
      • User consent description : Allows the application to update documents in RHTPA
      • State : Enabled
    7. Click Add scope to save the scope.
    8. Create a scope for deleting documents using the following values:

      • Scope name : delete:document
      • Who can consent? : Admins and users
      • Admin consent display name : Delete documents in RHTPA
      • Admin consent description : Allows the application to delete documents in RHTPA
      • User consent display name : Delete documents in RHTPA
      • User consent description : Allows the application to delete documents in RHTPA
      • State : Enabled
    9. Click Add scope to save the scope.
    10. Once finished, you should have the following scopes defined for your application registration:

      • api://{API_CLIENT_ID}/create:document
      • api://{API_CLIENT_ID}/read:document
      • api://{API_CLIENT_ID}/update:document
      • api://{API_CLIENT_ID}/delete:document
  4. Create a client secret for service-to-service authentication.

    This is useful for making API calls from backend services or command-line tools.

    1. Click Certificates & secrets from the navigation menu.
    2. Click New client secret.
    3. Add a description, such as CLI Access.
    4. Select a expiration period appropriate for your environment.
    5. Click Add to create the client secret.

      Important

      Make sure to copy the client secret value immediately after creation, as it will not be shown again. You will need this value for authentication.

  5. Configure the token version.

    1. Click Manifest from the navigation menu.
    2. Find the accessTokenAcceptedVersion property in the JSON file, and set change its value from null`to `2:

      "accessTokenAcceptedVersion": 2

      This ensures that tokens are using the v2.0 format.

    3. Click Save to save the manifest changes.
  6. Add application roles with scopeMappings for admin consent.

    1. Click App roles from the navigation menu.
    2. Click Create app role.
    3. Create roles for each permission, as follows:

      • Value: App.Read.Document, Allowed member types: Applications
      • Value: App.Create.Document, Allowed member types: Applications
      • Value: App.Update.Document, Allowed member types: Applications
      • Value: App.Delete.Document, Allowed member types: Applications
    4. Click Apply to save each application role.
    5. Navigate to API permissions > Add a permission > My APIs, and select the API application registration you created earlier.
    6. Check the boxes for the App.Read.Document, App.Create.Document, App.Update.Document, and App.Delete.Document application roles, and click Add permissions to save.
    7. Click Grant admin consent to grant consent for the application roles you just added.
  7. Create the front-end application registration.

    1. From the Microsoft Entra ID menu, navigate to App registrations > New registration.
    2. Fill out the following fields for your application registration:

      • Name : Add a descriptive name for your application registration, such as RHTPA UI.
      • Supported account types : Choose the appropriate option, Single tenant or Multi-tenant, based on your requirements.
      • Redirect URI > Platform : Select Single-page application (SPA).
      • Redirect URI > URI : Enter the URL where your front-end application is hosted, such as Content from rhtpa.apps.example.com is not included.https://rhtpa.apps.example.com/.
    3. Click Register to create the application registration.

      Note

      Your Application (client) ID is also your Frontend Client ID.

  8. Optional. To allow the front-end application to request tokens on behalf of the user.

    1. In the Expose an API section, click Authorized client applications.
    2. Click Add a client application.
    3. Enter the Frontend Client ID.
    4. Check all the boxes for the scopes you want to allow the front-end application to request on behalf of the user.
    5. Click Add application to save the authorized client application.
  9. Configure the authentication settings.

    1. Click Authentication from the navigation menu.
    2. Check the following settings:

      • Redirect URIs : Ensure the correct redirect URIs are listed for your front-end application.
      • Implicit grant and hybrid flows : Do not check the boxes for Access tokens or ID tokens.
      • Advanced settings > Allow public client flows : Set to No.
      • Select Single-page application.
    3. Click Save to save the authentication settings changes.
  10. Configure the API permissions.

    1. Click API permissions from the navigation menu.

      You can keep Microsoft Graph with User.Read permission.

    2. Click Add a permission.
    3. Click the My APIs tab.
    4. Select the RHTPA API application registration you created earlier.
    5. Click Delegated permissions.
    6. Check all the boxes for the scopes you defined earlier.
    7. Click Add permissions to save the API permissions.
    8. Optional. You can also grant admin consent for pre-approving the API permissions to avoid users having to consent individually when they log in for the first time. You can do this by clicking Grant admin consent, and then clicking Yes.
  11. Configure the token version.

    1. Click Manifest from the navigation menu.
    2. Find the accessTokenAcceptedVersion property in the JSON file, and set change its value from null`to `2:

      "accessTokenAcceptedVersion": 2

      This ensures that tokens are using the v2.0 format.

    3. Click Save to save the manifest changes.
  12. You now have the Tenant ID, API Client ID, Frontend Client ID, Client Secret, and Scopes values that you need to add Microsoft Entra ID as your OIDC provider in the RHTPA configuration.

    Your Issuer URL will be in the format, Content from login.microsoftonline.com is not included.https://login.microsoftonline.com/TENANT_ID/v2.0, and the token endpoint will be Content from login.microsoftonline.com is not included.https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token.

  13. Create a new configuration map for the scope assignments.

    1. Open a terminal on your workstation.
    2. Create a new auth.yaml file:

      $ touch auth.yaml
    3. Copy this content to the clipboard:

      authentication:
        clients:
          # Microsoft Entra ID Frontend Client (for user sign-in)
          - clientId: FRONTEND_CLIENT_ID
            issuerUrl: https://login.microsoftonline.com/TENANT_ID/v2.0
            requiredAudience: API_CLIENT_ID
      
            scopeMappings:
              "read:document":
                - "ai"
                - "read.sbom"
                - "read.advisory"
                - "read.importer"
                - "read.metadata"
                - "read.sbomGroup"
                - "read.weakness"
                - "read.systemInformation"
              "create:document":
                - "create.sbom"
                - "create.advisory"
                - "create.importer"
                - "create.metadata"
                - "create.sbomGroup"
                - "create.weakness"
                - "update.sbom"
                - "update.advisory"
                - "update.importer"
                - "update.metadata"
                - "update.sbomGroup"
                - "update.weakness"
                - "upload.dataset"
              "update:document":
                - "update.sbom"
                - "update.advisory"
                - "update.importer"
                - "update.metadata"
                - "update.sbomGroup"
                - "update.weakness"
              "delete:document":
                - "delete.sbom"
                - "delete.advisory"
                - "delete.importer"
                - "delete.metadata"
                - "delete.sbomGroup"
                - "delete.vulnerability"
                - "delete.weakness"
      
          # Microsoft Entra ID CLI/API Client (for client credentials)
          - clientId: API_CLIENT_ID
            issuerUrl: https://login.microsoftonline.com/TENANT_ID/v2.0
            requiredAudience: API_CLIENT_ID
      
            # Extract from 'scope', 'scp', or 'roles' claims
            scopeSelector: "$['scope','scp','roles']"
      
            scopeMappings:
              # App roles from 'roles' claim
              "App.Read.Document":
                - "ai"
                - "read.sbom"
                - "read.advisory"
                - "read.importer"
                - "read.metadata"
                - "read.sbomGroup"
                - "read.weakness"
                - "read.systemInformation"
              "App.Create.Document":
                - "create.sbom"
                - "create.advisory"
                - "create.importer"
                - "create.metadata"
                - "create.sbomGroup"
                - "create.weakness"
                - "update.sbom"
                - "update.advisory"
                - "update.importer"
                - "update.metadata"
                - "update.sbomGroup"
                - "update.weakness"
                - "upload.dataset"
              "App.Update.Document":
                - "update.sbom"
                - "update.advisory"
                - "update.importer"
                - "update.metadata"
                - "update.sbomGroup"
                - "update.weakness"
              "App.Delete.Document":
                - "delete.sbom"
                - "delete.advisory"
                - "delete.importer"
                - "delete.metadata"
                - "delete.sbomGroup"
                - "delete.vulnerability"
                - "delete.weakness"
    4. Open the auth.yaml file for editing.
    5. Paste the clipboard contents into the auth.yaml file, and replace the TENANT_ID, API_CLIENT_ID, and FRONTEND_CLIENT_ID placeholders with your values.
    6. Save and close the auth.yaml file
    7. Log in to the OpenShift web console.
    8. From the navigation menu, expand Workloads, click ConfigMaps.
    9. Click the Create ConfigMap button.
    10. In the Name field, set the value to server-entra-auth, and leave the Immutable checkbox unchecked.
    11. In the Key field, set the value to auth.yaml.
    12. On the Value field, click the Browse…​ button.
    13. Browse to the newly created auth.yaml file, and select it.
    14. Click the *Create button.
  14. Open the values-rhtpa.yaml Helm chart file for editing.

    1. Update the oidc section with the following values:

      ...
      oidc:
        issuerUrl: https://login.microsoftonline.com/TENANT_ID/v2.0
        uiScope: "openid profile email offline_access api://API_CLIENT_ID/create:document api://API_CLIENT_ID/read:document api://API_CLIENT_ID/update:document api://API_CLIENT_ID/delete:document"
        loadUser: false
        clients:
          frontend:
            clientId: FRONTEND_CLIENT_ID
          cli:
            clientId: API_CLIENT_ID
            clientSecret: CLIENT_SECRET
      ...

      Replace the API_CLIENT_ID, FRONTEND_CLIENT_ID, and CLIENT_SECRET placeholders with your values.

      Also, under the oidc section, set the loadUser option to false.

    2. Under the authenticator section, add the new configuration map reference as follows:

      ...
      authenticator:
        configMapRef:
          name: server-entra-auth
          key: auth.yaml
      ...
    3. Save and close the values-rhtpa.yaml Helm chart file.
  15. If you are configuring Microsoft Entra ID during the deployment of RHTPA, continue with the installation procedure.

    If you are configuring Microsoft Entra ID after RHTPA is deployed, you need to upgrade your RHTPA Helm release to apply the new OIDC configuration. You can do this by running the following command:

    $ helm upgrade --install redhat-trusted-profile-analyzer openshift-helm-charts/redhat-trusted-profile-analyzer -n $NAMESPACE --values values-rhtpa.yaml --values values-importers.yaml --set-string appDomain=$APP_DOMAIN_URL

Chapter 10. Frequently asked questions

Do you have questions about Red Hat Trusted Profile Analyzer (RHTPA)? Here is a collection of common questions and their answers to help you understand more about Red Hat’s Trusted Profile Analyzer product and service.

Q:

What is Red Hat Trusted Profile Analyzer service?

A:

Red Hat Trusted Profile Analyzer service provides an application risk profile by analyzing your application’s SBOM for security and vulnerability risks of Open Source Software (OSS) dependencies. The RHTPA service has vulnerability information from CVE aggregators and Red Hat Security Advisories.

The Trusted Profile Analyzer service is a hosted instance on This content is not included.Red Hat’s Hybrid Cloud Console. You can use this service, free of charge, to assess the risk profile of your SBOM by uploading it directly to the service. Red Hat does not keep a copy of your SBOM.

Q:

What are the benefits of using Red Hat Trusted Profile Analyzer?

A:
  • Enhanced transparency throughout the software supply chain.
  • Early detection and remediation of vulnerabilities.
  • Centralized management of SBOMs, VEX, and CVE data.
  • Reduced risk of introducing security flaws into production environments.
  • Improved compliance with industry standards for software security.
Q:

What telemetry data does Red Hat Trusted Profile Analyzer collect?

A:

Trusted Profile Anlyzer collects application telemetry data to help measure performance, and to identify errors with RHTPA. Along with application telemetry, RHTPA collects SRE metrics, and system metrics. For more information about Red Hat’s telemetry data collection, see our This content is not included.notice on the Red Hat Developers website.

Q:

Who should use Red Hat Trusted Profile Analyzer?

A:

Red Hat Trusted Profile Analyzer is ideal for organizations and teams involved in software development, security, and operations (DevSecOps) who need to manage and secure their software supply chain, especially software that uses open source and third-party components.

Q:

What problems does Trusted Profile Analyzer solve?

A:

Red Hat Trusted Profile Analyzer addresses the need for transparency and security in software supply chains by enabling organizations to:

  • Manage SBOMs and vulnerability remediation information efficiently.
  • Stay informed about vulnerabilities in open source software, and proprietary codebases across software inventories.
  • Eliminate vulnerabilities early in the development process.
  • Analyze and expose license information.
  • Ensure regulatory compliance.
Q:

How does Trusted Profile Analyzer help with SBOM management and analysis?

A:

Trusted Profile Analyzer provides storage and management for SBOMs creating a software inventory, allowing organizations to support a comprehensive record of software components from in-house applications, and third party vendors. Trusted Profile Analyzer supports cross-referencing components within an SBOMs with CVEs and Common Security Advisory Framework (CSAF) VEX security advisories, and providing an application risk profile ensuring transparency in the software supply chain.

Q:

How does Red Hat use Trusted Profile Analyzer?

A:

Trusted Profile Analyzer is an important part of Red Hat’s internal software supply chain. It provides Red Hat with a source of truth for SBOM storage, risk profiling, and analysis.

Q:

What types of SBOMs can RHTPA analyze?

A:

Trusted Profile Analyzer can analyze SBOMs created directly from source code, generated during the build process, or generated by the analysis of artifacts, such as containers and packages.

Q:

What SBOM formats does RHTPA accept?

A:

Trusted Profile Analyzer supports SBOMs formatted in CycloneDX 1.6 or lower, and SPDX 2.3 or lower.

Q:

How does it integrate into the development workflow?

A:

Integrating RHTPA into your CI/CD pipeline is as easy as adding a task for SBOM generation, and upload it to the Trusted Profile Analyzer service.

Q:

What types of deployment are supported?

A:

You can deploy RHTPA on Red Hat Enterprise Linux or Red Hat Openshift Container Platform. See the RHTPA Deployment Guide for more details.

Q:

Where can you learn more or get started?

A:

Visit the This content is not included.Red Hat Trusted Profile Analyzer overview page on Red Hat Developers for more information, documentation, and resources to help you get started.

Legal Notice

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.