Integration with CxSCA - RDR3/cx-flow GitHub Wiki

• Configuration
• Bug-Trackers
• Filters
• Thresholds
• Configuration As Code
• SCA Scans From Command Line

CxSCA scans can be triggered based on WebHooks using CxFlow. For instructions on registering CxFlow to WebHook, refer to WebHook Registration.

Select the vulnerability scanner by adding the following property to the CxFlow section. You can choose to trigger a CxSAST scan a CxSCA scan or both. The example below has been set to trigger both CxSCA and CxSAST.

enabled-vulnerability-scanners:
    - sca
    - sast

In addition, add a CxSCA section with the following properties:

sca:
  appUrl: [https://sca.scacheckmarx.com](https://sca.scacheckmarx.com)
  apiUrl: [https://api.scacheckmarx.com](https://api.scacheckmarx.com)
  accessControlUrl: [https://platform.checkmarx.net](https://platform.checkmarx.net)
  tenant: your tenant name
  username: userxx
  password: pasxx

SCA integration supports tickets management with the following bug trackers :

• Jira
• GitLab
• Azure
• Github
  The tickets format is the same for each of the bug trackers.

CxFlow can open Jira tickets according to the CxSCA scan results. Currently, CxFlow opens a limitation per vulnerability severity found in a package.

+++ The section below is still under development +++

CxFlow opens a separate ticket for each vulnerability type found in a package of a specific project.

The ticket is structured as follows:

<Severity> Risk Vulnerability:  <**vulnerabilityId**> in <**package name and version**> @ <**Repo.branch**>

CxFlow SCA scans Jira's tickets based on both vulnerabilityId & PackageId.

This means that each vulnerabilityId with a different packageId has its own ticket.

The following correlation exists between pull requests processed via GitHub and Jira:

• Red section: There are two vulnerabilities, each with the same Id, but each one has a different package. Therefore two matching tickets are expected on the Jira side.
• Blue section:There are four vulnerabilities, each with a different Id, but each one has the same package. Therefore four matching tickets are expected on the Jira side.

Jira ticket example:

SCA filtering has 2 sections: filter-severity & filter-score:

• Filter Severity: is a list type and can have multiple values [high, medium, low] regardless the order and not case sensitive. When applying this filter the SCA results vulnerabilities will be sanitized according to the severities defined filter.
  • Special cases:
    • Filter not defined: in that case the severity filter won’t be applied and the returned results will contain all scan severities.
    • Unrecognized filter defined: in that case this filter value will be ignored.
• Filter Score: is a double value starting from ‘0.0’.
  • Special cases:
    • Negative value will be ignored.
    • Filter not defined: in that case the score severity won’t be applied and the returned results will contain all scan scores.
• Combined filters: In case both severity & score filter were defined, the returned results will contain only vulnerabilities which apply both conditions.
  • Backwards Compatibility: in case none of the filters were defined, the returned results won’t be sanitized and all scan’s results will be returned

Cx-Flow supports 2 kind of thresholds:

• Severity Thresholds (count per severity):
• Score Threshold
  When performing a scan, if at least one of the thresholds is violated, Cx-Flow will fail the pull request and it will be marked as failed.

The thresholds feature is supported in the following source-code managements:

• ADO
• GitHub
• BitBucket

Thresholds are configured in the application.yml within the sca section:

• Define the block-merge with true value
• Define the error-merge with true value

Cx-Flow uses the thresholds to ease its (no) tolerance of findings.

• Severity – this threshold tells Cx-Flow what is the maximum number of findings (per severity) allowed, before failing the pull request.
• Score – this threshold tells Cx-Flow what is the maximum acceptable score (of all findings), before failing the pull request.
  Note:
• if only one threshold type is defined, the other one will be ignored
• that the thresholds are on findings and not on issues.
• if no threshold is defined, cx-flow will fail the pull request if there is any finding.
• thresholds are checked after the execution of filters.
  An example for pull request failure:

CxFlow supports configuration as code for CxSAST and CxSCA scans.
Available overrides for SCA properties:

• additionalProperties:
  • vulnerabilityScanners
• sca:
  • appUrl
  • apiUrl
  • accessControlUrl
  • tenant
  • thresholdsSeverity
  • thresholdsScore
  • filterSeverity
  • filterScore
    Example for SCA config file content:

{
    "additionalProperties": {
        "cxFlow": {
			"vulnerabilityScanners": ["sca", "sast"]
        }
    },
	"sca": {
		"appUrl": "sampleAppUrl",
		"apiUrl": "sampleApiUrl",
		"accessControlUrl": "sampleAccessControlUrl",
		"tenant": "sampleTenant",
		"thresholdsSeverity": {
			"HIGH": 10,
			"MEDIUM": 6,
			"LOW": 3
		},
		"thresholdsScore": 8.5,
		"filterSeverity": ["high", "medium", "low"],
		"filterScore": 7.5
	}
}

There are 2 options to add SCA scan to the cli run:

• Add scanner argument to the cli command: --scanner=sca
• Add sca to the active vulnerabilities scanner in cxflow app.yml:

In order to open SCA security tickets, set the bug tracker in cxflow app.yml file or in add the argument with your bug tracker type (for example: --bug-tracker=Jira)

• git scan:
  • -scan --scanner=sca --app=MyApp --cx-project=test --repo-url=my-repo-url --repo-name=my-repo --branch=master --github
• local zip scan:
  • -scan --app=MyApp --cx-team="my-team" --cx-project="project" --f="/Users/myProjects/project"