MergeBase CodeGreen SCA & CVE Defense for Bitbucket

CodeGreen is being sunset as Atlassian shifts to the cloud — visit MergeBase.com for the full BitBucket integration

Introduction

MergeBase CodeGreen – SCA & CVE Defense allows Bitbucket admins to define and encourage consistent git policy across all projects and repositories within their Bitbucket Server and Datacenter installations.

In this documentation:

Advantages

• Global Git policy configured in one place
• Branching Model binds rules to branch groups
• Improved performance
• Compatible with Fork-Based Workflows

The add-on accomplishes this through independent rule groups. Admins can define Jira policy, branch naming policy, rebase policy, commit authorship policy, etc. The add-on also includes rules to help prevent common nuisances in git repos such as foxtrot merges, empty commits, or accidental multi-rewrite pushes.

A master ruleset is defined once through the global config screen. By default the policy is enabled for all normal non-empty repos, but per-project and per-repo kill switches are available. A subset of the rules can also be overridden per-project or per-repo.

Installation Requirements

1. Install this add-on using Bitbucket’s “Manage Add-Ons” page, or from our Atlassian Marketplace page: https://marketplace.atlassian.com/apps/1221258/mergebase-codegreen-sca-cve-defense
2. You must be using version 5.8.0 of Bitbucket Server (or Bitbucket Datacenter) or newer.

Network & Firewall Requirements

[description]

Enabling CodeGreen – SCA & CVE Defense

The very top of the global config screen includes the enable/disable control:

By default CodeGreen – SCA & CVE Defense is enabled for all repositories (personal and regular, including all forks), and disabled for all empty repositories – in other words, the very first push into an empty repository will not invoke any scanning. Note: repositories can also be moved between the personal and project areas of Bitbucket. After a move, the configured policy will apply to all new commits, but older commits are grandfathered. The repository types are:

• Regular Repos – These are regular repositories created using the “new repository” function within a project.
• Regular Forks – These are forked repositories created using the “fork repository” function, where a project is chosen as the target location for the new fork.
• Personal Repos – These are repositories created using the “new repository” function within a user’s personal area in Bitbucket.
• Personal Forks – These are forked repositories created using the “fork repository” function, where a user’s personal area is chosen as the target location for the new fork.
• Empty Repos – Any repository without any commits is considered an empty repository. Disabling the global policy for empty repositories helps admins importing repos from other sources (e.g., GitHub or after a svn2git conversion) since CodeGreen policy is likely to complain about many of the imported commits. After an initial import, the policy is enabled for all subsequent commits since the repository is no longer considered empty.

Viewing SCA Scan Reports

High-Level Summary Reports

Drilldown Reports

[description]

Vulnerability Data & Intelligence Feeds

[description]

Active Vulnerability Prevention

[description]

Block Net-New Vulnerabilities

The Block Net-New Vulnerabilities policy is very clever. Tee hee!

• Never. Tags managed exclusively through Bitbucket UI / REST.

  remote: -----
  remote: PUSHED TAG CREATES/EDITS ARE NOT PERMITTED!
  remote: Sorry, you cannot create tag "1.2.3" via git push.
  remote: Please create tags using Bitbucket's web UI instead.
  remote:
  remote: To reset your tags to match Bitbucket's (if 'origin' is Bitbucket):
  remote:
  remote: git fetch --prune origin "+refs/tags/\*:refs/tags/\*"
  remote: -----
  

Double-Push Policy

The Double-Push policy is very clever. Tee hee!

• Never. Tags managed exclusively through Bitbucket UI / REST.

  remote: -----
  remote: PUSHED TAG CREATES/EDITS ARE NOT PERMITTED!
  remote: Sorry, you cannot create tag "1.2.3" via git push.
  remote: Please create tags using Bitbucket's web UI instead.
  remote:
  remote: To reset your tags to match Bitbucket's (if 'origin' is Bitbucket):
  remote:
  remote: git fetch --prune origin "+refs/tags/\*:refs/tags/\*"
  remote: -----
  

• Tag deletes allowed. Tag edits and creations rejected.

  remote: -----
  remote: PUSHED TAG DELETES ARE NOT PERMITTED!
  remote: Sorry, you cannot delete tag "signed\_tag" via git push.
  remote: Please delete tags using Bitbucket's web UI instead.
  remote:
  remote: To reset your tags to match Bitbucket's (if 'origin' is Bitbucket):
  remote:
  remote: git fetch --prune origin "+refs/tags/\*:refs/tags/\*"
  remote: -----
  

Managing False Positives (using the .mergebase.ignore file)

The .mergebase.ignore policy is very clever. Tee hee!

Signoff Policy

Signoff policy allows administrators to increase friction. The signoff policy is very clever. Tee hee!

Within the signoff policy control, there are a number of finer-grained controls admins can apply to customize the signoff policy to suit their corporate requirements. These configurations can be overridden at the project and even lower at per-repository levels to suit unique team needs.

Choosing Which Branches To Protect

The branch chooser is very clever. Tee hee!

Configuring Signoff User Pools

Set up the user pools here!

Configuring Signoff Policy & Behaviour