Skip to content



Checkmarx is a Static Application Security Testing (SAST) tool to analyze i.e. Java- or TypeScript, Swift, Golang, Ruby code, and many other programming languages for security flaws based on a set of provided rules/queries that can be customized and extended.

This step by default enforces a specific audit baseline for findings and therefore ensures that: No 'To Verify' High and Medium issues exist in your project Total number of High and Medium 'Confirmed' or 'Urgent' issues is zero * 10% of all Low issues are 'Confirmed' or 'Not Exploitable'

You can adapt above thresholds specifically using the provided configuration parameters and i.e. check for absolute thresholds instead of percentage whereas we strongly recommend you to stay with the defaults provided.


name mandatory default possible values
avoidDuplicateProjectScans No false true, false
checkmarxCredentialsId Yes
filterPattern No !**/node_modules/**, !**/.xmake/**, !**/*_test.go, !**/vendor/**/*.go, **/*.html, **/*.xml, **/*.go, **/*.py, **/*.js, **/*.scala, **/*.ts
fullScanCycle No 5
fullScansScheduled No true true, false
generatePdfReport No true true, false
incremental No true true, false
password Yes
preset No
projectName Yes
pullRequestName No
script Yes
serverUrl Yes
sourceEncoding No 1
teamId No
teamName No
username Yes
verbose No false true, false
vulnerabilityThresholdEnabled No true true, false
vulnerabilityThresholdHigh No 100
vulnerabilityThresholdLow No 10
vulnerabilityThresholdMedium No 100
vulnerabilityThresholdResult No FAILURE FAILURE
vulnerabilityThresholdUnit No percentage
  • avoidDuplicateProjectScans: Whether duplicate scans of the same project state shall be avoided or not
  • checkmarxCredentialsId: The technical user/password credential used to communicate with the Checkmarx backend
  • filterPattern: The filter pattern used to zip the files relevant for scanning, patterns can be negated by setting an exclamation mark in front i.e. !test/*.js would avoid adding any javascript files located in the test directory
  • fullScanCycle: Indicates how often a full scan should happen between the incremental scans when activated
  • fullScansScheduled: Whether full scans are to be scheduled or not. Should be used in relation with incremental and fullScanCycle
  • generatePdfReport: Whether to generate a PDF report of the analysis results or not
  • incremental: Whether incremental scans are to be applied which optimizes the scan time but might reduce detection capabilities. Therefore full scans are still required from time to time and should be scheduled via fullScansScheduled and fullScanCycle
  • password: The password to authenticate
  • preset: The preset to use for scanning, if not set explicitly the step will attempt to look up the project's setting based on the availability of checkmarxCredentialsId
  • projectName: The name of the Checkmarx project to scan into
  • pullRequestName: Used to supply the name for the newly created PR project branch when being used in pull request scenarios
  • script: The common script environment of the Jenkinsfile running. Typically the reference to the script calling the pipeline step is provided with the this parameter, as in script: this. This allows the function to access the commonPipelineEnvironment for retrieving, e.g. configuration parameters.
  • serverUrl: The URL pointing to the root of the Checkmarx server to be used
  • sourceEncoding: The source encoding to be used, if not set explicitly the project's default will be used
  • teamId: The group ID related to your team which can be obtained via the Pipeline Syntax plugin as described in the Details section
  • teamName: The full name of the team to assign newly created projects to which is preferred to teamId
  • username: The username to authenticate
  • verbose: verbose output
  • vulnerabilityThresholdEnabled: Whether the thresholds are enabled or not. If enabled the build will be set to vulnerabilityThresholdResult in case a specific threshold value is exceeded
  • vulnerabilityThresholdHigh: The specific threshold for high severity findings
  • vulnerabilityThresholdLow: The specific threshold for low severity findings
  • vulnerabilityThresholdMedium: The specific threshold for medium severity findings
  • vulnerabilityThresholdResult: The result of the build in case thresholds are enabled and exceeded
  • vulnerabilityThresholdUnit: The unit for the threshold to apply.

Step Configuration

We recommend to define values of step parameters via config.yml file.

In following sections of the config.yml the configuration is possible:

parameter general step/stage
avoidDuplicateProjectScans X
filterPattern X
fullScanCycle X
fullScansScheduled X
generatePdfReport X
incremental X
password X
preset X
projectName X
pullRequestName X
serverUrl X X
sourceEncoding X
teamId X
teamName X
username X
verbose X
vulnerabilityThresholdEnabled X
vulnerabilityThresholdHigh X
vulnerabilityThresholdLow X
vulnerabilityThresholdMedium X
vulnerabilityThresholdResult X
vulnerabilityThresholdUnit X