Keep your software supply chain secure with these new VCS policies

Barak Schoster

SREs and security practitioners spend a lot of time creating secure and reliable infrastructure for web applications. In parallel, engineering teams also spend significant time on release engineering and the release pipeline, ensuring it’s secure and fast.

Release pipelines are made up of version control systems (VCS) (e.g., GitHub, Gitlab, Bitbucket), continuous integration/continuous deployment (CI/CD) pipeline configuration (e.g., Jenkins, GitHub Actions, Terraform Cloud), OSS packages, and tagging. When building release pipelines, the goal is to create consistent, auditable, and agile build and deployment processes.

Both software components and release pipelines are equally significant components of software supply chains, but the latter can sometimes be overlooked in terms of security. Securing cloud infrastructure early in the development lifecycle is crucial, but even the most secure code can be compromised if the very place we store the code, the VCS, is exposed. If not adequately protected, a bad actor can inject a backdoor into our code that will make it into production without us knowing.

That’s why securing your version control system (VCS) is critical for a secure and reliable supply chain. The right protections ensure that code in your repositories is not modified or deleted—either mistakenly or maliciously.

New VCS configuration policies

To help teams secure where code is managed, we’ve added new VCS configuration policies in Checkov and Bridgecrew with support for scanning GitHub, GitLab, and Bitbucket.

With this update, you can now scan your VCS for configuration best practices like you would your infrastructure as code (IaC) for misconfigurations.

Best practices for secure VCS configurations

Automated scanning allows you to have complete confidence that you’re always following VCS security best practices such as the ones below.

Enforce 2FA

If credentials are stolen, the best second layer of defense to prevent code tampering is ensuring that two-factor authentication (2FA) is enforced. This makes sure that all git commits come from a legitimate, verified identity in your organization. Even if a bad actor is able to gain access, the rotation of the token will block reentry. If you’re turning on 2FA for the first time, this change should be communicated to all of the organization members so no disruption will occur to their day-to-day work.

Turn on SSO

Especially in large organizations, it’s challenging to manage onboarding and offboarding users. Configure SAML single sign-on (SSO) in a way that will allow everyone in the central identity provider to log in. Then, when someone leaves the organization, removal only has to be done in one place, and no one is left with unwarranted access to our repos.

Enforce signed commits branch protection rules on critical branches

Verify that commits have come from a trusted source and not from an impersonating identity since it can be easily forged. Double verify that the user has signed the commits using a GPG key on critical pipelines like commits that impact production. That can be done using branch protection rules.

Require approvals on code review

Requesting code review approvals can assist in distributing system knowledge on how things work, what might break, and if the code change was already implemented elsewhere. Not enforcing reviewers might lead to code changes nobody has noticed getting into production. It hurts the sense of team ownership and collaboration.

Getting started with continuous VCS scanning

To enforce the above best practices, Bridgecrew and Checkov come with new built-in policies for scanning your VCS. Previously, this was possible only using a custom JSON policy and some wrapping of curl commands described in a previous blog post. Now, starting with version 2.0.724, Checkov supports VCS policy checks out-of-the-box. Below, we’ll show you how to get started with VCS scanning with Checkov.

You can run Checkov locally with a personal access token to extract the configurations for a VCS provider and inspect them against out of the box and custom policies:

export GITHUB_TOKEN="ghp_abc"

checkov -d . --framework github_configuration

And an example output would be:

github_configuration scan results:

Passed checks: 2, Failed checks: 1, Skipped checks: 0

Check: CKV_GITHUB_3: "Ensure GitHub organization security settings has IP allow list enabled"
	PASSED for resource: /Users/barak//github_conf/org_security.json
	File: /Users/barak/github_conf/org_security.json:2-15

Check: CKV_GITHUB_2: "Ensure GitHub organization security settings require SSO"
	PASSED for resource:  /Users/barak//github_conf/org_security.json
	File: /Users/barak/github_conf/org_security.json:2-15

Check: CKV_GITHUB_1: "Ensure GitHub organization security settings require 2FA"
	FAILED for resource:  /Users/barak//github_conf/org_security.json
	File: /Users/barak/github_conf/org_security.json:2-15

		2  |     "data": {
		3  |         "organization": {
		4  |             "name": "Bridgecrew",
		5  |             "login": "bridgecrewio",
		6  |             "description": "Secure public cloud infrastructure",
		7  |             "ipAllowListEnabledSetting": "ENABLED",
		8  |             "ipAllowListForInstalledAppsEnabledSetting": "ENABLED",
		9  |             "requiresTwoFactorAuthentication": false,
		10 |             "samlIdentityProvider": {
		11 |                                 "ssoUrl": "https://bridgecrew.okta.com/app/githubcloud/foo/sso/saml"
		12 |             }
		13 |         }
		14 |     }
		15 | }

We can even set this up to scan for policy violations at regular intervals. Here is an example of a GitHub Actions configuration that validates best practices weekly:

name: Supply Chain
on:
  workflow_dispatch:
  schedule:
    - cron: 0 0 * * 0
jobs:
   bridgecrew:
    runs-on: ubuntu-latest
    steps:
    - name: Run checkov
      id: checkov
      uses: bridgecrewio/checkov-action@master
      env:
        GITHUB_TOKEN: ${{secrets.PAT_TOKEN}}

The output will look like this:

Behind the scenes, Checkov (which also powers Bridgecrew code scanning) is using a GitHub personal access token to fetch the current runtime configuration of the GitHub organization and then running the relevant built-in VCS configuration policies against it. After scanning, Checkov determines whether to fail or pass the CI job that was triggered.

GitHub provides additional capabilities to secure the software development lifecycle in its enterprise tier. Because security features like IP allowlists are not available in low/free tiers, these VCS policies, such as making sure the IP allowlist is used correctly, are only relevant only if the inspected account can enable it. 

Similar policy scanning can be achieved using a GitLab CI configuration:

stages:
   - test
  
checkov:
 stage: test
 allow_failure: true 
 image:
   name: bridgecrew/checkov:latest
   entrypoint:
     - '/usr/bin/env'
     - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
 variables:
   CI_JOB_TOKEN: SOME_TOKEN
   LOG_LEVEL: DEBUG
 script:
   - checkov -d . --framework gitlab_configuration

The output will look like this:

To scan your Bitbucket configuration, create an app password variable to grant access to Bitbucket rest API and configure the following pipeline:

image: bridgecrew/checkov
 
pipelines:
 default:
   - parallel:
     - step:
         name: 'Test branch restrictions'
         script:
           - checkov -d . --framework bitbucket_configuration

The output will look like this:

To build more secure code pipelines, we can now inspect and manage the posture of our VCS using Checkov as well as in the Bridgecrew platform. VCS policies will appear alongside other identified security issues. Additionally, scanned VCS repositories and parent organizations will also show up in our new Supply Chain Graph visualization.

Scanned VCS in Bridgecrew Supply Chain Graph

VCS configuration policy is a new concept, and we’ll be adding more best practice policies. To contribute more policies of your own, follow the contribution guides for GitHub, GitLab, and Bitbucket. If you find Checkov is helping secure your software supply chain, don’t forget to star our project!