Initiating a Scan

A Mend scan is initiated via a valid push. A valid push 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/modification of the package manager dependency file(s).
  Refer to the list of supported dependency files to find out whether your dependency files are supported.

NOTE:

• A push command may consist of multiple commits.

• You can manually trigger a scan for several repositories at once. Refer to the Global Repo Configuration document.

Inventory post-scan

Mend continuously researches new vulnerabilities and updates its vulnerability database with these findings. In order that these newly-discovered vulnerabilities be reflected in projects a soon as possible, Mend initiates a post-scan process for all integrated projects at 01:00 UTC and opens new issues for vulnerabilities that were added to the database in the previous 24 hours.

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

Viewing Details of the Scan

Results can be viewed in the following places:

• The Work items subsection of the project’s Boards section.

• The commits comments inside each specific commit

• The Mend UI

• Via email notifications

Viewing the Work items section

If you are performing Pull Requests or push commands via the Web browser, refresh your Web browser in order to view the work items that were generated by Mend. 
NOTE: It may take a number of minutes for the work items to be scanned and displayed after a valid push command is initiated.

The Work Items section displays all the issues that the Mend Integration detected with the security vulnerability tag and a tag indicating a repository in which the issue was found. These proprietary labels indicate that a security vulnerability was detected by Mend. 
The created Work Item type depends on the Process that was used in the project, as follows:

• Basic, Agile, and CMMI: Issue

• Scrum: Impediment

As part of your workflow, you have the option to manually add a relevant tag(s) to specific work items, and close work items that were resolved.

Work items that were manually closed will not be re-opened during future Mend scans unless their tag and/or name have been changed.

...

Viewing Details of an Issue

See here for more information.

Viewing Mend Security Checks

Status Check messages are displayed for each pull request. Clicking a specific security check message opens a related head commit with detailed information about found vulnerabilities:

...

The security report displays all the vulnerabilities that were found in descending order according to the severity and CVSS score. The following information is displayed for each vulnerability:

• CVE: A link to the related CVE page for the vulnerability. Displayed in a collapsible format (click the arrow to expand/collapse for more information regarding the vulnerability).

• Severity: Overall score of the severity (High, Medium or Low).

• CVSS Score

• Vulnerable Library

• Suggested Fix 

• Issue: A link to the Mend issue that was generated for the vulnerability. 

Types of Indicators

The following status indicators are available as feedback on a head commit:

• Queued: Scan has not begun and is scheduled to begin.

• In progress: Scan is in progress.

• Completed: Scan completed with one of the following conclusions:

  • Success: When the parameter 'vulnerable.check.run.conclusion.level' is set to 'success', the status of the head commit is always success  A 'Success' status is displayed for the commit even when it fails.

  • Failure: Default for all completed scans. When the parameter 'vulnerable.check.run.conclusion.level' is set to 'failure' (default), the status of a 'failed' head commit is 'failure', and a policy for approving merging pull requests that include failed head commits with another branch in the repository is enforced. Note that a 'failed' status can be caused due to security vulnerabilities or due to an error that occurred during the scan.

  • Neutral: Conclusion occurs when the push command was not valid.

Samples of Check Status Indicators 

In Progress

The following is a sample of a 'Running' status, which indicates that the security check is currently scanning the head commit.

...

Completed with Success Conclusion

When no vulnerabilities are found and no errors occurred during the scan, Mend will display the following commit status, and a security report indicating that no vulnerabilities were detected.

...

Completed with Failure Conclusion

All head commits that fail the scan due to the security check detecting vulnerabilities or due to an error that occurred during the scan will display a failed commit status.
The following screenshot displays a failure indicator for a head commit

...

Viewing Mend License Checks

On the Commits page, you can view the status and results of each scan. Open a specific commit in order to view the Mend check.

Types of Indicators

The following commit status indicators are available as feedback on the head commits:

• Success: No license policy violations were detected. 

• Failed: One or more license policy violations were detected during the Mend scan.

Viewing Mend IaC Checks

On the Commits page, you can view the status and results of each scan. Open a specific commit in order to view the Mend check.

Types of Indicators

The following commit status indicators are available as feedback on the head commits:

• Success: No license policy violations were detected. 

• Failed: One or more license policy violations were detected during the Mend scan.

Supported Configuration Files

Terraform, CloudFormation, Kubernetes, ARM Templates, Serverless, and Helm

Viewing Details in the Mend UI

• In the Mend UI, Mend projects will have the same name as the corresponding Azure Repos repository, with an "AZ_" prefix, unless otherwise specified in the .whitesource file using a project token.

• The name of the Mend product will be your Azure Repos Project name preceded by "AZ_".

Bot-user maintenance

Integration

For the Mend integration to work with Azure Repos, it needs to have a PAT created by the user with access to the integrated organizations. Mend for Azure Repos will use this PAT to perform its features (repository scanning, work items and pull requests creation, etc.) on behalf of the user who provided the PAT. We recommend having a separate bot-user created solely for this purpose - this process is described in the installation documentation.

When Mend for Azure Repos receives the PAT of a bot-user it creates Service Hooks in each project of each integrated organization. These hooks are triggers for the actions of code pushes and pull requests creation or updating. They can be found in the Project settings → Service hooks. For each hook, there is a history of actions logged, which is convenient for debugging.

Activity

As noted previously, all actions of the Mend for Azure Repos in the integrated organization are done by the bot-user. Here are some examples:

...

Maintenance

The PAT of the bot-user has an expiration date set during its creation. Two weeks before the expiration, there will be an alert work item created in the whitesource-config/whitesource-config repository. For integration to continue working correctly, the PAT needs to be updated, which can be done in several ways:

• Change the expiration date of the existing PAT

  • Log in as a bot-user.

  • Open User settings → Personal Access Tokens.

  • Select existing PAT and click on "Edit".

  • Set the new expiration date and save the token.

• Create a new PAT

  • Log in as a bot-user.

  • Open User settings → Personal Access Tokens.

  • Delete the existing PAT.

  • Create a new PAT following these instructions (step 3).

Synchronization

Azure Repos does not provide any triggers on some events. Thus we need to do a periodical synchronization with integrated organizations to keep up with the changes. There are two ways for synchronization:

• Automated - each hour, all projects are synchronized.

• Manual - you can go to Integrate → Developer Integrations → Mend for Azure Repos in the Mend application and press "Sync Projects"

...

List of the events that require synchronization:

...

Bot-user received access to a new organization

...

A new project was created in the organization

...

This page is available at: https://docs.mend.io/bundle/integrations/page/using_mend_for_azure_repos.html