Internal development environment variable conflicts with customer variables

Summary

The API Security scanner supports two database backends, sql and postgresql. An undocumented environment variable allows switching between the two for testing/development purposes. The name of this environment variable (DB_TYPE) is generic enough as to have conflicts with users configurations causing failures of API Security.

The issue was found through a customer support case where the scanner never starts causing the job to fail. It looks like the customer has a global variable DB_TYPE set for their own existing jobs. When they tried to configure DAST API it caused the scanner background process to fail with an unknown database type error.

Zendesk Ticket: https://gitlab.zendesk.com/agent/tickets/247646

Steps to reproduce

1. Set DB_TYPE global variable to mysql.
2. Run API Security products (DAST API or API Fuzzing)
3. Notice scanner service doesn't start

Example Project

What is the current bug behavior?

API Security job fails waiting for scanner to become available.

What is the expected correct behavior?

API Security job is able to start a session with the scanner.

Possible fixes

1. Rename the environment variable to API_SECURITY_DEV_DB_TYPE
2. Release new container
3. Add to troubleshooting guide with version guidance