In your application's repository, you can include a file named ngsast.yaml that contains configuration information for how you want ShiftLeft CORE's NG SAST 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
- Your analysis configuration once and save for future use instead of providing parameters before each code analysis
- Modification rules that allow you match findings and change its attributes (e.g., severity or CVSS score)
Adding a Configuration File
To use a configuration file, you will need to:
- Create a configuration file
- Modify your configuration file
- Ensure that your configuration file is in the root folder of your application's repository; NG SAST 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:
Once ShiftLeft generates the necessary configuration file for you, you can edit to it 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:
The config file is divided into two sections:
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 Insights or Secrets in your code).
In the example above, the
ngsast portion of the file contains configuration information for two applications:
helloshiftleft-js. There is also a
default section, which 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
additional-findings configuration with the custom ID of
hsl-js-secrets. The configuration for
helloshiftleft-js also requires additional findings analysis -
insights - but with a default configuration (
insights is not a custom ID).
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
Different sections of the configuration file accept different parameters for defining how the code analysis should run.
The following is a list of parameters you can include in the
ngsast section of your configuration file.
|The unique name of the application. Required for the |
|Optional. The language of the application. Accepted values: |
|Optional. The custom policy to use during analysis. Default: io.shiftleft/defaultWithDict|
|Optional. The additional analyses to be run in NG SAST. Accepted value: |
Additional NGSAST Parameters
The following is a list of parameters you can include in your
|The default configuration for analyzing for |
|A default configuration with a name of your choice, eg., |
The following is a list of parameters you can include in the
secrets portion under
|Optional. Entropy level to be used during the hard-coded credentials analysis. The accepted value is between 0 and 1 (inclusive). Default: |
|Optional. A Boolean parameter indicating whether the literals returned in the results should be obfuscated. Default: |
|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 |
|Optional. A list of paths that you want included during secrets detection. Accepts wildcards; use |
|Optional. A list of paths that you want excluded during secrets detection. Accepts wildcards; use |
insights do not allow for further customization.
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.
Only ShiftLeft 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.,
- Category (e.g.,
- Severity (e.g.,
To create modification rules:
- Add a section to your configuration file called
- Define individual modification rules with unique names of your choosing in the
- Indicate the specific modification rules to include on analysis of the app(s) by including the
appin the config file:
Modification Rules Example
To add a modification rule called
my_modification_rule that changes all critical Sensitive Data Leaks to moderate severity and a CVSS score of 5.0, add the following to your configuration file:
In all, a full 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 parameteres used, such as the app
name, which are
tarpit_go in this example, as appropriate):
Applying Modification Rules
Once you've created your config file, ShiftLeft automatically updates your findings whenever you run
sl analyze. This affects your current and subsequent scans only; it does not update prior scans.
Validating the Config File
NG SAST 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:
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: