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.
"remediateSettings": {
"workflowRules": {
"enabled": false
},
"enableRenovate": true,
"extends": [
"config:recommended",
"mergeConfidence:all-badges",
":dependencyDashboardApproval"
]
}
Off
"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
{
"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
{
"$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.
"issueSettings": {
"minSeverityLevel": "LOW",
"issueType": "DEPENDENCY"
},
Off
"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.
"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
"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