Administration Guide
General administration for the Trusted Profile Analyzer service
Abstract
Preface
As an administrator or DevSecOps team member, you can manage software supply chain security by using Red Hat Trusted Profile Analyzer (RHTPA). This guide covers upgrading, importing data, scanning SBOMs, searching for vulnerabilities, and configuring identity providers.
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 enables 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. Upgrade Trusted Profile Analyzer to version 3
Upgrading Red Hat Trusted Profile Analyzer (RHTPA) from version 2.2.x to version 3.0 involves significant database schema changes. Also, the existing Software Bill of Materials (SBOM) documents must be migrated. The migration reprocesses the advisory documents and updates the vulnerability scores.
Ensure a controlled upgrade to minimize disruption, and to protect data integrity by leaving the existing database unmodified. The controlled update procedure consists of the following stages:
- Disabling the importers and switching RHTPA to read only mode
- Creating a clone of the PostgreSQL database
- Migrating the database to the new version
- Upgrading the services to the new version, re-enabling read/write mode in the process
- Re-enabling the importers on the new RHTPA version
Depending on the size of your existing data set, the migration times can vary, from a few minutes to many hours. For example, a large RHTPA deployment, with thousands of SBOM documents, might take 8+ hours to complete. Plan your maintenance window accordingly.
The procedure for the upgrade depends on whether you used the Helm or Operator installation method.
Upgrading an Ansible installation is not supported. However, you can create a clone of the database, remove the Ansible installation, and then use Helm or the Operator for the migration from the old database to install RHTPA 3.0.
2.1. Upgrade a Helm installation of Trusted Profile Analyzer to version 3
If you used Helm to deploy Red Hat Trusted Profile Analyzer (RHTPA), you can use a sequence of helm upgrade commands to make the necessary changes.
Prerequisites
A running RHTPA 2.2.5 service installed using Helm.
ImportantIf you are running an older version of RHTPA, you must first upgrade to version 2.2.5 before proceeding with this procedure.
-
A workstation with the
oc,helm, andpsqlbinaries installed and with the OpenShift Helm chart repository installed.
Procedure
- In the RHTPA dashboard, click Importers. In the list of importers, disable all importers.
On your workstation, open a terminal, and log in to OpenShift:
$ oc login --token=sha256~example --server=https://example.com:6443
NoteYou can find your login token and URL information from the OpenShift web console to use on the command line. To find your login token and URL:
- Log in to the OpenShift web console.
- Click your user name, and click Copy login command.
- Enter your user name and password again, and click Display Token to view the command.
Switch to the project/namespace where RHTPA is installed:
$ oc project trusted-profile-analyzer
Replace
trusted-profile-analyzerwith the namespace in which you installed RHTPA.Get the current RHTPA 2.2.5 image name:
$ oc get deploy -n trusted-profile-analyzer -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'Make note of the current RHTPA 2.2.5 image name and version number for use later on.
Save the existing Helm deployment values:
export helm_release=redhat-trusted-profile-analyzer helm get values "${helm_release}" | grep -v 'USER-SUPPLIED VALUES' > original-values.yamlCreate the
rhtpa-read-only.yamlfile with the following content:readOnly: true modules: migrateDatabase: enabled: false server: image: fullName: <TPA_IMAGE> importer: image: fullName: <TPA_IMAGE> createDatabase: enabled: false createImporters: enabled: falseReplace
<TPA_IMAGE>with the full current RHTPA 2.2.5 image name. These settings freeze the image, preventing thehelm upgradecommand from updating the services to the new version before the migration is complete. They also disable re-creating the database and importers during the migration.Run the following command to apply the changes:
helm upgrade "${helm_release}" openshift-helm-charts/redhat-trusted-profile-analyzer -f original-values.yaml -f rhtpa-read-only.yamlCheck that RHTPA is in read-only mode and rejecting requests.
Verify that RHTPA is in read-only mode:
$ oc exec -n trusted-profile-analyzer deploy/<release-name>-server -- \ curl -s http://localhost:8080/.well-known/trustify | jq '.readOnly'
This command must return a value of
true. RHTPA is now in read-only mode.Verify that RHTPA is rejecting requests:
$ oc exec -n trusted-profile-analyzer deploy/<release-name>-server -- \ curl -s -o /dev/null -w '%{http_code}' -X POST http://localhost:8080/api/v2/advisoryThis command must return a
503code, signifying that incoming requests will be rejected.
Create a clone of the RHTPA PostgreSQL database. This new cloned database is the target for the data migration. Depending on your infrastructure, you can use the tools for your cloud provider to create a replica or else use the
pg_dumpandpg_restorecommands.ImportantThe cloned database must have the same username, password, and database name as the original database. If the credentials differ, update the
postgresql-credentialsandpostgresql-admin-credentialssecrets with the new values before proceeding.Create the
rhtpa-migratedb.yamlfile with the following content:modules: migrateDatabase: enabled: true migrateDatabase: host: <new-db-endpoint>Replace
<new-db-endpoint>with the endpoint URL of your new database clone.With these settings, the migration proceeds on the new database clone, while the RHTPA services continue operating in read-only mode using the original database.
Run the following command to start the database migration process.
helm upgrade --wait --timeout 24h0m0s "${helm_release}" openshift-helm-charts/redhat-trusted-profile-analyzer -f original-values.yaml -f rhtpa-read-only.yaml -f rhtpa-migratedb.yamlWarningThe database migration process can take a significant time.
After the migration process completes, create the
rhtpa-swapdb.yamlfile with the following content:readOnly: true database: host: <new-db-endpoint>
Replace
<new-db-endpoint>with the endpoint URL of your new database clone, which is migrated by now.Run the following command to upgrade the services and use the new database endpoint.
helm upgrade --wait --timeout 24h0m0s "${helm_release}" openshift-helm-charts/redhat-trusted-profile-analyzer -f original-values.yaml -f rhtpa-swapdb.yamlThis command does not include the image-freeze settings from
rhtpa-read-only.yaml, so Helm upgrades the services to the new version. ThereadOnly: truesetting inrhtpa-swapdb.yamlkeeps the services in read-only mode until you verify that the upgrade is working correctly.Verify that the upgraded RHTPA services are working correctly with the migrated database:
$ oc exec -n trusted-profile-analyzer deploy/<release-name>-server -- \ curl -s http://localhost:8080/api/v3/sbom?limit=1 | jq '. | has("items")'This command queries the upgraded v3 API and confirms that the server can read from the migrated database.
After verifying that the upgraded services are working, switch RHTPA to read/write mode:
helm upgrade --wait --timeout 24h0m0s "${helm_release}" openshift-helm-charts/redhat-trusted-profile-analyzer -f original-values.yaml -f rhtpa-swapdb.yaml --set readOnly=falseConnect to the new RHTPA PostgreSQL database with the
psqlutility and then run the following optimizations:$ psql -c "VACUUM ANALYZE;" $ psql -c "REINDEX DATABASE CONCURRENTLY \"$PGDATABASE\";"
- In the RHTPA dashboard, click Importers. In the list of importers, enable the importers that you use.
Result
RHTPA is upgraded to version 3.0.
If necessary, you can roll back to RHTPA 2.2.5 by using the older version of the Helm chart and pointing database.host to the original database endpoint, not the new clone.
2.2. Upgrade an Operator installation of Trusted Profile Analyzer to version 3
If you used Operator to deploy Red Hat Trusted Profile Analyzer (RHTPA), you must uninstall the old operator and then install the new one. However, before uninstalling the old operator, you can save a clone of the database. You can then ensure that the new operator migrates the database and uses it.
The RHTPA Operator does not offer a direct upgrade from version 2.2.x to 3.0.0. The stable-v1.1 channel used by version 2.2.x and the stable-v3 channel used by version 3.0 are independent. There is no automated upgrade path between them.
To upgrade, you must uninstall the old Operator and install the new one. You can preserve your existing data by pointing the new deployment at a replica or snapshot of your original database, using the same S3 storage and OIDC configuration in the new CR.
Because the new Operator begins reconciliation automatically on install, you must set readOnly: true and freeze the server and importer images in the CR before installing the new Operator, as described in the steps. This setting ensures the deployment does not start writing to the database before the migration completes.
Prerequisites
A running RHTPA 2.2.5 service installed using the Operator.
ImportantIf you are running an older version of RHTPA, you must first upgrade to version 2.2.5 before proceeding with this procedure.
Procedure
- In the RHTPA dashboard, click Importers. In the list of importers, disable all importers.
Open the RHTPA Operator CR and make the following change:
readOnly: true
Check that RHTPA is in read-only mode and rejecting requests.
Verify that RHTPA is in read-only mode:
$ oc exec -n trusted-profile-analyzer deploy/<release-name>-server -- \ curl -s http://localhost:8080/.well-known/trustify | jq '.readOnly'
This command must return a value of
true. RHTPA is now in read-only mode.Verify that RHTPA is rejecting requests:
$ oc exec -n trusted-profile-analyzer deploy/<release-name>-server -- \ curl -s -o /dev/null -w '%{http_code}' -X POST http://localhost:8080/api/v2/advisoryThis command must return a
503code, signifying that incoming requests will be rejected.
Save the current Operator CR as a backup:
$ oc get trustedprofileanalyzer <release-name> -n trusted-profile-analyzer -o yaml > original-cr.yaml
Replace
<release-name>with the name of your RHTPA deployment.Create a clone of the RHTPA PostgreSQL database. This new cloned database is the target for the data migration. Depending on your infrastructure, you can use the tools for your cloud provider to create a replica or else use the
pg_dumpandpg_restorecommands. The new clone must be outside the RHTPA Operator deployment so that it does not get removed when you remove the Operator deployment.ImportantThe cloned database must have the same username, password, and database name as the original database. If the credentials differ, update the
postgresql-credentialsandpostgresql-admin-credentialssecrets with the new values before proceeding.- Remove the RHTPA 2.2.5 Operator deployment.
Start deploying the RHTPA 3.0 Operator and select the
stable-v3channel, which provides RHTPA 3.0. Before deploying the Operator, make the following changes to the CR:modules: migrateDatabase: enabled: true migrateDatabase: host: <new-db-endpoint> readOnly: true database: host: <new-db-endpoint>Replace
<new-db-endpoint>with the endpoint URL of your new database clone. These settings run the services in read-only mode while the migration completes.After the migration process completes, edit the RHTPA Operator CR and make the following change:
readOnly: false
Connect to the new RHTPA PostgreSQL database with the
psqlutility and then run the following optimizations:$ psql -c "VACUUM ANALYZE;" $ psql -c "REINDEX DATABASE CONCURRENTLY \"$PGDATABASE\";"
- In the RHTPA dashboard, click Importers. In the list of importers, enable the importers that you use.
Verify that the upgraded RHTPA services are working correctly with the migrated database:
$ oc exec -n trusted-profile-analyzer deploy/<release-name>-server -- \ curl -s http://localhost:8080/api/v3/sbom?limit=1 | jq '. | has("items")'
Result
RHTPA is upgraded to version 3.0.
If necessary, you can roll back to RHTPA 2.2.5 by using the Operator version from the stable-v1.1 channel and pointing database.host to the original database endpoint, not the new clone.
Chapter 3. 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.
Additional resources
Chapter 4. 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.
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.
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.
Prerequisites
Install Syft for your workstation platform:
Procedure
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
NoteSyft supports many types of container image sources. For the official supported source list, see Content from github.com is not included.Syft GitHub site for more details.
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 5. 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.
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
- Open a web browser.
- Go to the Trusted Profile Analyzer console URL for your running RHTPA instance.
- Log in to the Trusted Profile Analyzer console with your credentials.
- Click SBOMs from the navigation menu.
- Click the Generate vulnerability report button.
- 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.
- 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 6. Searching for vulnerability, license, and AI Component information
You can use the Red Hat Trusted Profile Analyzer (RHTPA) service to find information about Software Bill of Materials (SBOM) documents, Artificial Intelligence Bill of Materials (AIBOM) 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.
For AIBOM documents, you can search for model names, or for package URLs (PURL).
Prerequisites
- A running RHTPA service hosted on Red Hat Enterprise Linux or Red Hat OpenShift.
Procedure
- Open a web browser, and log in to the RHTPA console.
- From the home page, click Search from the navigational menu.
- In the search field enter your search query.
- 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.
-
For AIBOM documents that appear in the search results, they will have the label of
kind=aibom. By selecting the AIBOM document from the search results, you can view the models associated with it on the Models tab.
Additional resources
Chapter 7. What are CVSS scores
The Common Vulnerability Scoring System (CVSS) is a standard for communicating the severity of software vulnerabilities with a numeric value. There are multiple CVSS specifications that address the needs of security assessments to help users evaluate the potential risk.
Versions 2 and 3 of CVSS are widely supported in most security tools for backwards compatibility.
Version 4 is the latest version of CVSS, and provides a more precise score.
Starting with Red Hat Trusted Profile Analyzer (RHTPA) 3.0, support for CVSS version 4 has been added.
In the RHTPA console, you can see the original CVSS score for Common Vulnerabilities and Exposures (CVE) on the Vulnerabilities page. You can also see a CVSS score breakdown for Software Bill of Materials (SBOM) documents by viewing the SBOM details page.
Chapter 8. Downloading and viewing license information
Red Hat Trusted Profile Analyzer (RHTPA) 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. For more information about the differences between the two license formats for CycloneDX and SPDX, see Additional resources.
Prerequisites
- Installation of RHTPA 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
- Open a web browser, and log in to the RHTPA console.
- From the home page, click Search from the navigational sidebar.
- Find your SBOM from the list.
- Click the options menu icon, and click Download License Export.
-
Extract the license information from the downloaded
.zipfile. Open the comma-separated values (CSV) file to view it.
NoteThe license reference CSV file only applies to SPDX-formatted SBOMs.
Chapter 9. Create and manage SBOM groups
You can create and manage groups for Software Bill of Material (SBOM) documents stored in the Red Hat Trusted Profile Analyzer (RHTPA) service to better organize your SBOMs.
Prerequisites
- A running RHTPA service hosted on Red Hat Enterprise Linux or Red Hat OpenShift.
- Access to the RHTPA console.
Procedure
- Open a web browser, and log in to the RHTPA console.
- From the home page, expand SBOMs from the navigational menu, and click All SBOMs.
- On the All SBOMs page, check the boxes next to the SBOM documents you want to group together, then click the Create group button.
- You must enter a name for your new group in the Group name field.
- Optional. If you have an existing group, you can create a parent-child relationship to this new group by selecting a parent group from the drop-down menu.
- Optional. Expand the Advance section, and you can add labels for the new group.
- Click the Create button to finish creating your new group.
- You can manage your new group under the Groups navigational menu.
Chapter 10. 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 (RHTPA).
Prerequisites
- Installation of the RHTPA service.
- A web browser.
- User credentials to access to the RHTPA console.
Procedure
- From the RHTPA console home page, click either SBOMs or Advisories on the navigation menu.
- 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.
On the Edit labels page, you can add or remove labels.
- To add a new label, start typing the label name in the Label field, and click the Add button.
- To remove a label, look under the Labels of SBOM section, click the X on the label you want to remove.
- When finished editing the labels for SBOMs or advisories, click the Save button.
Chapter 11. 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
- Open a web browser, and log in to the RHTPA console.
- From the home page, click SBOM or Advisories from the navigational menu.
- Find your SBOM or advisory in the list, click the options menu icon, and click Delete.
- A confirmation dialog is given, click the Delete button.
- Verify that the SBOM or advisory is no longer displayed in the list.
Chapter 12. 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.
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
Create an API application registration.
- Go to the Content from portal.azure.com is not included.Azure portal and navigate to Microsoft Entra ID > App registrations > New registration.
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.
- Click Register to create the application registration.
- 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.
Configure the application registration to expose an API.
- In the application registration overview page, navigate to Expose an API.
- Click Add next to Application ID URI, accept the default value, and click Save.
Define the scopes for client requests.
- In the Expose an API section, click Add a scope.
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
- Click Add scope to save the scope.
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
- Click Add scope to save the scope.
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
- Click Add scope to save the scope.
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
- Click Add scope to save the scope.
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
-
Create a client secret for service-to-service authentication.
This is useful for making API calls from backend services or command-line tools.
- Click Certificates & secrets from the navigation menu.
- Click New client secret.
- Add a description, such as CLI Access.
- Select a expiration period appropriate for your environment.
Click Add to create the client secret.
ImportantMake sure to copy the client secret value immediately after creation, as it will not be shown again. You will need this value for authentication.
Configure the token version.
- Click Manifest from the navigation menu.
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.
- Click Save to save the manifest changes.
Add application roles with
scopeMappingsfor admin consent.- Click App roles from the navigation menu.
- Click Create app role.
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
-
Value:
- Click Apply to save each application role.
- Navigate to API permissions > Add a permission > My APIs, and select the API application registration you created earlier.
-
Check the boxes for the
App.Read.Document,App.Create.Document,App.Update.Document, andApp.Delete.Documentapplication roles, and click Add permissions to save. - Click Grant admin consent to grant consent for the application roles you just added.
Create the front-end application registration.
- From the Microsoft Entra ID menu, navigate to App registrations > New registration.
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/.
Click Register to create the application registration.
NoteYour Application (client) ID is also your Frontend Client ID.
Optional. To allow the front-end application to request tokens on behalf of the user.
- In the Expose an API section, click Authorized client applications.
- Click Add a client application.
- Enter the Frontend Client ID.
- Check all the boxes for the scopes you want to allow the front-end application to request on behalf of the user.
- Click Add application to save the authorized client application.
Configure the authentication settings.
- Click Authentication from the navigation menu.
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.
- Click Save to save the authentication settings changes.
Configure the API permissions.
Click API permissions from the navigation menu.
You can keep Microsoft Graph with the
User.Readpermission.- Click Add a permission.
- Click the My APIs tab.
- Select the RHTPA API application registration you created earlier.
- Click Delegated permissions.
- Check all the boxes for the scopes you defined earlier.
- Click Add permissions to save the API permissions.
- 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.
Configure the token version.
- Click Manifest from the navigation menu.
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.
- Click Save to save the manifest changes.
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 beContent from login.microsoftonline.com is not included.https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token.Create a new configuration map for the scope assignments.
- Open a terminal on your workstation.
Create a new
auth.yamlfile:$ touch auth.yaml
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"-
Open the
auth.yamlfile for editing. -
Paste the clipboard contents into the
auth.yamlfile, and replace theTENANT_ID,API_CLIENT_ID, andFRONTEND_CLIENT_IDplaceholders with your values. -
Save and close the
auth.yamlfile - Log in to the OpenShift web console.
- From the navigation menu, expand Workloads, click ConfigMaps.
- Click the Create ConfigMap button.
-
In the Name field, set the value to
server-entra-auth, and leave the Immutable checkbox unchecked. -
In the Key field, set the value to
auth.yaml. - On the Value field, click the Browse… button.
-
Browse to the newly created
auth.yamlfile, and select it. - Click the *Create button.
Open the
values-rhtpa.yamlHelm chart file for editing.Update the
oidcsection 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, andCLIENT_SECRETplaceholders with your values.Also, under the
oidcsection, set theloadUseroption tofalse.Under the
authenticatorsection, add the new configuration map reference as follows:... authenticator: configMapRef: name: server-entra-auth key: auth.yaml ...-
Save and close the
values-rhtpa.yamlHelm chart file.
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
Additional resources
- Content from learn.microsoft.com is not included.Microsoft Entra ID documentation
- Content from learn.microsoft.com is not included.Register an application
- Content from learn.microsoft.com is not included.Expose a web API
- Content from learn.microsoft.com is not included.OAuth 2.0 authorization code flow
- Content from learn.microsoft.com is not included.OAuth 2.0 client credentials flow
Chapter 13. System components
Exploit Intelligence consists of interconnected components that work together to deliver AI-driven vulnerability analysis. Each component has a specific role in the analysis workflow, from accepting analysis requests to orchestrating LLM-based reasoning and delivering actionable reports.
The Exploit Intelligence system follows a distributed architecture where components are deployed as Kubernetes workloads and communicate through REST APIs and event-driven mechanisms.
- Core components, Exploit Intelligence Operator
- Kubernetes operator that provides declarative management of the entire Exploit Intelligence stack through the ExploitIQStack custom resource. Manages lifecycle and synchronization of all components.
- Exploit Intelligence Client
- User-facing component that provides the web UI and handles analysis input. Accepts CycloneDX SBOMs and CVE lists, manages request queuing, displays analysis reports, and stores results in MongoDB. Built with Java (Quarkus) back end and React front end.
- Exploit Intelligence Engine
- Core analysis back end that orchestrates vulnerability analysis by using NVIDIA NeMo Agent Toolkit. Correlates SBOM data with source code context and CVE intelligence, manages LLM prompting, and exposes REST API endpoints. Includes Nginx caching layer for improved performance.
13.1. Exploit Intelligence Engine
Core analysis backend built using NVIDIA NeMo Agent Toolkit. Orchestrates vulnerability analysis by correlating SBOM data with source code context and CVE intelligence.
- Analysis Orchestration
- Receives analysis requests and prompts the LLM
- Caching
- Nginx proxy server caches API requests to reduce duplicates and improve workflow speed
- API
- Exposes endpoints for client consumption
13.2. Exploit Intelligence Client
User-facing web application that provides the Exploit Intelligence dashboard interface and manages analysis requests.
- Technology
- Java (Quarkus) back end + React (Quinoa Quarkus extension) front end
- Request Analysis
- Accepts CycloneDX SBOMs and CVE lists
- Git Snapshots
- Users can manually supply GitHub repository and commit ID
- Reporting
- Displays reports with justification labels, reasoning, and checklists
- Feedback Loop
- Integrates with Argilla for data labeling and model feedback
- Queue Management
- Configurable pool for concurrent requests to avoid overloading engine and LLM
- Persistence
- Stores reports and analysis history in a customer-provided MongoDB database (see database requirements)
- Configuration
- Integrated with Red Hat OpenShift Container Platform OAuth for authentication
13.3. ComponentSyncer
Specialized component for processing product scanning events.
- Technology
- Python
- Workflow
- Triggered by Knative event
- Checks Git commit SHA against stored state in S3
- Clones/Updates repository
- Serializes processed documents to storage
13.4. Exploit Intelligence Operator
Provides declarative management of the stack through ExploitIQStack custom resource.
- Creates and synchronizes Kubernetes resources for entire stack (Engine, Client, Database, Cache, MinIO, Syncer)
- Manages lifecycle of all components
Chapter 14. 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?
- Q: What are the benefits of using Red Hat Trusted Profile Analyzer?
- Q: What telemetry data does Red Hat Trusted Profile Analyzer collect?
- Q: Who should use Red Hat Trusted Profile Analyzer?
- Q: What problems does Trusted Profile Analyzer solve?
- Q: How does Trusted Profile Analyzer help with SBOM management and analysis?
- Q: How does Red Hat use Trusted Profile Analyzer?
- Q: What types of SBOMs can RHTPA analyze?
- Q: What SBOM formats does RHTPA accept?
- Q: How does it integrate into the development workflow?
- Q: What types of deployment are supported?
- Q: Where can you learn more or get started?
What is Red Hat Trusted Profile Analyzer service?
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 This content is not included.Red Hat Hybrid Cloud Console hosts the Trusted Profile Analyzer service. 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.
What are the benefits of using Red Hat Trusted Profile Analyzer?
- 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.
What telemetry data does Red Hat Trusted Profile Analyzer collect?
Trusted Profile Analyzer 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.
Who should use Red Hat Trusted Profile Analyzer?
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.
What problems does Trusted Profile Analyzer solve?
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.
How does Trusted Profile Analyzer help with SBOM management and analysis?
Trusted Profile Analyzer provides storage and management for SBOMs creating a software inventory, allowing organizations to support a 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.
How does Red Hat use Trusted Profile Analyzer?
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.
What types of SBOMs can RHTPA analyze?
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.
What SBOM formats does RHTPA accept?
Trusted Profile Analyzer supports SBOMs formatted in CycloneDX 1.6 or lower, and SPDX 2.3 or lower.
How does it integrate into the development workflow?
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.
What types of deployment are supported?
You can deploy RHTPA on Red Hat Enterprise Linux or Red Hat OpenShift Container Platform. See the RHTPA Deployment Guide for more details.
Where can you learn more or get started?
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.