Consuming Mend Pipeline Results

This document is part of the Mend Rollout Guidiance.

The content is this document is intended for users who have already set up Mend Scanning in the pipeline. If you are not currently scanning with Mend please see the following documents:

Mend Platform Rollout Overview
Setting Mend UI for Pipeline Scanning
Scanning Your Applications in the Pipeline

While the Mend CLI provides an output of the scan results in the pipeline. These results often do not meet the needs of every stakeholder. It is important to implement the proper result consumption method for each stakeholder so you can drive the most value out of Mend.

This section will cover the recommended methods of results consumption for pipeline scanning.

Report Generation

Generating reports is the main way of providing information from Mend to stake holders.

Reports from the Mend UI

Mend has several reports available out of the box that can be downloaded from the UI. The contents of these reports are not customizable but they come in various common formats such as CSV, PDF, or JSON.

Reports in the Mend Platform

Custom Scripts with the Mend API

Custom scripts allow you to completely customize the reporting you are getting out of Mend. These scripts can be called from pipeline right after the scan has completed to take the results of the scan, transform the data as needed and stored as an artifact or sent to the right stakeholders through email. These scripts need to be written and maintained so this method is only recommended to teams who are experienced with APIs and scripting.

To get started using the Mend API see Getting Started with Mend API 3.0

The complete API 3.0 documentation can be found here.

The Mend Examples Repository has several examples of scripts that utilize the Mend API that can be used for inspiration. Most of these script utilize Mend API 2.0 which only provides SCA data as it is the API of the Legacy SCA UI.

Mend Jira Integration

Mend can connect to Jira through our native Jira App. This app will allow a user to create tickets manually though the Mend UI or automatically through automation workflows.

For more information on installing Mend For Jira see: Connect Mend for Jira

Automatic Dependency Updates with Renovate

Renovate is a tool that will create automatic pull requests to update your dependencies to the latest version. For SCA vulnerabilities, updating the library being used the main way of resolving a given vulnerability. By being on the latest version of a library, you will have all the available security patches for that particular library. Renovate is a great way to get ahead of CVEs and reducing the number of findings in your Mend Scans.

Installing Renovate

This guide provides directions for implementing the open-source version of Renovate as it is the easiest option to get started with Renovate.

Open-source Renovate is a free tool that is maintained by a community of developers who are not all associated with Mend. Mend does not provide support for issues that occur when using or implementing the open-source version Renovate. Any issues found when using the open-source version of Renovate should be reported to the open source repository.

An Enterprise version of Renovate is available with full Mend Support. If you would like to understand more about the Enterprise version of Renovate, please contact your Mend Sales Representative.

Renovate is a highly customizable tool with a lot of different configuration options. This guide will provide help point you in the right direction to get started installing Renovate but it cannot cover all of the possible configurations available with the tool. After installing Renovate it is recommended to view the Reading List in the Renovate documentations to get a better understanding of Renovate and what is possible with the tool.

Below covers the most common use cases for running Renovate. All platforms supported by Renovate can be found in the Renovate Documentation.

Azure/Bitbucket Data Center

While the below instructions link to the Azure DevOps instructions, the implementation will be the same. The main difference between the two platform will be the permissions of the Bot User and setting platform=bitbucket-server

Renovate should be added as a pipeline running the Renovate CLI

A Github token needs to be set in the config.js to provide updates for package managers that pulls its dependencies from GitHub such as Go. These are automatically disabled by default due to rate limiting concerns. An example can be seen from the Yarn Users example posted in the documentation.

schedules:
  - cron: '0 3 * * *'
    displayName: 'Every day at 3am (UTC)'
    branches:
      include: [main]
    always: true

trigger: none

pool:
  vmImage: ubuntu-latest

steps:
  - bash: |
      git config --global user.email 'bot@renovateapp.com'
      git config --global user.name 'Renovate Bot'
      npx renovate
    env:
      RENOVATE_PLATFORM: azure
      RENOVATE_ENDPOINT: $(System.CollectionUri)
      RENOVATE_TOKEN: $(System.AccessToken)

Bitbucket Cloud

Install the Mend App for Bitbucket and use the Free Renovate plan. Using the Paid Version of Renovate will automatically onboard your repositories with the Developer Platform repository integration.

GitLab Runner

The renovate-runner project should be used to run Renovate in Gitlab pipelines. Instructions for setting up renovate can be found in that project.

Some additional pieces to consider when setting up the renovate-runner:

1. If a GITHUB_COM_TOKEN is not set, then any package manager that pulls its dependencies from GitHub such as Go will automatically be disabled, and will not pull dependency updates.

2. It is recommended to either use the Docker image specified in the renovate-runner project or make sure all appropriate prerequisites are installed on the GitLab CI/CD runner. This consists of any relevant package managers for your repositories as well as having NPM/NodeJS for Renovate to run.

3. Specify a CI/CD tag so that one worker consistently resolves the same repositories, or make the environment for every worker identical. This way there will be no discrepancies between one worker’s resolution and another.

4. Specifying a global configuration with a config.js file in the repository where you host the runner can remove the need for each repository to set configurations unless special configurations are required for that respository.

Github.com/Github Enterprise Managed Users

Github.com users should install and run the Renovate Github App.

Self-hosted Github Enterprise

Self-hosted Github Enterprise users need to create their own Renovate Github App. Instructions on how to do so are provided in the official Renovate documentation.

Common Renovate Configurations for CLI and Self-hosted

These configurations only apply to implementations of Renovate that can set environment variables. The Github App cannot be modified to support the strategies discussed below.

Opt-In

By default, Renovate requires the presence of a renovate.json file inside the root directory of the repository before it will create pull requests to update dependencies. This file is created automatically by the onboarding pull request when it encounters a new repository. If the pull request is closed and the renovate.json file is not present in the repository it will be ignored. This approach will allow teams to decide if they want to run renovate or not within their repository. This approach will also allow development teams to customize the renovate configuration with repository specific configurations.

No User Interaction Needed

Renovate can be configured to not create onboarding PRs and still update repositories it has access to. This approach will allow the AppSec team to enforce the use of Renovate in all repositories. To disable onboarding PRs add the following environment variables to your pipeline or self-hosted configuration.

RENOVATE_REQUIRE_CONFIG: 'Optional'
RENOVATE_ONBOARDING: false

RENOVATE_REQUIRE_CONFIG: 'Optional' will still allow dev teams to create a renovate.json if they wish to configure their experience. Setting RENOVATE_REQUIRE_CONFIG: 'ignored' will prevent renovate from reading a customized configuration file, using only the configuration set within the pipeline.

Repository Discovery

Renovate can automatically discover repositories the service user has access to with the RENOVATE_AUTODISCOVER: trueenvironment variable. This setting removes the need to modify the pipeline to add newly created repositories to Renovate.

Noise Control

Renovate has a default limit of two pull request per hour and ten concurrent pull requests per repository. These settings can be overridden with the RENOVATE_PR_HOURLY_LIMIT and RENOVATE_PR_CONCURRENT_LIMIT environment variables

Next Steps

Congratulations on completing your Mend Rollout! From here the recommended next steps would be to collect feedback from your teams and tweak the integration based on feedback.

The document Analyze your Results in the Mend Platform will give you a better understanding of how to view and triage your results from within the Mend Platform while Prioritizing Findings gives a high level overview of where to start addressing your findings.

Creating automation workflows will allow you enforce company policies around vulnerabilities or licenses, create Jira issues or send emails to the right teams if new critical vulnerability is discovered.

For SAST Scans you can customize the Code Scan configurations to set up path exclusions or adjust CWE severities to match your policies.