SAST ci template to support multi line env vars by using -e instead of .env file

What does this MR do?

This MR changes the way environment variables are loaded in docker for SAST jobs. The current method of loading environment variables uses a .env file. This MR introduces a change that loads env vars using the -e option in docker run ....

This MR would fix two issues the SAST team has encountered.

1. The first being users are unable to load multi-line variables due to the way docker reads the .env file. If a user supplies a multi-line CI/CD variable docker will fail with a docker: poorly formatted environment: ... error. By loading in the variables with individual -e VAR options users are able to pass in multi-line variables.
2. The second issue is related to the SAST secrets scan picking up secrets passed in via the .env file. If a user supplies a secret in the form of a CI/CD variable it will get written to the .env file which the secrets scanner will pick up and detect as a vulnerability. By using the -e VAR method the CI/CD secrets will not be detected by the secrets scanner because they only exist within the environment and are not considered to be part of the repo.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team