Operations Guide

Document maturity: DRAFT

Referenced documentation

Introduction

The Coverity component is part of Software Factory as a Package (SWaaP).

Coverity makes it easy to track and manage compliance with the coding standards that matter to your business. Built-in reports provide insight into issue types and severity to help prioritize remediation efforts and track progress toward each standard across teams and projects.

Learn more about it in LLD-Coverity and in TASD .

Service Catalog Items

The catalog items are defined according to the RACI in the LLD.

Grant access to Coverity

This is performed via the bundle ‘Get Access to Software Factory’ catalog item.

See how to configure User Authentication

Manage groups in Coverity

Coverity comes with Builtin groups but allows also easy custom group management Things to consider on this topic include asign users to a group and managing roles for a group

Project creation in Coverity

Coverity admin user has the capability of creating projects

⚠️ The naming rules for projects and streams in Coverity must be unique but we do not have any naming rules to advise our users or a way of enforcing it, thus you can consider the following proposal:

1. Project name:

• For projects in GBUs: COVERITY_PROJECT_NAME = <GBU>-<BL>-<PROJECT/TEAM>-[<RELEASE>] Choose from the following GBU/BL map

  AVS-FLX-PROJECT_NAME/TEAM_NAME

• For projects Off-GBUs:

  COVERITY_PROJECT_NAME = <COS>-<SERVICE>-<PROJECT/TEAM>-[<RELEASE>] (This is the naming convention for Off-GBUs/Services that was used for platform naming. I thought we can keep the trend. See this doc )

  COS-SOFTWARE_FACTORY-SMART_PRODUCTS-TISHA1.2

1. Stream name:

COVERITY_STREAM_NAME = <$COVERITY_PROJECT_NAME>-<branch>-[<language>]-[<target>] … (other suffixes may be added as necessary)

AVS-FLX-PROJECT_NAME/TEAM_NAME-rel2.2-C-32bit COS-SOFTWARE_FACTORY-SMART_PRODUCTS-TISHA1.2-feature1

Note: Everything in square brackets [] is optional.

Billing and onboarding

This section aims at describing how billing related to the component is managed and at specifying offers including access to the component.

General billing principles:

• The price of the licenses is the same across all platforms
• The price of the infrastructure varies per platform
• The licenses are paid only once, regardless of the number of platforms the user is working on
• The infrastructure costs are cumulative
• The chargeback model is available [on SharePoint](the chargeback model )

Billing & onboarding on TDP

To onboard, use Get access to Software Solutions .

To offboard, use Unsubscribe from a pack or a license .

Billing & onboarding on RTDP

RTDP boarding will be done through PostIT soon. Until then, follow this procedure .

Billing & onboarding on CASTLE

To onboard, refer to Software Factory on CASTLE documentation

Component deployment and configuration

Requirements & Pre-requisite

See LLD-Coverity §4.2 prerequisites

Configuration

Setting Helm values

Mandatory Coverity values are described in the SWaaP Readme - Helm values .

There’s also a list of required and optional ConfigMaps that are needed. These are described in the Coverity package readme document

Configuring Kubernetes secrets

We enforce using a secret to store a Connect Web application administator password and reference it via cim.cimweb.adminPasswordSecret key in the value file.

❗ This prevents the deployment of Coverity with a default password

❗ The value set in the secret needs to be compliant with “Connect Web application administator password requirements”

Optional, we recomend to create a secret for storing the Connect license key reference it via global.licenseSecretName key in the value file

Note that, based on the Helm values you provide, additional Kubernetes secrets and configmaps may also be required. Please check the official documentation for further information.

Security context constraints

You can define container security using security context constraints in the various SecurityContext Helm keys. A default container context value is automatically applied for any containerSecurityContext key that is not configured with a different constraint parameter=value pair.

The default containerSecuritycontext Helm key constraints for containers defined in the cnc chart are:

containerSecuritycontext:

  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: <uid>

The default containerSecuritycontext Helm key variables in the scan-services chart are:

  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 5000

You can override the default constraints or apply new constraints for pods or containers as follows:

• You can apply constraints for a pod using the appropriate podSecurityContext Helm key. This value is inherited by all containers within that pod, except if a container has a different context value.

• You can apply constraints for a container using the appropriate containerSecurityContext Helm key.

More on this in Coverity documentation .

Deployment & update procedure

The deployment and update procedures are described in the SWaaP Readme - Quick start section .

Settings

License

If the license is not injected via secret at deployment, you can add it manually as administrator by going to the Configuration > System and choosing Coverity Connect License and import your license.dat license file.

Functional Configuration

Enable Local Password Policy (Security enforcement)

By default, Local Passord Policy is disabled, allowing users to create passwords with a minimum leaght of 6 characters, making them more vulnerable to security breaches. To enable Local Password Policy, navigate to Configuration > System > Authentication and Sign In > Local Password Policy and enable the Local Password Policy option.

Minimum password length

Choose a value that is between 8 and 128.

Default: 8

Recommended: 14

Select the minimum number of each character type

Choose a minimum number between 1 and 32 of each character type that the password must contain. The possible character types are uppercase, lowercase, number, and symbol.

Default: 1

Recommended: at least 1

Number of unsuccessful sign in attempts allowed before the user is locked out

Sets the number of failed sign-in attempts to allow before the user is locked out of the Coverity Connect interface. Once this happens, unless password recovery is enabled, the administrator must reset the password for this user. See Locking and unlocking a user account for more information.

Default: 3

Recommended: 3 ( should not exceed 5 )

Prompt users to update their password upon next sign in

When on, if an existing password does not meet the updated criteria, the next time the user logs in, Coverity Connect will prompt the user to update the password to one that does meet the new criteria.

Default: Off

Recommended: On

SAML Configuration

Enable SAML SSO in Coverity Connect

1. Navigate to Configuration > System > Authentication and Sign In
2. Set:
   • Authentication with → SAML
3. Optional settings:
   • Create SAML users automatically on sign in
     • While this option is active, when a user firsts signs in, Coverity Connect links the SSO user to an existing Coverity Connect user, if there is a user-name match, or it creates a new Coverity Connect user to match the SSO user.
   • Disable all sign in types except for SAML
     • While this option is active, the built-in admin user will always be able to log in locally, but other administrators will not.
4. Click Done

SAML SSO configuration parameters

1. Navigate to Configuration > System > SSO Configuration
2. Set:
   • Disabled
     • When this box has a check mark, this particular SAML SSO configuration is disabled. Because you cannot delete a SAML SSO configuration until there are no more users associated with this configuration, Disabled provides a convenient alternative to deleting a SAML configuration.
   • Display Name
     • The name of the current SAML SSO configuration.
   • SP Entity ID
     • The name of the service provider entity (also known as an Audience URI).
   • SAML Groups
     • When on, Coverity Connect checks whether the metadata from the IdP includes a groups attribute. If it does, a user who logs in is added to the specified groups and removed from others. Users inherit permissions from the groups they belong to. This option is provided for customers who want their IdP app (rather than LDAP settings) to handle all authentication and authorization for Coverity Connect. ❗If you set up SAML SSO to support groups, the groups attribute should be enabled and configured in the IdP. This option supersedes the LDAP group-management settings.

Additional documentation, can be found in the Coverity documentation and in the Setting up SAML for Coverity with Azure . More on Coverity with Azure SAML Group claims

Make Coverity Analysis and license.dat file available from the Connect UI

You can use Coverity Connect to host your Coverity Analysis license files, and associate them with their respective Coverity Connect projects. This allows Desktop Analysis users to be covered by the analysis license file specified by their associated Coverity Connect project. Once retrieved, it can also be used in nextgen-cicd Coverity step by setting its corresponding CI variable.

This is a manual procedure that consists in the following sequence:

• Pull the full-analysis client files from the BlackDuck registry

export USER=XXXXXXX
export PASSWORD=XXXXXXXXXXXXX
mkdir cov_analysis && cd $_ && \
curl https://repo.blackduck.com/coverity-releases/2025.9.3/cov-analysis-linux64-2025.9.3.sh \
-o cov-analysis-linux64-2025.9.3.sh -u $USER:$PASSWORD

where $USER:$PASSWORD are your Black Duck registry credentials that you can obtain from Black Duck community.

Optional you can download ‘cov-analysis-win64-2025.9.3.exe’ or ‘cov-analysis-macosx-2025.9.3.sh’ in above section

• Obtain the Coverity license.dat file from Blackduck customer portal and copy it into the same cov_analysis folder

• Create a Dockerfile similar to this

FROM busybox
COPY cov_analysis /downloads/

• Build a Docker image from the files and save the image in your private registry.

export PATH=XXXXXXXXXXXXX
docker build -t $PATH/analysis-downloads:2025.9.3 .

where , PATH includes the registry URL and the path to the target folder.

• Push the Dockerfile image to your private company registry:

docker push $PATH/analysis-downloads:2025.9.3

• In the Helm chart, create an init container that automatically copies the Docker image to Coverity Connect storage.

cim:
  cimweb:
    initContainers:
    - name: cim-analysis-downloads
      image: $PATH/analysis-downloads:2025.9.3      #update your registry URL/PATH
      command:
        - sh
        - '-c'
        - |
          cp /downloads/* /cimweb/downloads
      resources:
        limits:
          cpu: 100m
          memory: 128Mi
        requests:
          cpu: 100m
          memory: 128Mi
      volumeMounts:
      - name: cim-downloads
        mountPath: /cimweb/downloads
      imagePullPolicy: Always

Monitoring

Coverity generates metric data that enables you to monitor the performance of your Coverity scans. The metric data can be exported to open-source data acquisition and monitoring software such as Prometheus and Grafana, enabling you to monitor Coverity performance.

Metrics for supervising health of components

Presenting application metrics to the /metrics endpoint is enabled by default in the cnc Helm chart.

Also, set the cim.cimweb.exposeMetrics Helm key to true in order to expose time-series metrics in Prometheus format. For example:

cim:
  cimweb:
    exposeMetrics: true
    extraProperties:
      connect.enable.metrics: true     #default to false

When these Helm overrides are set to true, annotations are added to containers which tell an aggregator whether to scrape metrics data or not, and the port/path to use.

Metrics must be pulled from a containers’ port/path. Therefore, containers do not need to know about the metrics aggregator.

All Connect application metrics are published at the /metrics endpoint on port 8089 (configured in Helm charts as described above) by default. This endpoint is not available on any other port.

For security purposes, visiting the /metrics endpoint will throw a 403 forbidden status code. If you need more detailed guidance, Coverity’s official documentation provides comprehensive instructions on setting up and using these metrics.

Logging

This chapter describes details for configuring and accessing:

• Logs from the UI
• System logs
• Console logs

Logs from the UI

While Coverity provides a way to retrieve the logs in the web ui, through Help > System Diagnostics > Logs , this is not available for Cloud Native deployments.

System Logs

The Kubernetes deployment of Coverity doesn’t write logs to files. The only available method to retrieve the logs is through console logs.

Console logs

For Kubernetes deployments the default way of getting the logs is from the stdout/stderr flow, which can be retrieved with the kubectl command:

# Tail the CIM webapp pod logs (replace namespace/pod)
kubectl logs -f -n <namespace> <cim-webapp-pod-name>

# If you have multiple containers in the pod, specify the container
kubectl logs -f -n <namespace> <pod-name> -c cim-webapp

Detailed logging configuration is available in the web UI in the Configuration > System > Logging Configuration . The default categories being logged are Configuration and Access Control.

Log Level

All Coverity cloud containers write logs. Through the Helm chart, you can specify the granularity of the information presented to the logs. In the Helm keys, logLevel is the minimum log level required before events are logged.

You can configure the level of logging through the Helm chart by setting cim.cimweb.logLevel to one of the supported values (ALL, TRACE, INFO, WARN, ERROR, FATAL, OFF). The default value is INFO.