docs: running in production should change aes key (#12132)

* running in production should change aes key

* running in production should change aes key

* add instructions on how to generate AES key

* adjust celery text

Author: valentijnscholten

docs/content/en/open_source/installation/running-in-production.md

@@ -28,6 +28,18 @@ With a separate database, the minimum recommendations to run DefectDojo are:
     a different disk than your OS\'s for potential performance
     improvements.
 
+### Security
+Verify the `nginx` configuration and other run-time aspects such as security headers to comply with your compliance requirements.
+Change the AES256 encryption key `&91a*agLqesc*0DJ+2*bAbsUZfR*4nLw` in `docker-compose.yml` to something unique for your instance.
+This encryption key is used to encrypt API keys and other credentials stored in Defect Dojo to connect to external tools such as SonarQube. A key can be generated in various ways for example using a password manager or `openssl`:
+
+```
+     openssl rand -base64 32
+```
+```
+      DD_CREDENTIAL_AES_256_KEY: "${DD_CREDENTIAL_AES_256_KEY:-<PUT THE GENERATED KEY HERE>o}"
+```
+
 ## File Backup
 
 In both cases (dedicated DB or containerized), if you are self-hosting, it is recommended that you implement and create periodic backups of your data.
@@ -55,7 +67,7 @@ concurrent connections.
 
 ### Celery worker
 
-By default, a single mono-process celery worker is spawned. When storing a large amount of findings, leveraging async functions (like deduplication), or both. Eventually, it is important to adjust these parameters to prevent resource starvation. 
+By default, a single mono-process celery worker is spawned. When storing a large amount of findings or running large imports it might be helpful to adjust these parameters to prevent resource starvation.
 
 The following variables can be changed to increase worker performance, while keeping a single celery container.
 
@@ -80,8 +92,8 @@ and see what is in effect.
 
 <span style="background-color:rgba(242, 86, 29, 0.3)">This experimental feature has been deprecated as of DefectDojo 2.44.0 (March release).  Please exercise caution if using this feature with an older version of DefectDojo, as results may be inconsistent.</span>
 
-Import and Re-Import can also be configured to handle uploads asynchronously to aid in 
-processing especially large scans. It works by batching Findings and Endpoints by a 
+Import and Re-Import can also be configured to handle uploads asynchronously to aid in
+processing especially large scans. It works by batching Findings and Endpoints by a
 configurable amount. Each batch will be be processed in separate celery tasks.
 
 The following variables impact async imports.
@@ -90,7 +102,7 @@ The following variables impact async imports.
 -   `DD_ASYNC_FINDING_IMPORT_CHUNK_SIZE` defaults to 100
 
 When using asynchronous imports with dynamic scanners, Endpoints will continue to "trickle" in
-even after the import has returned a successful response. This is because processing continues 
+even after the import has returned a successful response. This is because processing continues
 to occur after the Findings have already been imported.
 
 To determine if an import has been fully completed, please see the progress bar in the appropriate test.