Skip to main content

SCA Configuration Options

The following table shows the configuration options available for the SCA scanner. These configuration options can be applied on the Account > Project > Scan levels. These configurations can be set via the web application (UI), CLI or API, as shown in the table below.

Notice

CLI flags are submitted on the scan level with the scan create command. API configs can be configured on the account or project level using the Configuration API or on the scan level as part of the request body of the POST /scans API. When using the POST /scans API the scan.config.sca prefix is left out.

Parameter

Values

Notes

CLI

API

Folder/file filter

Allow users to select specific folders or files that they want to include or exclude from the code scanning process.

  • Including a file type - *.java

  • Excluding a file type - !*.java

  • Use “,” sign to chain file types.

    for example: *.java,*.js

  • The parameter also supports including/excluding folders.

  • regex is not supported.

Notice

For details on the filter application logic, see here.

--sca-filter <string>

scan.config.sca.filter

Example:

  {
    "key": "scan.config.sca.filter",
    "value": "*.java,*.js",
    "allowOverride": true
  }

Exploitable Path

Toggle On/Off

When Exploitable Path is activated, scans that use the SCA scanner will identify whether or not there is an exploitable path from your source code to the vulnerable 3rd party package.

Learn more about Exploitable Path.

--sca-exploitable-path <string>

scan.config.sca.ExploitablePath

Example:

  {
    "key": "scan.config.sca.ExploitablePath",
    "value": "true",
    "allowOverride": true
  }

Exploitable Path Configuration

Radio button selection

The Exploitable Path feature uses queries in the SAST scan of your project to identify exploitable paths to vulnerable 3rd party packages. Therefore, it is always necessary to run a SAST scan on the project in order to get results for Exploitable Path.

Whenever you run a Checkmarx One scan with both the SAST and SCA scanners selected, Exploitable Path uses the results of the current SAST scan for analysis. When you run a Checkmarx One scan with only the SCA scanner selected, if SAST results exist within your designated time-range those results are used. Otherwise, Exploitable Path won't be analyzed.

Select one of the following configurations:

  • Use SAST scans for past _ day/s - specify the number of days for which results from a historic SAST scan will be used for Exploitable Path. If no scan was run within the specified period, Exploitable Path won't be analyzed.

    Warning

    Not fully supported in all environments. The default value of one day may be applied automatically.

  • Do not use existing SAST scans - Whenever you run a Checkmarx One scan with only the SCA scanner selected the Exploitable Path won't be analyzed.

--sca-last-sast-scan-time <integer> (Default: 1)

scan.config.sca.LastSastScanTime

Example:

  {
    "key": "scan.config.sca.LastSastScanTime",
    "value": "25",
    "allowOverride": true
  }

Vulnerability Comparison Mode 1]

Project-Wide (default) or Branch-Based

Determines what is used as the base-line for determining whether or not a vulnerability is a New finding in the current scan.

  • Project-wide - compares to the most recent scan of any branch of the project.

  • Branch-based - compares to the most recent scan of the specific branch that was scanned.

scan.config.sca.vulnerabilityComparisonMode

Example:

  {
    "key": "scan.config.sca.vulnerabilityComparisonMode",
    "value": "Branch-Based",
    "allowOverride": true
  }

Java Language Version 1]

8,11,17, 21 or 25

Specify the Java version used for dependency resolution for gradle package manager. This version does not affect Java version used for maven resolution. If not defined, gradle scans will run with Java version 21 by default.

scan.config.sca.javaLanguageVersion

Example:

  {
    "key": "scan.config.sca.javaLanguageVersion",
    "value": "17",
    "allowOverride": true
  }

Python Language Version 1]

2.7,3.11,3.12, 3.13 or 3.14

Specify the Python version used for dependency resolution for pip and poetry package managers. Poetry does not support Python prior to version 3, if version 2.7 is supplied, the default version is used instead. If not defined, scans will run with Python version 3.13 by default.

scan.config.sca.pythonLanguageVersion

Example:

  {
    "key": "scan.config.sca.pythonLanguageVersion",
    "value": "3.12",
    "allowOverride": true
  }

Scan SBOM2]

 

Run an SCA scan on a specific SBOM file. Learn more about scanning SBOM files here.

--sbom-only

sbom

For exact syntax, see Scanning from an SBOM in our API documentation portal.

1] These configurations are only available on the tenant or project level. They can't be set on the scan level.

2] This configuration is only available on the scan level.

Filter Application Logic

  • Filters are applied in the order they appear in the expression.

  • When both include and exclude filters are used, include filters must come first.

Why this order matters

If the include filters come first (correct order) the system starts with an empty selection set, then adds content from the original sources based on the include filters. The exclude filters are then applied to that populated set, successfully removing any unwanted items. The resulting, correctly filtered selection set is what gets sent for scanning.

If the exclude filters are applied first (incorrect order), the system begins with an empty selection set and attempts to remove content - which has no effect. Only afterward does it apply the include filters, adding content from the source set to the selection set. This results in the exclude rules being effectively ignored.

In this section: