Scan your open source components (SCA) with Mend for GitHub Enterprise

Overview

Mend SCA is an SCA (Software Composition Analysis) solution of our Mend for GitHub Enterprise integration. Within Mend for GitHub Enterprise, Mend SCA performs an extensive analysis of the open-source components within your repositories for CVE vulnerabilities as well as license compliance.

Use Case

Mend for GitHub Enterprise SCA scans can be utilized in the following ways:

You, a developer, discover that an open-source component in one of your commits contains a vulnerability. You are responsible for fixing this and need a way to automate the remediation process.
You, a development team leader, are responsible for a repository and want to make sure there are no high-severity findings or license violations in your team’s open-source components. You want to monitor the overall state of the repository.

Mend’s Answer: With every valid commit, the SCA scan creates a Mend Security Check that provides details on vulnerabilities and license violations. The SCA scan creates GitHub Issues to help you keep track of these findings. Lastly, working alongside Remediate and Renovate, the SCA scan provides automated vulnerability remediation and dependency updates via GitHub Pull Requests. This is all done without you ever needing to leave GitHub Enterprise.

Getting It Done

Once you have installed the Mend for GitHub.com app, you will see a GitHub Pull Request (PR) created by the whitesource/configure branch appear in your integrated repositories. This is also referred to as the Mend for GitHub Enterprise "onboarding PR.":

The “onboarding PR” will contain the .whitesource file, which handles the configuration of your Mend for GitHub Enterprise scan. You can edit the .whitesource file before merging the onboarding PR to ensure that your first scan is configured appropriately for your repository:

Configure

The .whitesource file is used to configure Mend for GitHub Enterprise SCA scans. To learn more about the SCA-supported languages, configuration, and parameters, visit our Configure Mend for GitHub Enterprise for SCA documentation.

Run the Scan

Once you merge the onboarding PR into your default branch, this will start the first SCA scan on your repository.

Any concurrent SCA scans on your repository are initiated via a valid GitHub push command. A valid push command meets at least one of the following requirements:

One of the commits in the push command added/removed a source file(s) that has an extension supported by Mend. Refer to the Mend Languages page in order to find out whether or not a specific language and its extensions are supported.
One of the commits in the push command includes an addition/deletion/modification of the package manager dependency file(s). Refer to the list of supported dependency files to determine whether your dependency files are supported.
For Go, Python, JavaScript, or Maven projects, when the manifest file (go.mod, Pipfile, package.json, or pom.xml) is changed, the scan will be triggered only if the dependencies section is changed.

Note:

A push command may consist of multiple commits.
You can manually trigger a scan for several repositories at once.

Re-run a prior Mend SCA scan via GitHub check

You can re-run a previously failed Mend Security Check on a commit using the re-run options within the GitHub checks. When clicking on Re-run, an SCA scan will run again on the relevant commit, and both the Mend Security Check and Mend License Check (if the license scan is enabled) will be updated:

Notes:

Re-runs can only be initiated from the Mend Security Check, however, the Mend Security Check, Mend License Check, and Mend IaC Check will be updated from the re-run.
When initiating a re-run of a scan, it will retrigger all SCA check runs in the app, even successful ones. For example, if the Mend License Check succeeded and the Mend Security Check failed, the re-run of a scan will update both check runs.
We only allow the most recent valid push on the base branch to be retried. Meaning, neutral checkruns don’t count toward this and checkruns before neutral checkruns can be retried. This restriction is only for base branches, feature branches can be retried, regardless of age.
Only check runs created after this code is deployed can be retried. Meaning if the user requests a retry of an old check run it will be ignored. This is because new check runs contain some hidden information necessary for the retry.
There is a 5-minute period that prevents a user from pressing the “Re-run” button more than once in 5 minutes. Any attempts within the 5-minute period will be ignored until the cooldown expires.

View the Scan Status

Once the scan is started, there is a GitHub check created called:

Mend Security Check: For vulnerabilities in SCA components
Mend License Check: For SCA components that contain license violations on policies defined by your organization

Within GitHub, in the Code > commits page of your repository, you can view the status and results of each scan. Click a specific check icon in order to view the Mend check:

Mend Security Check (SCA)

The following status indicators are available as feedback on the head commits for the Mend Security Check:

Queued: SCA Scan has not begun and is scheduled to begin.
In progress: (Orange Circle Icon) The SCA scan is currently running:
Neutral: (Gray box icon) The SCA scan did not run because a valid scan initiation action did not occur:

Note: Mend Security Checks in non-base branches that would have been considered a Neutral check will instead always have a Failed status if the previous check failed. For example:

Success: (Green Checkmark icon) The scan is completed and this status can be displayed in two scenarios:
- When the parameter vulnerable.check.run.conclusion.level is set to success or failure, and a 'success' status is provided for the scan, since no vulnerabilities were found and no errors occurred during the scan for this head commit. In this case, the merging of a pull request that includes this commit to another branch in the repository is automatically approved.
- When the parameter vulnerable.check.run.conclusion.level is set to success. In this configuration, even a 'failed' status for a head commit's scan is converted to 'success'. In this case, the merging of a pull request that includes this head commit to another branch in the repository is automatically approved.
Failure: (Red “X” icon) Default behavior for all completed SCA scans. When the parameter 'vulnerable.check.run.conclusion.level' is set to ''failure', all head commits that fail the scan due to the Mend Security Check display a 'failure' status. In this case, only the administrator of the repository can approve merging a pull request that includes this head commit to another branch in the repository, and therefore, it will not be automatically merged:

Note: The Failure status can also occur when an error (i.e. scan timeout) that occurred during the scan.

Mend License Check

The following commit status indicators are available as feedback on the head commits for the Mend License Check:

Neutral: (Gray box icon) The license scan did not run because a valid scan initiation action did not occur:
Success: (Green Checkmark icon) No license policy violations were detected:
Failure: (Red “X” icon) One or more license policy violations were detected:

View the Scan Results

Once your Mend for GitHub Enterprise scan has been completed, there are multiple resources to review your results. For more information to help you in understanding your findings, visit our View the results of your Mend for GitHub Enterprise SCA scan documentation.

Inventory post-scan

Mend continuously researches new vulnerabilities and updates its vulnerability database with these findings. For these newly discovered vulnerabilities to be reflected in projects as soon as possible, Mend initiates a post-scan process for all integrated projects every 6 hours and additionally at 01:00 UTC. Mend will create or update issues and pull requests for vulnerabilities that were added to the database during this period of time.

This is an automated procedure, and no action from the user is required.