Deploying ScanCentral SAST ESF Adapter in Kubernetes

Official Helm chart for deploying ScanCentral SAST ESF Adapter 26.2 sensor connector to Kubernetes. ScanCentral SAST ESF Adapter orchestrates scan requests from SC SAST, coordinates with ESF for scanning operations, and manages artifact storage via S3.

Table of Contents

• Overview
• Prerequisites
  • Required Tools
  • Required Services
  • Access Requirements
• Installation Guide
  • Step 1: Create database in Postgres
  • Step 2: Configure namespace
  • Step 3: Preparing required services
  • Step 4: Creating Secrets
    • Database credentials secret
    • Database CA certificate (for TLS)
    • SC SAST sensor token
    • ESF authentication token
    • S3 credentials
    • SC SAST CA certificate (for TLS)
    • ESF CA certificate (for TLS)
  • Step 5: Registering ESF scanners
    • Terminology
    • Configurable ProcessQueue (scanner) parameters
    • Queue name
    • Examples
      • Register a single set of default linux sensors
      • Register small and large linux sensors
      • Register linux sensors with additional environment variables set
  • Step 6: Installing the ScanCentral SAST ESF Adapter Chart
    • Verify Installation
• Upgrading
  • Upgrading ScanCentral SAST ESF Adapter
  • Upgrading ProcessQueues (sensors modification)
• Architecture
• Limitations
• Additional information
  • State Persistence and Recovery
• Troubleshooting
• ESF installation guide

Overview

ScanCentral SAST ESF Adapter is a sensor adapter that:

• ✅ Processes scan requests from SC SAST
• ✅ Coordinates with ESF (Elastic Service Fabric) for scan execution and on-demand scanner machine resource allocation
• ✅ Manages artifact storage and retrieval via S3-compatible storage
• ✅ Maintains scan state in a PostgreSQL database

Kubernetes versions

The repository production guide currently documents these tested Kubernetes versions:

• Kubernetes 1.33
• Kubernetes 1.34
• Kubernetes 1.35

Helm version

• Helm 3.18
• Helm 3.19

Prerequisites

Before installing ScanCentral SAST ESF Adapter, ensure you have:

Required Tools

• Kubernetes cluster
• Helm
• kubectl

Required Services

The following services must be available in your Kubernetes cluster and started before running ScanCentral SAST ESF Adapter:

Access Requirements

• Network connectivity between ScanCentral SAST ESF Adapter and all required services
• Proper credentials for all external services

Installation Guide

The following steps create secrets using the default names and keys referenced in the ScanCentral SAST ESF Adapter Helm chart values (see values.yaml). You can reuse existing secrets from other charts (e.g., from SC SAST Controller or ESF) when the names and keys match, or create new secrets with custom names by updating the chart values.

Step 1: Create database in Postgres

ScanCentral SAST ESF Adapter requires a database to be present in PostgreSQL before the application starts. Connect to your PostgreSQL instance using admin credentials and run the following command to create the database:

CREATE DATABASE "sc-sast-esf-adapter-db";

The default database name used in the Helm chart is sc-sast-esf-adapter-db. If you use a different name, update the database.name value in your Helm chart configuration accordingly.

Step 2: Configure namespace

Set the Kubernetes namespace where all resources will be deployed. All subsequent kubectl and helm commands in this guide use this environment variable.

export NAMESPACE=default

Note: Replace default with your target namespace if you are deploying to a custom namespace (e.g., scancentral).

Step 3: Preparing required services

1. Follow ESF installation guide to install the ESF Helm chart.
2. Follow SC SAST documentation to install the SC SAST Controller Helm chart.
3. Install and configure PostgreSQL.

Step 4: Creating Secrets

Credentials and certificates for the required services are provided via Kubernetes secrets. ScanCentral SAST ESF Adapter requires several secrets for secure operation.

Creating an image pull secret

By default, the Fortify ScanCentral SAST ESF Adapter components Helm chart references its images directly from DockerHub. For Kubernetes to properly install your images using the default configuration, you must create an image pull secret and store it in your installation namespace in Kubernetes. If you are replicating these images to a local repository, you can skip this task and update the relevant image values in the Helm chart to reference your local repository. To create an image pull secret:

• Use the kubectl create secret command as shown in the following code sample:

  kubectl create secret docker-registry docker.io \
   --docker-server=https://index.docker.io/v1/ \
   --docker-username='<docker username>' \ 
   --docker-password='<docker password>' \
   --docker-email='<docker user email>'

Database credentials secret

Database administrator credentials secret. These credentials must be valid and precreated in the database. Initialization container uses them to create a ScanCentral SAST ESF Adapter database schema and application user.

Default secret creation example:

kubectl create secret generic sc-sast-esf-adapter-db-secret-admin \
  --from-literal=username='admin-username' \
  --from-literal=password='admin-password' \
  -n $NAMESPACE

Application user credentials. Application will use this user configuration to work with the database. It is not necessary to create this user in the database prior to running the application. Initialization container can create the user using administrator credentials if needed.

Default secret creation example:

kubectl create secret generic sc-sast-esf-adapter-db-secret \
  --from-literal=username='db-username' \
  --from-literal=password='db-password' \
  -n $NAMESPACE

Database CA certificate (for TLS)

When database.sslRootCertSecret.enabled is true (the default), a secret containing the PostgreSQL CA certificate must be created so the adapter can verify the server's identity.

Default secret creation example:

kubectl create secret generic sc-sast-esf-adapter-db-ca \
  --from-file=ca.crt=path/to/postgres-ca.crt \
  -n $NAMESPACE

Update database.sslRootCertSecret.name and database.sslRootCertSecret.key in your Helm values if you use a different secret name or key.

SC SAST sensor token

ScanCentral SAST ESF Adapter requires SC SAST worker auth token configured. Reusable from SC SAST Controller: If you've deployed the SC SAST Controller Helm chart with its default configuration, the secret scancentral-chart-secret with key scancentral-worker-auth-token already exists. This adapter uses the same default, so you can skip this step. If not reusing, create:

kubectl create secret generic scancentral-chart-secret \
  --from-literal=scancentral-worker-auth-token='sensor-token' \
  -n $NAMESPACE

ESF authentication token

Reusable from ESF: If you've deployed the ESF Helm chart with its default configuration, the secret esf-sjc-credentials with key token already exists. The adapter uses this as the default secret, so you can skip this step. If you need a different secret, update esf.authSecret.name and esf.authSecret.key in your Helm values, or create a new secret:

kubectl create secret generic esf-sjc-credentials \
  --from-literal=token='your-esf-auth-token' \
  -n $NAMESPACE

Fortify license file

Fortify SAST which is ran by ESF scanners requires fortify.license file. It should be mounted using a secret named fortify-esf-secrets.

kubectl create secret generic fortify-esf-secrets \
  --from-file=fortify.license=<path to fortify.license file> \
  -n $NAMESPACE

S3/MinIO credentials

S3 credentials (access key and secret key) are stored in a single secret. The default secret name and key names are referenced in values.yaml under s3.credentialsSecret:

kubectl create secret generic sc-sast-esf-adapter-s3-secret \
  --from-literal=accessKeyId='your-access-key' \
  --from-literal=secretAccessKey='your-secret-key' \
  -n $NAMESPACE

Reusable: If you have an existing S3/MinIO secret with these credentials, update the s3.credentialsSecret values in your Helm chart to reference it instead of creating a new one. You can reuse the secret used for credentials in ESF helm chart stored in values as sjc.csAuth.authCred. Default value is esf-s3-credentials.

Note: if you use MinIO instead of AWS S3, the access key is a MinIO user name, where secret key is a MinIO user password.

MinIO certificate (for TLS)

If you use MinIO with self signed certificates, the secret with MinIO certificate should be created. The default secret name and key are referenced in values.yaml under s3.certificateSecret:

kubectl create secret generic esf-cs-cert \
  --from-path=tls.crt=path/to/minio.crt \
  -n $NAMESPACE

Reusable If you have an existing MinIO secret with the certificate, update the s3.credentialsSecret values in your Helm chart to reference it instead of creating a new one. You can reuse the secret used for a certificate in ESF helm chart stored in values as sjc.csAuth.certificateSecret.

SC SAST CA certificate (for TLS)

kubectl create secret generic sc-sast-esf-adapter-scsast-ca \
  --from-file=cert=path/to/ca-cert.pem \
  -n $NAMESPACE

ESF CA certificate (for TLS)

Reusable from ESF: If you've deployed the ESF Helm chart with its default configuration, the secret fortify-sjc-secrets with key ca.crt already exists. The adapter uses this as the default secret, so you can skip this step. If you need a different secret, update esf.certificateSecret.name and esf.certificateSecret.key in your Helm values, or create a new secret:

kubectl create secret generic fortify-sjc-secrets \
  --from-file=ca.crt=path/to/ca-cert.pem \
  -n $NAMESPACE

Step 5: Registering ESF scanners

Terminology

ProcessQueue - custom Kubernetes resource the ESF operates with. ProcessQueue is a blueprint for SJM pods. ProcessQueue describes the resources and attributes of SJM pods and specifies how many pods can be created. It can be called a Queue or sensor group for simplicity. SJM - scanner job manager of ESF. The application that actually performs a scan. It can be called a scanner or sensor for simplicity. ScanCentral SAST ESF Adapter virtual sensor - representation of an SC SAST sensor rendered in SSC, but managed by ScanCentral SAST ESF Adapter. It mediates communication between the SC SAST Controller and ESF.

ESF provides efficient resource management by spinning up sensors on demand using a Kubernetes resource called ProcessQueue. It allows running additional sensor pods when more jobs need to be processed simultaneously. ESF supports zero scaling, allowing zero pods to run when there are no active jobs, or it can keep multiple sensors always running ("warmed up") to decrease scan latency due to startup time.

Despite downscaling in ESF, the number of active sensors rendered in the SSC UI for SC SAST is generally equal to an ESF sensor group's maximum size. The sensor count on the SC SAST page indicates how many jobs can be processed in parallel. Showing the maximum possible ESF sensor count as the number of actively connected SC SAST sensors reflects this purpose. As for SC SAST sensor parameters shown in SSC, the maximum of min and max memory/CPU values is shown to represent full sensor capacity.

Only Linux sensors are currently supported.

To create ScanCentral SAST ESF Adapter virtual sensors, the ESF sensors should be installed. ScanCentral SAST ESF Adapter provides a Helm chart for this purpose.

helm install scancentral-sast-esf-adapter-operator \
  oci://registry-1.docker.io/fortifydocker/helm-scancentral-sast-esf-adapter-operator:<tag> \
  -f queue-values.yaml -n $NAMESPACE

If you are already familiar with configuring queue-values.yaml, skip to the next step.

Configurable ProcessQueue (scanner) parameters

The following table lists the configurable parameters of the ProcessQueue chart and their descriptions.

Queue name

Queue name is important because it uniquely identifies the group of sensors with the same parameters. If the same name is used for more than one Queue, only the last one will be visible to ScanCentral SAST ESF Adapter. The Queue name affects SC SAST sensor UUID generation.

ScanCentral SAST ESF Adapter uses the Queue name to store SC SAST sensors in the database. After ScanCentral SAST ESF Adapter restarts, it pulls the Queue information from ESF, and if Queues were upgraded but the names remain the same, ScanCentral SAST ESF Adapter recreates SC SAST sensors using existing UUIDs so no new sensors are shown in SSC.

Following examples show how sensor UUID reuse works for different hosting scenarios:

1. Self-hosted SC SAST sensors
2. Sensors created by the SC SAST Helm chart
3. ScanCentral SAST ESF Adapter managed sensors

The UUID preservation can be useful if sensors should remain in the same sensor pool after update.

Example 1

1. Self-hosted

There are two self-hosted 25.4 SC SAST sensors running on virtual machines. On startup, each sensor gets a UUID saved into the worker-persist.properties file.

Sensor 1 25.4: 11111111-1111-1111-1111-111111111111
Sensor 2 25.4: 22222222-2222-2222-2222-222222222222

User updates Sensor files to 26.2 but preserves worker-persist.properties files.

Sensor 1 26.2: 11111111-1111-1111-1111-111111111111
Sensor 2 26.2: 22222222-2222-2222-2222-222222222222

During the update, SSC showed the sensors as Inactive, but after the update they appear in SSC as Active, and the SCA version is shown as 26.2.

2. SC SAST helm chart

The SC SAST Helm chart is run with Generate worker UUIDs from release name and is invoked as

helm install scsast ./helm/scsast

It creates 2 SC SAST sensors with UUID generated from scsast-worker-0 and scsast-worker-1 names:

Sensor sc-sast-worker-0 25.4: 11111111-1111-1111-1111-111111111111
Sensor sc-sast-worker-1 25.4: 22222222-2222-2222-2222-222222222222

User upgrades helm chart to 26.2 but reuses the release name.

helm upgrade scsast ./helm/scsast

It creates 2 SC SAST sensors with same UUID as they are generated from scsast-worker-0 and scsast-worker-1 names:

Sensor scsast-worker-0 26.2: 11111111-1111-1111-1111-111111111111
Sensor scsast-worker-1 26.2: 22222222-2222-2222-2222-222222222222

During update SSC showed the sensors as Inactive but after update they apper in SSC as Active but the SCA version is shown now as 26.2

3. ScanCentral SAST ESF Adapter

ProcessQueue is creates with a linux-standard name and maxScale=2. It creates 2 SC SAST Sensors and map generated UUIDs to linux-standard identifier.

"linux-standard": {
  "uuids": [
    "11111111-1111-1111-1111-111111111111",
    "22222222-2222-2222-2222-222222222222"
  ]
}

Sensor 1 25.4: 11111111-1111-1111-1111-111111111111
Sensor 2 25.4: 22222222-2222-2222-2222-222222222222

User stops ScanCentral SAST ESF Adapter and upgrades Queues to 26.2 using the scancentral-sast-esf-adapter-operator Helm chart but reuses the Queue name linux-standard.

ScanCentral SAST ESF Adapter retrieves from database the existing UUIDs for linux-standard identifier and recreates SC SAST sensors using them.

"linux-standard": {
  "uuids": [
    "11111111-1111-1111-1111-111111111111",
    "22222222-2222-2222-2222-222222222222"
  ]
}

Sensor 1 26.2: 11111111-1111-1111-1111-111111111111
Sensor 2 26.2: 22222222-2222-2222-2222-222222222222

During update SSC showed the sensors as Inactive but after update they apper in SSC as Active but the SCA version is shown now as 26.2

Example 2

1. Self-hosted

There are 2 self hosted 25.4 SC SAST Sensors running on virtual machines. On a startup each sensor gets a UUID saved into worker-persist.properties file.

Sensor 1 25.4: 11111111-1111-1111-1111-111111111111
Sensor 2 25.4: 22222222-2222-2222-2222-222222222222

User updates Sensor files to 26.2. User preserves worker-persist.properties for Sensor 1, but creates Sensor 2 from scratch.

Sensor 1 26.2: 11111111-1111-1111-1111-111111111111
Sensor 2 26.2: 33333333-3333-3333-3333-333333333333

During update SSC showed the sensors as Inactive but after update it shows 2 sensors as Active, but at the same time it shows one sensor as Inactive because that sensor was identified with 22222222-2222-2222-2222-222222222222 UUID.

2. SC SAST helm chart

SC SAST helm chart is ran with Generate worker UUIDs from release name and ran as

helm install scsast-25.4 ./helm/scsast

It creates 2 SC SAST sensors with UUID generated from scsast-25.4-worker-0 and scsast-25.4-worker-1 names:

Sensor scsast-worker-25.4-0 25.4: 11111111-1111-1111-1111-111111111111
Sensor scsast-worker-25.4-1 25.4: 22222222-2222-2222-2222-222222222222

User installs the 26.2 Helm chart and uses a new release name.

helm delete scsast-25.4
helm install scsast-26.2 ./helm/scsast

It creates 2 SC SAST sensors with same UUID as they are generated from scsast-worker-0 and scsast-worker-1 names:

Sensor scsast-worker-26.2-0 26.2: 33333333-3333-3333-3333-333333333333
Sensor scsast-worker-26.2-1 26.2: 44444444-4444-4444-4444-444444444444

During the update, SSC showed the sensors as Inactive, and after the update they both remained Inactive while two new Active sensors are shown in SSC.

3. ScanCentral SAST ESF Adapter

ProcessQueue is created with the linux-standard-25.4 name and maxScale=2. It creates two SC SAST sensors and maps generated UUIDs to the linux-standard-25.4 identifier.

"linux-standard-25.4": {
  "uuids": [
    "11111111-1111-1111-1111-111111111111",
    "22222222-2222-2222-2222-222222222222"
  ]
}

Sensor 1 25.4: 11111111-1111-1111-1111-111111111111
Sensor 2 25.4: 22222222-2222-2222-2222-222222222222

User stops ScanCentral SAST ESF Adapter and upgrades Queues to 26.2 using the scancentral-sast-esf-adapter-operator Helm chart:

1. Sets maxScale=1 for linux-standard-25.4
2. Creates a new queue linux-standard-26.2 with maxScale=1

ScanCentral SAST ESF Adapter generates new UUIDs for the linux-standard-26.2 identifier and recreates the SC SAST sensor for linux-standard-25.4.

"linux-standard-25.4": {
  "uuids": [
    "11111111-1111-1111-1111-111111111111",
    "22222222-2222-2222-2222-222222222222"
  ]
},
"linux-standard-26.2": {
  "uuids": [
    "33333333-3333-3333-3333-333333333333"
  ]
}

Sensor 1 25.4: 11111111-1111-1111-1111-111111111111
Sensor 2 26.2: 33333333-3333-3333-3333-333333333333

During the update, SSC showed the sensors as Inactive, but after the update one 25.4 sensor appears as Active while another remains Inactive. The new 26.2 sensor is shown as Active.

Examples

Register a single set of default linux sensors

values.yaml:

processQueues:
  - name: linux-standard
    os: linux

helm install scancentral-sast-esf-adapter-operator \
  oci://registry-1.docker.io/fortifydocker/helm-scancentral-sast-esf-adapter-operator:<tag> \
  -f values.yaml -n $NAMESPACE

This will create a ProcessQueue object with

minScale=1
maxScale=1

so it will create and immediately spin up one ESF scanner pod.

minCpu=8
maxCpu=8
minMem=32Gi
maxMem=32Gi
os=linux

which will effectively create one SC SAST sensor shown in SSC and controlled by ScanCentral SAST ESF Adapter with the following configuration:

os=linux
sastVersion=26.2.0
scSastVersion=26.2.0
memory=32Gi
cpu=8

Register a set of small linux sensors and set of large linux sensors

values.yaml:

processQueues:
  - name: linux-small
    os: linux
    queueMinScale: 0
    queueMaxScale: 3
    attributes:
      podMinCpu: "2"
      podMaxCpu: "4"
      podMinMem: "8Gi"
      podMaxMem: "16Gi"
      
  - name: linux-large
    os: linux
    queueMinScale: 1
    queueMaxScale: 2
    attributes:
      podMinCpu: "16"
      podMaxCpu: "16"
      podMinMem: "64Gi"
      podMaxMem: "64Gi"

helm install scancentral-sast-esf-adapter-operator \
  oci://registry-1.docker.io/fortifydocker/helm-scancentral-sast-esf-adapter-operator:<tag> \
  -f values.yaml -n $NAMESPACE

This will create two ProcessQueue objects with different resource profiles:

Small Linux Queue:

minScale=0
maxScale=3
minCpu=2
maxCpu=4
minMem=8Gi
maxMem=16Gi
os=linux

Large Linux Queue:

minScale=1
maxScale=2
minCpu=16
maxCpu=16
minMem=64Gi
maxMem=64Gi
os=linux

This will effectively create 5 SC SAST sensors shown in SSC and controlled by ScanCentral SAST ESF Adapter:

3 Small Linux Sensors:

os=linux
sastVersion=26.2.0
scSastVersion=26.2.0
memory=16Gi
cpu=4

2 Large Linux Sensors:

os=linux
sastVersion=26.2.0
scSastVersion=26.2.0
memory=64Gi
cpu=16

Note: The small sensors have minScale=0, so no pods will be running initially. When a scan is assigned to a small sensor, ESF will spin up a pod on demand. The large sensors have minScale=1, so 1 pod will always be running ("warmed up") to reduce scan latency.

Register a set of linux sensors with additional environment variables set

values.yaml:

processQueues:
  - name: linux-with-proxy
    os: linux
    queueMaxScale: 3
    environmentVariables:
      HTTPS_PROXY_HOST: "http://proxy.corp.example.com"
      HTTPS_PROXY_PORT: "3128"
      NO_PROXY: "localhost,127.0.0.1,.svc,.cluster.local"
      CUSTOM_SETTING: "value"

helm install scancentral-sast-esf-adapter-operator \
  oci://registry-1.docker.io/fortifydocker/helm-scancentral-sast-esf-adapter-operator:<tag> \
  -f values.yaml -n $NAMESPACE

This will create a ProcessQueue object:

Linux Queue with Environment Variables:

minScale=1
maxScale=3
minCpu=8
maxCpu=8
minMem=32Gi
maxMem=32Gi
os=linux
environmentVariables:
  HTTPS_PROXY_HOST: "http://proxy.corp.example.com"
  HTTPS_PROXY_PORT: "3128"
  NO_PROXY: "localhost,127.0.0.1,.svc,.cluster.local"
  CUSTOM_SETTING: "value"

This will effectively create 3 SC SAST sensors shown in SSC:

Linux Sensors with Proxy Configuration:

os=linux
sastVersion=26.2.0
scSastVersion=26.2.0
memory=32Gi
cpu=8

Note: The environment variables are passed to the ESF scanner pods and are available during scan execution. Common use cases include proxy configuration, custom paths, or scanner-specific settings.

Step 6: Installing the ScanCentral SAST ESF Adapter Chart

Configuration Values Reference

The following table describes all configurable values in the ScanCentral SAST ESF Adapter Helm chart organized by section:

Resources

Database Configuration

SC SAST Configuration

ESF Configuration

S3 Configuration

ScanCentral SAST ESF Adapter retrieves S3 (MinIO) bucket from ESF server. The only options required for configuration for the Adapter itself are region (only when S3 is used) and credentials for a connection. To simplify configuration you can reuse the secret used for credentials in ESF helm chart stored in values as sjc.csAuth.authCred.

Fortify recommends keeping s3.useSSL set to true and s3.skipTLSVerify set to false to avoid insecure configurations in production.

Logging

Init Container Configuration

Create a custom values file (custom-values.yaml):

# Resource limits
resources:
  limits:
    cpu: 2000m
    memory: 1Gi
  requests:
    cpu: 200m
    memory: 256Mi

# Service endpoints (adjust to match your cluster)
database:
  host: "my-postgres-service"
  port: 5432
  name: "sc-sast-esf-adapter-db"
  sslmode: "require"
  connectionTimeout: 30
  adminCredentialsSecret:
    name: "sc-sast-esf-adapter-db-secret-admin"
    usernameKey: "username"
    passwordKey: "password"
  credentialsSecret:
    name: "sc-sast-esf-adapter-db-secret"
    usernameKey: "username"
    passwordKey: "password"
  sslRootCertSecret:
    enabled: true
    name: "sc-sast-esf-adapter-db-ca"
    key: "ca.crt"

scsast:
  url: "https://scancentral-sast:8443/scancentral-ctrl"
  sensorTokenSecret:
    name: "scancentral-chart-secret"
    key: "scancentral-worker-auth-token"
  certificateSecret:
    name: "sc-sast-esf-adapter-scsast-ca"
    key: "cert"
  connectionTimeout: 60

esf:
  url: "https://esf:31031"
  tenantId: 1
  connectionTimeout: 30
  certificateSecret:
    name: "fortify-sjc-secrets"
    key: "ca.crt"
  authSecret:
    name: "esf-sjc-credentials"
    key: "token"

s3:
  certificateSecret:
    enabled: true
    name: "esf-cs-cert"
    key: "tls.crt"
  credentialsSecret:
    name: "esf-s3-secret"
    accessKeySecretKeyName: "accessKeyId"
    secretKeySecretKeyName: "secretAccessKey"

logLevel: INFO

If using AWS S3 instead of MinIO, use the following minimal s3 section in custom-values.yaml:

s3:
  region: 'us-east-1'
  credentialsSecret:
    name: "esf-s3-secret"
    accessKeySecretKeyName: "accessKeyId"
    secretKeySecretKeyName: "secretAccessKey"

Install with custom values:

helm install scancentral-sast-esf-adapter \
  oci://registry-1.docker.io/fortifydocker/helm-scancentral-sast-esf-adapter:<tag> \
  -f custom-values.yaml -n $NAMESPACE

Verify Installation

# Check deployment status
helm status scancentral-sast-esf-adapter -n $NAMESPACE

# Check pod status
kubectl get pods -l app.kubernetes.io/name=scancentral-sast-esf-adapter -n $NAMESPACE

# View application logs
kubectl logs -l app.kubernetes.io/name=scancentral-sast-esf-adapter --tail=50 -n $NAMESPACE

# Check init container logs
kubectl logs -l app.kubernetes.io/name=scancentral-sast-esf-adapter -c db-init -n $NAMESPACE

Successful installation should show:

• Deployment created and rolled out
• Pod(s) in Running state
• Init container completed successfully
• Application logs showing connection to services

Upgrading

Upgrading ScanCentral SAST ESF Adapter

Upgrade to new configuration or chart version:

# Upgrade with custom values
helm upgrade scancentral-sast-esf-adapter \
  oci://registry-1.docker.io/fortifydocker/helm-scancentral-sast-esf-adapter:<tag> \
  -f custom-values.yaml -n $NAMESPACE

Upgrading ProcessQueues (sensors modification)

ScanCentral SAST ESF Adapter is sensitive to ESF queue modifications. If any modifications to ESF are required—such as adding new sensors, changing existing sensor parameters, or deleting sensors — ScanCentral SAST ESF Adapter must be stopped prior to those changes. These modifications change internal component IDs that are processed on application startup. If modifications are made while ScanCentral SAST ESF Adapter is running, it might lead to unpredictable behavior.

Upgrade steps:

1. Stop the ScanCentral SAST ESF Adapter service
2. Delete existing ScanCentral SAST Esf Adapter Operator deployment

helm uninstall scancentral-sast-esf-adapter-operator -n $NAMESPACE

3. Modify values file
4. Install ScanCentral SAST Esf Adapter Operator with modified values.

helm install scancentral-sast-esf-adapter-operator \
  oci://registry-1.docker.io/fortifydocker/helm-scancentral-sast-esf-adapter-operator:<tag> \
  -f modified-queue-values.yaml -n $NAMESPACE

Warning: The current version of the Operator does not support helm upgrade and requires the existing deployment to be uninstalled first. To preserve existing sensor UUIDs, queue names in the Helm chart values must remain unchanged. Running helm upgrade to modify ProcessQueues can lead to abandoned deployments in Kubernetes.

5. Start the ScanCentral SAST ESF Adapter service

Limitations

• ScanCentral SAST ESF Adapter is sensitive to the components starting order. Required services must be started prior to starting ScanCentral SAST ESF Adapter.
• ScanCentral SAST ESF Adapter is sensitive to ESF queue modifications. If any modifications are required to ESF such as queue modifications, queue creation/deletion, ScanCentral SAST ESF Adapter must be stopped prior to those changes. The mentioned modifications change internal components IDs which are processed on an application startup. If modificatons are done when ScanCentral SAST ESF Adapter is running, it will lead to unpredictable behavior.
• ESF is a multitenant system; however, to work properly ScanCentral SAST ESF Adapter should be the only client connected to ESF at the same time.
• When working with ScanCentral SAST ESF Adapter, no manual scan requests or scan manipulations should be performed on ESF. Scan orchestration must be done using the ScanCentral Controller. Manual requests to ESF might lead to an unpredictable or unstable state of the system.
• The current version of the Operator does not support helm upgrade and requires the existing deployment to be uninstalled first. To preserve existing sensor UUIDs, queue names in the Helm chart values must remain unchanged. Running helm upgrade to modify ProcessQueues can lead to abandoned deployments in Kubernetes.

Additional information

State Persistence and Recovery

Each scan in ScanCentral SAST ESF Adapter has multiple phases, such as getting job data from SC SAST, sending it to ESF, creating and tracking scan status in ESF, and sending results back to SC SAST. ScanCentral SAST ESF Adapter persists the phase of each sensor and assigned scan in the database, so that even if ScanCentral SAST ESF Adapter is restarted or SC SAST/ESF becomes unavailable, it can continue from the last known point.

Example 1: Restart ScanCentral SAST ESF Adapter

1. Virtual sensor 1 receives a job assignment for job_1
2. It downloads job data from SC SAST and triggers a scan in ESF. It is waiting for job completion
3. From SC SAST Controller's perspective, the sensor is performing a scan
4. ScanCentral SAST ESF Adapter is restarted. The sensor is restored using the same UUID
5. Instead of requesting a new job from SC SAST and faulting the previously assigned one (as would happen to a physical sensor), ScanCentral SAST ESF Adapter restarts the virtual sensor at the phase where it is waiting for job completion in ESF

Example 2: ESF is Temporarily Unavailable

1. Virtual sensor 1 receives a job assignment for job_1
2. It downloads job data from SC SAST and triggers a scan in ESF. It is waiting for job completion
3. From SC SAST Controller's perspective, the sensor is performing a scan
4. ESF service becomes unavailable for some reason

The scan cannot be completed now, and it's unknown whether it's still in progress by the ESF scanner. However, there's no point in faulting the scan in SC SAST because when ESF comes back online, it can actually be successfully completed. Also, even if the scan is faulted, there's no point in requesting a new one because it cannot be assigned to ESF anyway.

Instead, ScanCentral SAST ESF Adapter waits for ESF to come back online and then proceeds from the last checkpoint.

Abandoned Scans: A scan can be abandoned similar to when a physical sensor is shut down and never started again. This might happen if a new queue is created using a new scanner group name, so the previous sensor UUID is not restored, and jobs assigned to those sensors cannot be completed. In this case, SC SAST Controller will eventually mark the sensor as inactive and deal with the scan.

Troubleshooting

If when helm uninstall scancentral-sast-esf-adapter-operator stuck it might be because it can be CRD issue. Sensor is stuck in some phase because it always gets 5xx or other non terminal error from ESF/SCSAST. Solution - cancel the scan in SC SAST, delete queue, create a queue with a new name.

ESF installation guide

For more information on installing ESF, refer to the Deploying Elastic Service Fabric in Kubernetes guide.