Skip to content

CxSCA Integration

Jump to bottom
AvivCx edited this page Apr 12, 2021 · 24 revisions

Configuration

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

Adding the CxSCA Configuration

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.checkmarx.net
  apiUrl: https://api-sca.checkmarx.net
  accessControlUrl: https://platform.checkmarx.net
  tenant: your-tenant
  username: username
  password: xxxxx
  team: "/CxServer/MyTeam/SubTeam"

To use an European tenant:

In addition, add one of the CxSCA sections with the following properties:

sca:
  appUrl: https://eu.sca.checkmarx.net
  apiUrl: https://eu.api-sca.checkmarx.net
  accessControlUrl: https://eu.platform.checkmarx.net
  tenant: your-tenant
  username: username
  password: xxxxx
  team: "/CxServer/MyTeam/SubTeam"

Bug-Trackers

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.

Opening Tickets in Jira

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:

Filters

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

Thresholds

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.

Feature SCM Supportability

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

  • ADO
  • GitHub
  • BitBucket

Configuration changes required – via application.yml

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

On the supported SCM sections: (e.g. GitHub section)

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

Threshold configuration – General

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:

Policy Management

SCA supports with policy management control. Each policy can be customized by defining number of custom rules and conditions in which, if getting violated, can break a build. On the creation process or after it, a policy can be defined with 'Break build' flag or not.

When performing a scan, if a defined policy is getting violated, Cx-Flow will fail the pull request and it will be marked as failed.

  • Violated policy occurs when at least one rule condition is getting violated AND when policy 'Break Build' flag in on.
  • In case of a CLI scan which violated a policy: Cx-Flow will fail with exit code 10.
  • If current scan violated any active SCA thresholds and also violated a policy, policy break build has the top priority.

Configuration As Code

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
    • team (needs to be set with none empty value)


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,
		"team": "/CxServer/MyTeam/SubTeam"
	}
}

SCA Scans From Command Line

CxFlow can initiate SCA scans with command line mode


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:

CxFlow can open security tickets upon SCA scan results

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)

CxFlow can init git scan or upload zip folder to scan by sca:

  • git scan:
    • --scan --enabled-vulnerability-scanners=sca --app=MyApp --cx-project=test --repo-url=my-repo-url --repo-name=my-repo --branch=main --github
  • local zip scan:
    • --scan --app=MyApp --cx-team="my-team" --cx-project="project" --f="/Users/myProjects/project"
  • get latest scan results:
    • --project --app=MyApp --cx-team="my-team" --cx-project="project"
enabledZipScan: true

Additional configuration in SCA zip scan flow - Include source files

  • Default value set to false, In order to change the default CxFlow SCA zip scan behavior, the next configuration property should be added underneath the sca configuration section:
includeSources: true

SCA project team assignment

SCA project team assignment with CxFlow is performing on the SCA project creation stage. In order to set a project team, the next configuration property should be added underneath the sca configuration section:

team: /team

Or within a tree hierarchy:

team: /MainTeam/SubTeam
  • In order to declare a team within a tree hierarchy, make sure to use the forward slash ('/').
  • Declaring not existing team or team path will be resulted with 400 BAD REQUEST error.
Clone this wiki locally