Skip to main content
Skip table of contents

Enabling Results Consumption in Mend For Github.com

This document will focus on executing the onboarding decisions made following documents:

Mend Platform Rollout Overview
Cloud Repository Rollout
Setting up the Mend UI for Github.com Integration
Configure and Enable Mend for Github.com

Please read the previous documents prior to continuing.

Modify Results Consumption Settings

Results consumption settings are enabled by default. If opting out of a specific set of results consumption, use the sections labeled “off” to disable the desired settings.

Renovate

There are two approaches to running Renovate, proactively and reactively. This document describes both approaches, Mend recommends using proactive remediation running Renovate as it can put you ahead of open source vulnerabilities before they are published. All of the examples in this guide have proactive remediation enabled.

Decide if developers should receive pull requests for dependency updates by updating the remediateSettings{} section.

Smart Merge

Smart Merge is the preferred setting for Renovate and should be considered the default. The above link explains in more detail how to implement.

config:recommended

The below setting is a base recommendation for configuring Renovate and will enable the Dependency Dashboard in GitHub and provide merge confidence data. It will lock pull requests in the dependency dashboard for approval so that no automatic pull requests occur which in turn might trigger builds causing a “big bang” when using noWhiteSourceFile or pushWhiteSourceFile.

CODE
  "remediateSettings": {
    "workflowRules": {
      "enabled": false
    },
    "enableRenovate": true,
    "extends": [
      "config:recommended",
      "mergeConfidence:all-badges",
      ":dependencyDashboardApproval"
    ]
  }

Off

CODE
  "remediateSettings": {
    "enableRenovate": false,
    "workflowRules": {
      "enabled": false
    }
  }

Individual Repository Overrides

If you have followed the above directions to implement config:recommended in the global configuration and would like to have an individual repository use the Smart Merge approach then you can either update the individual .whitesource file with the following

CODE
{
  "settingsInheritedFrom": "OrgA/whitesource-config@main",
    "remediateSettings": {
    "extends": ["local>whitesource-config/whitesource-config:smart-merge"],
    "ignorePresets": [":dependencyDashboardApproval"]
    }
}

or you can create a renovate.json file within the repository if using the nowhitesourceFile approach

CODE
{
   "$schema": "https://docs.renovatebot.com/renovate-schema.json",
   "extends": ["local>whitesource-config/whitesource-config:smart-merge"],
   "ignorePresets": [":dependencyDashboardApproval"]
}

Both methods require you to create the smart-merge.json file as detailed in the Smart Merge directions.

Issues

Decide if developers should receive findings information within issues in the repository by updating the issueSettings{} section

Informative

If opening issues for developers, it is recommended to give all details as the issues are grouped by direct dependency, and raising the severity level will not reduce noise.

CODE
  "issueSettings": {
    "minSeverityLevel": "LOW",
    "issueType": "DEPENDENCY"
  },

Off

CODE
  "issueSettings": {
    "minSeverityLevel": "NONE",
    "displayLicenseViolations": false,
    "issueType": "DEPENDENCY"
  },

Security Gates

Decide if commits should receive a failure based on findings information which can be used with branch protection rules to block pull requests based on Mend findings. Security gates can be configured by updating the checkRunSettings{} section.

Blocking

The below will show a failure if critical SCA vulnerabilities or high SAST vulnerabilities are found. This can be a good level to start with so developers are not overwhelmed with a large number of vulnerabilities all at once. To adjust the level of vulnerability failure, change "failOnVulnerabilityMinCvss" and "severityThreshold" settings.

CODE
  "checkRunSettings": {
    "vulnerableCheckRunConclusionLevel": "failure",
    "failOnVulnerabilityMinCvss": "9.0",
    "licenseCheckRunConclusionLevel": "failure",
    "displayMode": "diff",
    "useMendCheckNames": true,
    "strictMode": "failOnWarning"
  },
  "checkRunSettingsSAST": {
    "checkRunConclusionLevel": "failure",
    "severityThreshold": "high"
  }

Off

The below will always show the checkRun status as successful even if high or critical findings were detected

CODE
  "checkRunSettings": {
    "vulnerableCheckRunConclusionLevel": "SUCCESS",
    "failOnVulnerabilityMinCvss": "9.0",
    "licenseCheckRunConclusionLevel": "SUCCESS",
    "displayMode": "diff",
    "useMendCheckNames": true,
    "strictMode": "failOnWarning"
  },
  "checkRunSettingsSAST": {
    "checkRunConclusionLevel": "SUCCESS",
    "severityThreshold": "high"
  }

Next Steps

Wrap up your rollout by setting up scan log retrieval and enabling Mend for your development teams by following: Wrapping up Mend for Github.com Rollout

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.