CIS Software Supply Chain Benchmark Guide: Applying the GitHub and GitLab Controls

Most organisations harden their servers against a CIS Benchmark but leave the source code platform that builds and ships their software on default settings. The CIS Software Supply Chain Security Benchmarks close that gap with auditable controls for GitHub and GitLab, derived from the vendor-neutral CIS Software Supply Chain Security Guide. This guide explains how the guidance is structured, which recommendations matter most, how they translate into GitHub and GitLab settings, how to assess them with open-source tools such as chain-bench and Legitify, and how the controls map to SLSA, NIST SSDF and SP 800-53. It is written for DevSecOps engineers, platform owners and auditors. For general GitHub hardening see the GitHub and GitHub Actions Security Guide; this page focuses on the benchmark itself.

Key takeaways

• One guide, several benchmarks. The CIS Software Supply Chain Security Guide v1.0 is the generic parent; CIS currently lists platform benchmarks for GitHub (v1.2.0) and GitLab (v1.0.1) on its benchmark page, checked 27 October 2026.
• Five phases, 100+ recommendations. Source code, build pipelines, dependencies, artifacts and deployment, from the first commit to the running application.
• Identity is most of the benchmark. MFA, minimum administrators, strict base permissions, third-party app approval, registry access and default passwords are all identity controls, and many apply to bots, tokens and apps as well as people.
• Automate the assessment. chain-bench implements the benchmark checks against GitHub and GitLab, and Legitify audits organisation and repository settings; both need a highly privileged token, which must itself be protected.
• The benchmark is a floor for SLSA. CIS designed the guide to support SLSA and The Update Framework with foundational, auditable settings; it does not by itself produce signed provenance.

What it is and who it applies to

Argon (now part of Aqua Security) approached the Center for Internet Security with the idea of a benchmark for software supply chain security. Because so many platforms are involved, CIS first published a generic CIS Software Supply Chain Security Guide, intended as the parent for platform-specific benchmarks. Its diagram shows GitHub and Azure DevOps benchmarks as children; the CIS benchmark page today lists GitHub and GitLab versions, with older versions archived in CIS WorkBench. The guide was reviewed by subject matter experts from Aqua Security, CIS, Microsoft, PayPal, Red Hat, CyberArk, Axonius and others.

• Audience: the guide names DevOps and application security administrators, security specialists, auditors, help desks and platform deployment staff.
• Scope: any organisation that develops software through automated DevOps pipelines, whether on GitHub.com, GitHub Enterprise Server, GitLab.com or self-managed GitLab.
• Status: CIS Benchmarks are voluntary consensus guidance. They become mandatory only when a customer contract, an internal policy or an auditor adopts them, which is increasingly common in supplier security questionnaires.
• Access: the platform benchmarks are distributed by CIS after registration; the v1.0 guide PDF is also published in the chain-bench repository. Version numbers change, so confirm the current version on the CIS page before an audit.

Structure and key requirements

The guide follows the supply chain from contributor to customer and organises recommendations into five categories, each with sub-sections. Each recommendation is phrased as "Ensure..." with a rationale, audit procedure and remediation.

How the controls land in GitHub and GitLab

Treat the table as orientation: exact names and licence tiers differ between versions, and the platform benchmark gives the authoritative audit steps for each.

Identity and NHI requirements

Read as an identity document, the benchmark is about who and what can change code, trigger builds and publish artifacts. Several recommendations apply as much to machine identities as to people.

• Human accounts: 1.3.4 and 1.3.5 require MFA for contributors and organisation members; 1.3.6 requires invitations to company-approved email; 1.3.1 removes inactive users; 1.3.3 and 1.3.7 set a minimum number of organisation administrators and two administrators per repository, so no one person controls a repository and no repository is orphaned.
• Base permissions: 1.3.8 sets strict base permissions, so new repositories are not readable or writable by every member by default. Legitify flags this as "Default Member Permissions Should Be Restricted".
• Git credentials: 1.3.11 asks the organisation to provide SSH certificates, and 1.3.12 limits Git access by IP address. Both reduce the value of a stolen personal key or token. See the GitHub Personal Access Tokens Security Guide and the GitLab Tokens Security Guide.
• Third-party apps: 1.4.1 requires administrator approval for every installed application, 1.4.2 removes stale ones and 1.4.3 limits each to least privilege. The GitHub OAuth Token Breach 2022 showed why: OAuth tokens held by the Heroku and Travis CI integrations were used to clone private repositories from dozens of organisations.
• Pipeline identities: 2.1.5 and 2.1.6 limit and authenticate access to build environments, and 2.3.5 minimises who can trigger a build. In GitHub, Legitify also checks that the default workflow token is read-only and that workflows cannot approve pull requests, which would let a bot bypass review. Prefer OIDC federation over stored cloud keys; see the GitHub Actions OIDC Federation Hardening Guide.
• Secrets in pipelines: 2.3.8 and 5.1.3 require scanners for sensitive data in pipeline and deployment files. The Codecov Breach 2021 turned a CI script into a harvester of the environment variables, tokens and keys in customer pipelines.
• Registries: 4.2.2 minimises uploaders, 4.2.3 requires MFA for registry users, 4.2.4 says registry user management should not be local (use the central IdP), and 4.2.5 revokes anonymous access. Publishing tokens are the machine side of this; see the RubyGems, NuGet and Crates.io Publishing Tokens Guide.
• Deployment: 5.2.3 limits production access and 5.2.4 bans default passwords, which in practice means default service and admin credentials on deployment tooling.

Implementation steps

1. Pick the benchmark and scope: download the current GitHub or GitLab benchmark from CIS, list in-scope organisations or groups, and decide which profile or level the platform benchmark defines as your target.
2. Baseline with tools in read-only mode: run chain-bench (chain-bench scan --repository-url ... --access-token ...) against representative repositories and Legitify (legitify analyze --org ..., with --scm gitlab for GitLab) across the organisation. Use a dedicated scanning identity, keep its token in a vault and revoke it after the run.
3. Fix organisation-wide identity controls first: enforce MFA and SSO, set strict base permissions, reduce owners to a small named group, and review installed apps and OAuth grants. These changes cover every repository at once.
4. Roll out branch rules in rings: apply GitHub rulesets or GitLab protected branch and approval settings to a pilot group of repositories, review failed merges and bypass requests for a sprint, then widen. Rollback is a ruleset or protection change, so keep the previous configuration as code.
5. Harden pipelines: set default workflow token permissions to read-only, restrict actions or CI components to an allowlist, move to ephemeral runners, and pin third-party actions to commit SHAs.
6. Add integrity: sign artifacts and SBOMs from the pipeline itself (2.4.1, 2.4.6, 4.1.1). See the Sigstore Guide and the SBOM Guide.
7. Record exceptions: some recommendations, such as 3.1.8 (packages older than 60 days) or 1.1.13 (linear history), may conflict with team practice or urgent security updates. Document the deviation, owner and compensating control instead of silently failing.
8. Re-scan on a schedule: run the tools monthly or in CI and track drift.

Small and large organisations

A small team with a handful of repositories can apply organisation settings and one ruleset manually in a day and re-check quarterly. An enterprise with hundreds of organisations or groups needs policy as code: rulesets and protections managed through Terraform or the API, scanning in CI, and exception records in a GRC tool. Licence tier matters: several GitLab approval controls require Premium or Ultimate, and some GitHub rules apply only to organisation-level rulesets on higher plans.

Evidence and assessment

What to monitor and measure

• Benchmark pass rate: percentage of applicable recommendations passing, per organisation, trended monthly.
• Protected default branches: share of active repositories whose default branch is covered by a ruleset or protection that applies to administrators.
• Owner count: number of organisation owners and repositories with fewer than two administrators.
• App hygiene: installed apps and OAuth grants without an approval record or unused for 90 days.
• Bypass events: number of ruleset bypasses or protection changes per month, each tied to a change record.
• Write-scoped workflow tokens: repositories whose default workflow permission is still read and write.

Alert in the SIEM on branch protection or ruleset deletion, visibility changes from private to public, new organisation owners and new app installations. See the OWASP CI/CD Top 10 CICD-SEC-10 Insufficient Logging and Visibility Guide.

Mapping to other frameworks

On the threat side, the benchmark mitigates MITRE ATT&CK T1195.001 Compromise Software Dependencies and Development Tools, T1195.002 Compromise Software Supply Chain and T1199 Trusted Relationship. It overlaps heavily with the OWASP Top 10 CI/CD Security Risks; see the Top 10 CI/CD Security Risks.

Common pitfalls

• Branch rules that exempt administrators: 1.1.14 exists because a single compromised owner account can otherwise push straight to main.
• Scanning token left lying around: Legitify's GitHub token needs scopes such as admin:org and repo and cannot be a fine-grained token, so a leaked scanner token is an organisation-admin credential. Run scans from a controlled job and revoke afterwards.
• Repository checks without organisation checks: running chain-bench against one repository proves little if organisation MFA, base permissions and apps are not assessed.
• Counting human MFA but not bots: deploy keys, personal access tokens on service users and OAuth apps bypass MFA entirely and need their own scope, rotation and ownership.
• Treating a pass as provenance: a benchmark pass shows settings, not that a given artifact came from a given commit. Add signed provenance (see the SLSA and Build Provenance Guide).
• Auditing an outdated version: the GitHub benchmark has moved through several versions; check the version an auditor or customer expects.

Practitioner checklist

• Download the current CIS GitHub or GitLab benchmark and record the version in scope.
• Run chain-bench and Legitify with a dedicated, vaulted, short-lived scanning token and keep the reports as evidence.
• Enforce MFA and SSO, set strict base permissions and keep a small named owner group with at least two administrators per repository.
• Approve, scope and periodically remove third-party apps and OAuth grants.
• Apply branch rules for reviews, stale approval dismissal, signed commits, status checks and no force push, with administrators included.
• Set default workflow token permissions to read-only, use ephemeral runners and pin third-party actions.
• Turn on secret scanning with push protection for code, pipeline and deployment files.
• Sign artifacts and SBOMs in the pipeline and require MFA and central identity for registry users.
• Forward audit logs and alert on protection changes, visibility changes, new owners and new apps.
• Document every deviation with an owner and compensating control, and re-scan monthly.

Standards and references

• CIS: Software Supply Chain Security Benchmarks
• CIS and Aqua Security: CIS Software Supply Chain Security Guide v1.0
• Aqua Security: chain-bench
• Legit Security: Legitify
• GitHub Docs: Available rules for rulesets
• GitLab Docs: Merge request approval settings
• NIST: SP 800-218 Secure Software Development Framework Version 1.1
• OpenSSF: Supply-chain Levels for Software Artifacts (SLSA)

Related NHI Mgmt Group resources: GitHub and GitHub Actions Security Guide · GitLab Security Guide · CI/CD Pipeline Identity Security Guide · CI/CD Security Guide · SLSA and Build Provenance Guide