> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/sast-and-sca/prezero/customization/config-file.md).
# Configuration file
In your application's repository, you can include a file named **ngsast.yaml** containing configuration information for how you want Qwiet AI by Harness to analyze your code.
Within the **ngsast.yaml** configuration file, you can define:
* A default configuration to be used during the analysis of the artifact
* A custom configuration to be used for the analysis of the specific artifact
* Configurations that are not typically available via `sl`
* Modification rules that allow you to match findings and change their attributes (e.g., severity or CVSS score)
## Adding a configuration file
To use a configuration file, you will need to:
1. Create a configuration file
2. Modify your configuration file
3. Ensure that your configuration file is in the root folder of your application's repository; Qwiet AI by Harness will automatically look for an **ngsast.yaml** file in this location and load the included options if it finds a file
You can generate a sample configuration file by running the following:
```
sl ngsast default
```
 
Once Qwiet generates the necessary configuration file for you, you can edit it to reflect your preferences for how the code analysis runs. Then, move the **ngsast.yaml** file to the root folder of your app repository.
## Working with the configuration file
The following is a sample of what a configuration file might look like:
```
ngsast:
- app:
name: helloshiftleft
language: JAVA # change to your app's language
policy: io.shiftleft/helloshiftleft # change this policy name to the one you'd like to use for this app
- app:
name: helloshiftleft-js
language: JAVASCRIPT # change to your app's language
additional-findings:
- hsl-js-secrets
- default:
policy: io.shiftleft/defaultWithDict
additional-findings:
hsl-js-secrets:
name: secrets
entropy: 0.5
include:
- "**/*.properties"
- src/**
exclude:
- src/test/**
```
 
The config file is divided into two sections: `ngsast` and `additional-findings`. Only the `ngsast` parameter is required; you can provide `additional-findings` parameters to customize your code analysis further using features designed to return additional findings (e.g., identifying [Secrets](/sast-and-sca/prezero/secrets.md) in your code).
In the example above, the `ngsast` portion of the file contains configuration information for two applications: `helloshiftleft` and `helloshiftleft-js`. A `default` section also provides configuration information when analyzing applications that *aren't* explicitly named.
For the application named `helloshiftleft`, the configuration file states that its analysis should use the `io.shiftleft/helloshiftleft` policy and that the application is written in Java.
However, for the application `helloshiftleft-js`, the configuration file specifies that the analysis should be run with slightly different parameters. More specifically, the application is written in JavaScript, and while running the analysis, Qwiet should look to a custom `additional-findings` configuration with the **custom ID** of `hsl-js-secrets`.
The specifics of `hsl-js-secrets` are defined at the bottom of the config file; more specifically, the analysis should include looking for hard-coded credentials only in `.properties` files and files in `src` directory without files in `src/test` subdirectory, and using an entropy (or sensitivity) level of `0.5`.
## Parameters
Different sections of the configuration file accept different parameters for defining how the code analysis should run.
### NGSAST parameters
The following is a list of parameters you can include in the `ngsast` section of your configuration file.
| **Parameter** | **Description** |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | The unique name of the application. Required for the `app` parameter; disallowed for the `default` parameter |
| `language` | Optional. The language of the application. Accepted values: `C`, `JAVA`, `CSHARP`, `JAVASCRIPT`, `GO`, `PHP`, `PYTHON`, `TERRAFORM` |
| `policy` | Optional. The custom policy to use during analysis. Default: **io.shiftleft/defaultWithDict** |
| `additional-findings` | Optional. The additional analyses to be run in Qwiet AI by Harness. Accepted value: `secrets` or the **custom ID** (as defined in the `additional-findings` section of the config file) |
### Additional NGSAST parameters
The following is a list of parameters you can include in your `additional-findings` section.
| **Parameter** | **Description** |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `secrets` | The default configuration for analyzing for `secrets` |
| `custom-id` | A default configuration with a name of your choice, eg., `hsl-js-secrets`, for one of the above analysis modes. Requires a sub-parameter `name` with accepted value `secrets` |
#### Secrets parameters
The following is a list of parameters you can include in the `secrets` portion under `additional-findings`.
| **Parameter** | **Description** |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `entropy` | Optional. Entropy level to be used during the hard-coded credentials analysis. The accepted value is between 0 and 1 (inclusive). Default: `0.0` |
| `obfuscate` | Optional. A Boolean parameter indicating whether the literals returned in the results should be obfuscated. Default: `false` |
| `name` | The name of the analysis and the value to be provided in place of **custom\_id**. If you include the configuration for hard-coded credentials, this parameter is not optional and must be `secrets` |
| `include` | Optional. A list of paths that you want included during secrets detection. Accepts wildcards; use `*` to search the provided directory, and use `**` to search the provided directory and its subdirectories |
| `exclude` | Optional. A list of paths that you want **excluded** during secrets detection. Accepts wildcards; use `*` to search the provided directory, and use `**` to search the provided directory and its subdirectories |
| `include-tags` | Optional. A list of tags that you want included during secrets detection. It's case insensitive. Examples of tags: `PII`, `IaaS`, `Social Media` |
| `exclude-tags` | Optional. A list of tags that you want **excluded** during secrets detection. It's case insensitive. Examples of tags: `PII`, `IaaS`, `Social Media` |
| `disable` | Optional. A boolean indicating if secrets detections should be disabled. Default: `false` |
## Modifying the severity of findings after code analysis
You can modify the severity of findings after analysis using **modification rules**. Modification rules match findings and change attributes of the findings like severity or CVSS score.
note
Only Qwiet users with admin privileges may modify the severity of findings after analysis.
Modification rules match findings using filters that consider attributes like:
* Finding type (e.g., `vuln`, `secret`, `insight`)
* Category (e.g., `XSS`, `SQL Injection`)
* Severity (e.g., `critical`, `high`, `medium`, `low`)
To create modification rules:
1. Add a section to your configuration file called `finding-modifications`
2. Define individual modification rules with unique names of your choosing in the `finding-modifications` section.
3. Indicate the specific modification rules to include on analysis of the app(s) by including the `modify-findings` parameter under `app` in the config file:
```
- app:
name: tarpit_go
additional-findings:
- hsl-js-secrets
language: GO
modify-findings:
- my_modification_rule_name
```
 
### Modification rules example
To add a modification rule called `my_modification_rule` that changes all **critical Sensitive Data Leaks** to medium CVSS severity rating and a CVSS score of 5.0, add the following to your configuration file:
```
finding-modifications:
my_modification_rule_name:
filter:
category:
- Sensitive Data Leak
id:
- 97
type:
- vuln
severity:
- info
- medium
tags:
- key: cvss_score
value: 5
- key: cvss_31_severity_rating
value: medium
- key: severity
value: moderate
- key: some-custom-tag
value: todo
```
 
In all, a complete configuration file with an `app` section calling a specific rule and a `finding-modifications` section that define the rules will look like this (be sure to update the parameters used, such as the app `name`, which are `helloshiftleft` and `tarpit_go` in this example, as appropriate):
```
ngsast:
- app:
name: helloshiftleft
language: JAVA
policy: io.shiftleft/helloshiftleft
- app:
name: tarpit_go
additional-findings:
- hsl-js-secrets
language: GO
modify-findings:
- my_modification_rule
- default:
policy: io.shiftleft/defaultWithDict
finding-modifications:
my_modification_rule:
filter:
category:
- Sensitive Data Leak
id:
- 97
type:
- vuln
severity:
- info
- moderate
tags:
- key: cvss_score
value: 5
- key: severity
value: critical
- key: cvss_31_severity_rating
value: high
- key: some-custom-tag
value: todo
```
 
> Your modification rules **must** include all of the following parameters to maintain consistency: `cvss_score`, `severity` and `cvss_31_severity_ratings`.
### Applying modification rules
Once you've created your config file, Qwiet automatically updates your findings whenever you run `sl analyze`. This only affects your current and subsequent scans; it does not update previous scans.
## Validating the config file
Qwiet AI by Harness will validate the config file every time you attempt a code analysis if present. **If the config file has syntax or semantic errors, the analysis will fail.**
You can, at any time, manually validate the config file without running a code analysis by running the following:
```
sl ngsast validate
```
 
If the config file isn't located in the default location (i.e., you have a test file located elsewhere on your drive), you can use:
```
sl ngsast validate --config path/to/config/file.yaml
```
 
## Examples
We offer a tutorial on [how to modify the severity of findings for Python applications](/sast-and-sca/prezero/tutorials/modify-findings-python.md).
The following is an example that focuses on open redirect vulnerabilities; more specifically, the findings that meet the criteria specified will have their CVSS scores and severity levels modified and are flagged with `appsec_escalation`:
```
ngsast:
- app:
name: sl-java-test
language: JAVA # change to your app's language if necessary
modify-findings:
- open_redirect_modification_rule
finding-modifications:
open_redirect_modification_rule:
filter:
category:
- Header Injection
tags:
- key: cvss_score
value: 8
- key: severity
value: critical
- key: cvss_31_severity_rating
value: high
- key: reason
value: appsec_escalation
```
 
To modify the severity of findings using both the legacy severity values and the new values based on CVSS 3.1 ratings:
```
ngsast:
- app:
name: go-services # change your app name
modify-findings:
- set-severities
language: GO # change to your language
finding-modifications:
set-severities:
tags:
- key: cvss_score
value: 8.9
- key: severity # legacy severity rating
value: critical
- key: cvss_31_severity_rating # CVSS 3.1 severity rating
value: high
```
 