Silent Rollout for Repository Integrations

The following instructions to create a RuleSet will create a branch protection rule while allowing the Mend Bot to bypass these restrictions. These should be used in place of a branch protection rule and not alongside them.

• Go to your whitesource-config repository → Settings → Rules → Rulesets

• Create a new RuleSet with the following information:

  • Ruleset Name: Mend Bot Bypass

  • Enforcement Status: Active

  • Bypass list: Mend for GitHub.com App

  • Target branches: <your default branch>

  • Rules:

    • Restrict deletions

    • Require a pull request before merging (add any extra rules needed here).

    • Block force pushes

• Go to your whitesource-config project → Project Settings → Repositories → whitesource-config → Security tab

• Click on your Mend Bot user

• Bypass policies when pushing: Allow

Bypassing Branch Protection Rules is not supported in Mend for Bitbucket Cloud as the Bitbucket app is what executes the integration. It is recommended to manually create the files yourself before installing the integration.

For Mend Developer Platform for BitBucket Cloud, a whitesource-config repository is not needed.

• Follow the appropriate steps to Install Mend for GitHub.com.

  • choose “Only select repositories” when installing the app

• Add the whitesource-config repository to the list.

• Follow the appropriate steps to Install Mend for Azure Repos.

• Go to the whitesource-config project created for this and go to “Project Settings”

• Go to the Users and add the Bot user created for the purposes of the integration as a Project Administrator.

• Follow the appropriate steps to Install Mend for Bitbucket Cloud (old integration).

• The whitesource-config project/repository should have been created during installation.

• You can use includedRepos.exactNames = [ "whitesource-config/whitesource-config" ] to denote that no other repositories should be on-boarded.

• Follow the appropriate steps to Install Mend Developer Platform for Bitbucket Cloud.

  • When specifying repositories, specify “Only selected repositories” and select your test repository.

  • When choosing the scan behavior, specify “Scan Only”.

• checkRunSettings.vulnerableCheckRunConclusionLevel="NONE"

• pullRequestStatusSettings.vulnerablePullRequestStatus="NONE"

• buildSettings.createBuildStatus=false

These settings should not need to be changed if you set “Scan Only” in the scan behavior when installing.

• Go to your GitHub Organization → Settings → GitHub Apps → Mend for GitHub.com → Configure

  

• Scroll down to “Repository Access”, choose “Only select repositories” and select a few repositories for initial testing.

  

• Click Save.

The “Mend for GitHub.com” Repository Integration will start scanning the repositories that you have selected, and after a short period of time you should start seeing SCA results in the Mend UI. Once you have confirmed that the scans are executing properly, then you can set the “Repository access” to “All repositories” and continue to monitor the integration from there.

• Go to a couple of different projects that you would like to start scanning and add the Service User that was created to the project as a Project Administrator. These projects will be used for testing.

• After a short period of time you should start seeing SCA results in the Mend UI.

• If you would like to control which apps are accessible to the integration from the

Once you have confirmed that the scans are executing properly, then you can add the Service User to your other projects and continue to monitor the integration from there.

If the service user is added to a project and no scan is created in the Mend Platform, then it is possible that the integration needs it’s projects synced. To do this go to: Mend UI → Gear Icon in the Top Right → Integrations → Azure Repos → Sync Projects.

• Go to your whitesource-config repository.

• Add a couple of different repositories into the includedRepos.exactNames = [] JSON array for testing.

  • This should be in the format of: "workspaceName/repositoryName".

• After a short period of time you should start seeing SCA results in the Mend UI.

Once you have confirmed that the scans are executing properly, then you can add more repositories to the integration. Once you are confident the scans are running properly, then you can onboard all repositories by changing includedRepos.exactNames to ignoredRepos.exactNames = []. If you want the integration to not scan specific repositories, then add them to that list.

• Go to a couple of different repositories from within the platform → Select Settings → Open-Source Security → Enable to start onboarding repositories to scan.

Once you have confirmed that the scans are executing properly, then you can enable more repositories. Once you are confident all repositories will be scanned without issue, then you can enable all repositories.

{
  "settingsInheritedFrom": "<gh-org>/whitesource-config@main",
  "checkRunSettings": {
    "vulnerableCheckRunConclusionLevel": "success"
  },
  "issueSettings": {
    "minSeverityLevel": "CRITICAL"
  },
  "remediateSettings": {
    "workflowRules": {
      "enabled": true
    }
  }
}

This configuration will:

• Turn on checkruns, but not make them fail if Security Vulnerabilities are present.

• Only report on Critical Vulnerabilities in checkruns due to the setting checkRunSettings.failOnVulnerabilityMinSeverity=CRITICAL in the repo-config.json.

• Override issueSettings.minSeverityLevel=NONE to CRITICAL, which will only open up issues for security vulnerabilities that have “CRITICAL” severity.

• Override remediateSettings.workflowRules.enabled=false to true, which will allow remediate to open up fix pull requests for the vulnerabilities detected from the scans.

{
  "settingsInheritedFrom": "<azdo-project>/whitesource-config@main",
  "pullRequestStatusSettings": {
    "vulnerablePullRequestStatus": "success"
  },
  "issueSettings": {
    "minSeverityLevel": "CRITICAL"
  },
  "remediateSettings": {
    "workflowRules": {
      "enabled": true
    }
  }
}

This configuration will:

• Turn on check statuses, but not make them fail if Security Vulnerabilities are present.

• Only report on Critical Vulnerabilities in checkruns due to the setting issueSettings.minSeverityLevel=NONE to CRITICAL, this will also only open up issues for security vulnerabilities that have “CRITICAL” severity.

• Override remediateSettings.workflowRules.enabled=false to true, which will allow remediate to open up fix pull requests for vulnerabilities detected from the scans.

{
  "settingsInheritedFrom": "<bb-workspace>/whitesource-config@main",
  "buildSettings": {
    "createBuildStatus": true,
    "failBuilds": false
  },
  "issueSettings": {
    "minSeverityLevel": "CRITICAL"
  },
  "remediateSettings": {
    "workflowRules": {
      "enabled": true
    }
  }
}

This configuration will:

• Turn on check statuses, but not make them fail if Security Vulnerabilities are present.

• Only report on Critical Vulnerabilities in checkruns due to the setting issueSettings.minSeverityLevel=NONE to CRITICAL, this will also only open up issues for security vulnerabilities that have “CRITICAL” severity.

• Override remediateSettings.workflowRules.enabled=false to true, which will allow remediate to open up fix pull requests for vulnerabilities detected from the scans.