VMware Tanzu Application Catalog general FAQs

This section provides answers to general VMware Tanzu Application Catalog (Tanzu Application Catalog) questions.

How do I get started with Tanzu Application Catalog?

Customers can work with the Tanzu Application Catalog sales team to receive an invitation to use the service. These are the typical steps for onboarding and quickly use Tanzu Application Catalog:

Click on the invitation link, provide your VMware ID and select the CSP Organization to connect to the service.
Once the right CSP Org is connected to the service, select “Request a Catalog” within the product. A short guide will walk through the deployment format, operating system and application options.
The onboarding team will then receive the customer’s request and contact them once their catalog is configured and ready to be delivered.

Note
To learn more, see Get Started with VMware Tanzu Application Catalog guide.

For further questions and inquires, contact Tanzu Application Catalog.

How is Tanzu Application Catalog delivered?

Tanzu Application Catalog is delivered via VMware’s Cloud Services Portal (CSP). Once an entitlement to the service is purchased, customers can log-in to CSP with their existing credentials and add the Tanzu Application Catalog tile to their list of CSP services. For more information on CSP, see User Guide.

How does the trial period work?

The Tanzu Application Catalog provides users with a free 90-day trial period. When this period is about to end, users will see the following message when accessing their Tanzu Application Catalog accounts: “Your trial is going to expire”. In that case, contact your VMware sales representative to learn more about how to subscribe to any of the available editions that you can purchase for your team.

What are the types of roles that can be assigned to use Tanzu Application Catalog?

There are two types of roles that can be assigned to use Tanzu Application Catalog:

App Catalog Admin: This role allows a user to manage the catalog and see all the information regarding it. A user with this role can create application requests and manage base images and registries.
App Catalog User: This role allows a user to see data through the catalog but not make any changes to it. They can’t perform application requests or manage registries and base images.

What does an open CVE mean?

Open CVEs are the ones that have not been fixed by the Linux Distribution maintainers because they did not work on that yet or they do not consider a critical issue. The Tanzu Application Catalog team is not able to fix those CVEs since those fixes depend directly on the distribution maintainers.

Tanzu Application Catalog’s images are based on various operating systems, including Debian, Photon, RedHat UBI, and Ubuntu. These CVEs exist in these distributions as well as other distributions which depend on them or use them.

How can I check if a container or chart includes an open CVE?

CVE information is available in the CVE Scan report for each Tanzu Application Catalog container image and virtual machine. To access this, navigate to a catalog, and click the “Details” link of the container image you wish to check. To check CVE information for a Helm chart, check the CVE Scan report for each of its dependent container images.

How can I check if there is a vulnerability in any Bitnami component?

The Tanzu Application Catalog team has launched a public CVE security feed available on GitHub to better enable vulnerability scanners to detect vulnerabilities in the custom-build components included in the Bitnami packages.

Customers that use Trivy as the security scanner to detect vulnerabilities in their containers can check vulnerabilities in Bitnami components. Trivy integrates the Bitnami security feed since version v0.45.0.

The Bitnami CVE security feed is publicly available and it can be consumed by any security scanner that supports the Open Source Vulnerability Database (OSV) schema.

If your security scanner does not support the Bitnami CVE feed, please contact your provider to request its integration. This will enable you to receive Bitnami component analysis in your vulnerability scanner results.

To learn more, see blog post announcement.

Does Tanzu Application Catalog release charts or containers that include fixable CVEs?

Tanzu Application Catalog containers and Helm charts do not include fixable CVEs.

How does Tanzu Application Catalog ensure that its containers and Helm charts do not include fixable CVEs?

To ensure that all Tanzu Application Catalog images include the latest security fixes, Tanzu Application Catalog implements the following policies:

Tanzu Application Catalog triggers a release of a new Helm chart when a new version of the main server or application is detected.

For example, if the system automatically detects a new version of MariaDB, the Tanzu Application Catalog pipeline automatically releases a new container with that version and also releases the corresponding Helm chart if it passes all tests. That way, Tanzu Application Catalog ensures that the application version released is always the latest stable one and has the latest security fixes.
Tanzu Application Catalog triggers a release of a new chart when a package that includes a fix for a CVE from the distribution in any of the containers that it includes is detected.

The system scans all our containers and releases new images daily with the latest available system packages. Once the pipeline detects there is a new package that fixes a CVE, our team triggers the release of a new Helm chart to point to the latest container images.
The Tanzu Application Catalog team monitors different CVE feeds - such as Heartbleed or Shellshock - to fix the most critical issues as soon as possible.

Once a critical issue is detected in any of the charts included in the Tanzu Application Catalog catalog, a new solution is released. Tanzu Application Catalog provide updates in less than 48 business hours.

Does Tanzu Application Catalog support CycloneDX format for viewing SBoM information?

Currently Tanzu Application Catalog supports SPDX format for SBoM but not CycloneDX. However, you can convert the existing SPDX format files to CycloneDX format files using Syft CLI. Once converted, the CycloneDX format files can be imported in Dependency-Track or any other tool to visualize information of that SBoM specific type.

How to convert SPDX file to CycloneDX file and use Dependency-Track to view information of SBoM?

What to do first

Ensure:

Syft is installed.
Dependency-Track is installed.

To convert SPDX file to CycloneDX file using Syft CLI:

Download the SPDX file from Tanzu Application Catalog UI:
- Log in to Tanzu Application Catalog.
- Select your organization.
- From the left navigation pane, go to “Applications” > “My Applications”.
- In the “My Applications” tab, from the list of all applications click the “DETAILS” button corresponding to the container image, Helm chart, or virtual machine, whose SBoM you need.
- In the Build Time Reports section, find and download the SBoM (SPDX) report to your PC. The report is a JSON-formatted file containing multiple sections. It can be read using any text editor or JSON-compatible client library, making it immediately usable in other applications.
- Open the Syft CLI and change to the directory where the SPDX file was downloaded.
- Run the command, for example,
```
syft convert apache.spdx -o cyclonedx-json=apache-cyclonedx.json
```
  The SPDX file is converted to a CycloneDX and will be available in the same folder where the SPDX file was downloaded.

To view SBoM information in Dependency-Track:

Log into Dependency-Track, click “Projects” > “Create Project” and create a new project.
Under “Project Name”, click the newly created project.
Click the “Components” tab.
Click “Upload SBOM” to import the CycloneDX file and view all the software components.
(Optional) Click the “Dependency graph” tab to view which dependencies are related to which software component.
(Optional) Click the “Audit vulnerability” tab to view all the software components which have a known vulnerability.

Note
Converting files from one format to other has a known limitation where specific license IDs could not be identified or linked in Dependency-Track UI.

What are the types of configurations available while adding new applications to your catalog?

There are two configurations available while adding new applications to your catalog:

Basic
Custom

This allows you to have a single private catalog containing both community edition of Bitnami Application Catalog and customized catalogs in your private repository with your Tanzu Application Catalog subscription. This also helps in having an even upgrade experience when moving from Bitnami Application Catalog to Tanzu Application Catalog.

For more information, see Configurations.

How is Tanzu Application Catalog continuously tested to be used in production environments?

Tanzu Application Catalog applications are verified across various combinations of Kubernetes versions, cloud platforms, and base OS distribution versions.

As a result, customers can be confident that the applications included in their catalogs are continuously tested and proven to be suitable for production environments reducing the risk of failure at deployment time.

One form factor, four verifications

Each Tanzu Application Catalog Helm chart distribution is verified in four different Kubernetes versions.

The entire Tanzu Application Catalog is also tested against major cloud platforms covering more than 90% of deployment scenarios. For more information, see Interoperability.

How frequently are Tanzu Application Catalog applications verified?

All container images, Helm charts, and virtual machines available in the catalog are continuously verified to ensure they include the latest dependencies and minimal CVEs.

New versions are only released after they meet specific conditions. This ensures that only relevant updates are delivered to customer registries.

Container images

A new container is triggered so long it fulfils any of the following cases:

A fix for a critical CVE is detected in the OS package
An upstream update in the main component of the container is detected
There are changes in the configuration scripts such as feature improvements or bug fixes
Every 30 days if a new version of the container was not released within that period

Helm charts

A new Helm chart is triggered so long as it fulfills any of the following cases:

A new Helm chart is released in Tanzu Application Catalog
A new feature or fix for an existing application is merged to the catalog
A new version of the main container is triggered fixing a critical CVE
Indirectly when there is an upstream update in the main container
Every 30 days if a new version of the chart was not released within that period

Virtual machines

A new VM is triggered so long it fulfils any of the following cases:

An upstream update in the main component of the VM is detected
A critical security fix is available
Every 30 days if a new version of the application was not released within that period

| NOTE: For additional information about the reasons fir triggering the build, you can download a “Trigger information” report from the applications details page. See Reports.

Are Tanzu Application Catalog multi-arch images verified?

Yes, in addition to the default AMD64 format, certain distributions and applications that also support ARM64 architecture were verified and found to run in major cloud platforms.

How can I check if a Helm chart is configured correctly to meet specific security requirements?

Customers can check if the Helm charts available in Tanzu Application Catalog library are security compliant based on:

Use in air-gapped environments
FIPS
Containers are configured as non-root and the Helm chart is verified to run in OpenShift environments

Go to Tanzu Application Catalog and sign in using your VMware Account. After signing into Tanzu Application Catalog, from the left navigation page, click “Library”.

You can check the security requirements in one of the following ways:

Scroll down to the application you want to check. Tags displayed under the application name indicate the applicable security requirements.
Filter by “Security” from the list of filters displayed on the left-side of the page.
Select an application and click on the “Details” link. In the table that displays, the “Validation Platforms” column indicates the security requirements this chart has been verified against.
Once an application has been added to your catalog, go to “Application” from the left navigation pane. Click on the “Details” link and download the test-results.tar.gz file. If that Helm chart has been verified to meet any security requirements, the file name will indicate that condition.

Are Tanzu Application Catalog applications tested and verified for use in air-gapped environments?

Yes, the verification process involves testing at least two distribution versions on two different Kubernetes platforms to ensure compatibility in air-gapped environments.

To check if an application has been verified for use in air-gapped environments, see How can I check if a Helm chart is configured correctly to meet specific security requirements?.

Is Tanzu Application Catalog verified for FIPS?

Yes, currently Photon OS distributions are verified to be compliant with AKS FIPS.

To check if an application has been verified for FIPS, see How can I check if a Helm chart is configured correctly to meet specific security requirements?.

Is Tanzu Application Catalog verified to run on OpenShift?

Yes, as part of the verification process, certain distributions were verified and found to run on OpenShift, with a specific requirement for a non-root and random-UID configuration.

To check if a Helm chart works with non-root containers see How can I check if a Helm chart is configured correctly to meet specific security requirements?.

Application performance, security, and functional tests in Tanzu Application Catalog

Bitnami application packages available through Tanzu Application Catalog — containers, Helm charts, and OVAs — are built with best practices, kept up to date with the latest application versions, and go through extensive automated tests and verifications to run in their target platforms with the expected behavior and performance. Each application package comes ready to use, requiring no additional setup.

Tanzu Application Catalog applications run through the following tests and validations:

Compliance: Verifies that application components (libraries, packages, and so on) meet license requirements according to VMware open source compliance policies.
Functional: Verifies that the application works as expected depending on functional requirements and specifications. These verifications are:
- Health check: Verifies that the service is running, which means the application URL is reachable and returns a response with an OK HTTPS status.
- End-to-end testing: Validates that the potential deployed software runs from end to end as expected. Tanzu Application Catalog team uses Cypress as an E2E testing framework. In web applications, for example, these verifications include checks on login and logout actions, creation of posts, projects, tickets, plugin installation, and so on. Additionally, other actions are executed such as creating a database, make sure the database is replicated in a high-availability configuration, API queries, create events/topics and make sure they are received, actions in the CLI, and so on.
- Persistence: Checks that the pod or image can be removed and the data is properly configured in an external volume.

To learn more about Bitnami functional tests, see blog post .

Integration: Verifies that the application is correctly configured and integrated with all the other components required to run in the environment where it is going to be deployed. GOSS is the tool used for that purpose.
Performance: Tests functional behavior and measures performance of the application under a heavy load on a server, group of servers, or network. JMeter is the tool used for that purpose.
Security: Verifies the security vulnerabilities of the sources and components used by the application. To scan vulnerabilities in container images, git repositories and filesystems, Trivy is used. To improve and add more information to scanning results, container images and filesystem are also analyzed using Grype. The scanning results are available under the “Build Time Reports” section of each application and are downloadable as a json file.

Additionally, to enforce the security of container images they are configured with a non-root user.

Apart from these validations, Tanzu Application Catalog applications run through rigorous verifications against specific Kubernetes versions and platforms as well have been verified to use in air-gapped and OpenShift environments, and to be verified in FIPS environments. For more information, see How to check if a Helm chart is configured to meet specific security requirements, How is Tanzu Application Catalog continuously tested to be used in production environments, and verification matrix to check the specific Kubernetes and cloud platforms the catalog is verified against.