Execution

WebHook

Refer to Webhhok Registration for instructions on registering for WebHooks. To launch the WebHook WebService, select the relevant jar file and run the following command:

java -jar cx-flow-<ver>.jar

The relevant configuration is determined by the application.yml file that resides in the same directory as the jar file, or if an explicit configuration is set to override as defined in the command line as follows:

java -jar cx-flow-<ver>.jar --spring.config.location=/path/to/application.yml --web

Docker

The CxFlow docker images on Docker Hub checkmarxts/cxflow contain the latest and previous versions of CxFlow.

docker pull checkmarxts/cxflow docker run --env-file=.checkmarx --name=cxflow --detach -p <host port>:8080 checkmarxts/cxflow

The env-file provides the necessary overrides during the bootstrap process - urls, credentials, etc - sample below. Alternatively on *Unix hosts, you can use --env-file <(env)` to move the entire environment from the host into the Docker container.

BITBUCKET_TOKEN=<user>:<token>

BITBUCKET_URL=http://xxxxxx:7990

BITBUCKET_API_PATH=/rest/api/1.0/

BITBUCKET_WEBHOOK_TOKEN=XXXXXXX

CHECKMARX_BASE_URL=https://xxxxxxxx

CHECKMARX_CLIENT_SECRET=XXXXXXXXXX

CHECKMARX_PASSWORD=XXXXXXXX

CHECKMARX_USERNAME=XXXXXXXX

CHECKMARX_TEAM=\CxServer\SP\Checkmarx

GITHUB_TOKEN=XXXXXXXXXXXXXX

GITHUB_WEBHOOK_TOKEN=XXXXXXXX

GITLAB_TOKEN=XXXXXXXX

GITLAB_WEBHOOK_TOKEN=XXXXXXXX

JIRA_TOKEN=XXXXXXX

JIRA_USERNAME=XXXXXX

JIRA_URL=https://XXXXXXXXX

JIRA_PROJECT=SS

Note: In order to highly customize the yaml configuration for CxFlow in a Docker environment, use this docker image as a base and add custom configuration. Alternatively build from source (Docker files are found in the git repository).

Command Line

CxFlow can be integrated via command line using several ways. The table below lists command line arguments and flags to help drive the different execution flows and overrides.

Option	Description
--spring.config.location	Override the main application.yml/properties file for the application. Defaults to the application.yml packaged within the jar
--pars	Indicates that a result XML file from Checkmarx is provided (–f is also mandatory). No value provided (flag)
--project	Indicates that we would like to retrieve the latest scan results for a given team/project and provide feedback (defect / issue tracking). No value provided (flag)
--batch	Indicates that the entire instance or a given team is iterated through and the latest results are retrieved for each project and feedback is provided (defect/issue tracking)
--cx-team	Used to override the team that is used as a base team (optionally defined globally in the yaml configuration). This team is used when creating a project in Source/Scan (zip) mode as well as the team to use when retrieving latest project results in project/batch modes (--project/--batch)
--namespace	Repository group (Gitlab)/organization (Github)/namespace (BitBucket). Used as higher level grouping of repositories. Used along with repo-name and branch for tracking purposes (Jira only). If these three components are not present, an application attribute must be passed (--app). These values are stored in a tracking label within Jira. This value is also stored in the body of the issue.
repo-name	Name of the repository. Used along with repo-name and branch for tracking purposes (Jira Only). If these three components are not present, application attribute must be passed (--app). These values are stored in a tracking label within Jira. This value is also stored in the body of the issue.
--branch