Repository Integrations - Understanding Your Pull Request's Security Report
This article covers how to kick off a Mend scan on a pull request using Mend Repo Integrations and the information you can find in the resulting Mend Security Check. This article uses examples from the GitHub.com integration.
Initiating a Mend Scan on a Pull Request
Mend scans will automatically run on any pull request you generate that includes a commit that meets one of the following criteria:
It modifies a package manager manifest file (examples: pom.xml, package.json, go.mod)
It modifies the repository’s .whitesource file
It adds or removes a source file
If your pull request meets one of the above criteria, you will see the following check run on the pull request’s page. Click ‘Details’ to review the Security Report.
Note that the Mend Security Check reflects the outcome of the latest commit. If the last commit does not meet one of the criteria above, the Security Check will appear as a neutral check.
For example, in the below PR, package.json is updated (which is considered a valid push to initiate a Mend scan), then, README file is updated in the repository (which is not considered a valid push). This causes the Mend Security Check to appear as a neutral check on the pull request:
To view the details of the Mend Security Check that ran due to the valid push, navigate to the commit tab on the pull request. Then select the check mark or X next to the commit that contains the valid push to view the Security Report:
Reviewing the Security Report
Below is an example of a Security Report for a pull request that upgraded the version of a vulnerable library. This pull request resolved seven vulnerabilities, but introduced six vulnerabilities as the new version of the library contains other vulnerabilities.
“New Vulnerabilities” will include all of the new vulnerabilities that your pull request is introducing to your repository. These will show up in the Mend UI once you merge your pull request into the repository’s default branch (or a branch specified by the ‘baseBranches’ parameter in the .whitesource file). Merging this pull request will also cause issues to be generated for each vulnerability in the base branch.
“Remediated Vulnerabilities” will include all of the vulnerabilities that your pull request has remediated. Once you merge your pull request into the repository’s default branch (or branch specified by the ‘baseBranches’ parameter), the vulnerabilities will show as resolved in the Mend UI. Merging this pull request will also cause any issues associated with the vulnerabilities you resolved to be auto-closed in the base branch.
“Base Branch Total Remaining Vulnerabilities” indicates the number of vulnerabilities that are currently affecting the base branch of your repository. This is the number of vulnerabilities in the base branch before you merge your pull request into the base branch. In the example above, the “base branch total remaining vulnerabilities” will change to 14 after the pull request is merged since seven vulnerabilities were resolved and six were introduced with this pull request.
“Total Libraries Scanned” indicates the number of libraries that were found in the scan completed on the pull request.
Does the Pull Request’s Data Get Sent to the Mend UI?
No, only the scans of the default branch or the branches specified in the ‘baseBranches’ parameter send data that is visible in the Mend UI. Some scan data is sent to Mend about scans on other branches and pull requests, however, this data does not persist in your Mend organization. This data that is sent includes information such as library names, sha-1 values of files, and other information used to identify the open source components in the project. This data does not include any source code, binaries, or contents of any files.