Screenshot from CodeGreen requiring a double-push when known-vulnerabilities are detected.
MergeBase Logo

MergeBase CodeGreen
SCA & CVE Defense

Documentation
 
July 2020
 

Table of Contents

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 Bitbucket Datacenter installations.

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:

Enabled For:
Regular
Repos
Regular
Forks
Personal
Repos
Personal
Forks
Empty
Repos

By default CodeGreen - SCA & CVE Defense is enabled for all respositories (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

[description]

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!
Block Net-New Vulnerabilities:
Net-New Override
  • 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!
Double-Push Policy:
  • 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!
Enable .mergebase.ignore file:
For managing false positives
 

Signoff Policy

Signoff policy allows administrators to increase friction. The signoff policy is very clever. Tee hee!
Signoff Policy:
Known-vulnerabilities above the CVSS threshold require signoff to merge (when enabled)
Within a the signoff policy control there are 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!
Branches Signoff Policy Applies To:        

Configuring Signoff User Pools

Setup the user pools here!
Signoff Pool (Users)
Signoff Pool (Groups)
Can be enclosed in quotes if necessary (e.g., Group1, "Group with , in name")

Configuring Signoff Policy & Behaviour

Signoffs Required To Merge:
"Approved" pull-request reviews
Vetoes Required To Block:
"Needs Work" pull-request reviews
Ignore Self-Signoffs  
Require Signoff For Edits To
.mergebase.ignore file?