Security Requirements for Selecting a Source Code Management Platform: criteria, vendor questions and tests

A source code management (SCM) platform holds your intellectual property, your build definitions and, too often, your secrets, so choosing one on developer features alone hands attackers the most valuable target in the software supply chain. This vendor-neutral guide sets out the security requirements to write into an SCM selection or RFP, whether you are buying a SaaS service, a self-managed server or a dedicated single-tenant edition. It covers identity and access, branch and tag protection, audit evidence, machine credentials, integrations and the platform's own security. It is written for platform engineering, application security and procurement teams, and it assumes the organisation will later run the platform day to day using our operational guides.

Key takeaways

• Enforcement must be central, not per repository. Require organisation-wide rules for branch protection, MFA, SSO, forking and visibility that repository admins cannot quietly switch off.
• History has to be tamper-evident. No force pushes or deletion on protected branches, immutable release tags and a record of every reference change are the basis of SLSA Source Level 2 and above.
• Machine identities are the main attack path. Personal access tokens, deploy keys, app installations and OAuth grants have exposed more private repositories than broken passwords; demand scoped, expiring and inventoried credentials.
• Audit logs are evidence, not a feature. Ask for complete, streamable, retained logs of authentication, permission and protection changes, clone activity and token use.
• Prove it in a proof of concept. Try to bypass review, rewrite a tag, export code with a stale token and find the change in the log before you sign.

Define requirements

Start from what the platform must protect and who touches it, then decide the deployment model. The answers change the weight of every criterion later in this guide.

• Assets in scope: source code, infrastructure-as-code, pipeline definitions, issue and wiki content, package and container artefacts if the SCM also hosts them, and any secrets that have historically leaked into repositories.
• Population: employees, contractors, external collaborators, open source contributors and machine actors (CI runners, bots, AI coding assistants, deployment tools). Count the machines: in most estates they outnumber people.
• Deployment model: multi-tenant SaaS (least operational effort, shared infrastructure), dedicated or single-tenant SaaS (data residency and isolation), or self-managed (you own patching, backups, network exposure and the server's own credentials). A self-managed server exposed with default credentials is a known failure; see the Nissan source code leak.
• Assurance target: decide whether you need to produce SLSA Source Track evidence, NIST SP 800-218 (SSDF) PS.1 evidence that code is protected from unauthorised access and tampering, or ISO/IEC 27001:2022 Annex A 8.4 (Access to source code) evidence. The target defines which logs and attestations the platform must produce.
• Regulatory and residency constraints: where repository data, backups and logs are stored and processed, and whether export-controlled code needs a dedicated region or self-managed instance.

Capability areas

Identity, authentication and session control

• SSO enforcement: SAML or OIDC single sign-on required for every member of the organisation, with automatic deprovisioning through SCIM when a joiner-mover-leaver event happens in the identity provider.
• Phishing-resistant MFA: the ability to require MFA for all members and to restrict factors to FIDO2 or WebAuthn for administrators. CISA's Secure by Design pledge asks manufacturers to increase MFA adoption with a focus on administrators, and SLSA lists phishing-resistant second factors as a future source requirement.
• Git transport credentials: controls over SSH keys and HTTPS tokens used by git clients, including organisation-level approval of SSH certificate authorities, key expiry and the ability to block legacy personal tokens.
• Session and IP policy: session lifetime, re-authentication for sensitive actions and optional IP allow lists for administrative and API access.

Authorisation and tenancy

• Least privilege by default: default member permission of none, team-based roles and custom roles, so read access to one repository does not imply read access to all.
• Owner sprawl limits: the OpenSSF SCM best practices recommend fewer than three organisation owners and removing admins and members inactive for six months. The platform should report on both.
• Visibility and exfiltration controls: policies that stop non-admins creating public repositories, block changing a private repository to public, restrict forking of private repositories to external namespaces and limit inviting outside collaborators.

Branch, tag and merge protection

• Protected references: rules for default and release branches that block force pushes and deletion, require pull requests and status checks, and apply to administrators too.
• Review rules: required approvals (two for high-risk repositories), code owner review, dismissal of stale approvals when new commits arrive, and no self-approval by the author or by whoever requested the review. SLSA Source Level 4 requires two trusted persons to review changes to protected branches.
• Tag immutability: release tags that cannot be moved or deleted. SLSA Source Level 2 requires this. The Laravel-Lang compromise shows what happens when a stolen token can rewrite every release tag.
• Commit signing: the ability to require signed commits and to show verification status, with support for SSH, OpenPGP and X.509 or keyless signing. See the Git Repository Security Guide.
• Rulesets at scale: organisation-level rules that target repositories by name pattern or property, with an evaluate or dry-run mode so you can see what would be blocked before enforcing.

Machine identities and integrations

• Token types: fine-grained, repository-scoped tokens with mandatory expiry; organisation approval of tokens before they can access organisation resources; and the ability to list and revoke every token, deploy key and app installation centrally.
• App and OAuth governance: admin approval for third-party apps, visibility of the scopes each holds and of which repositories each app installation can reach. The 2022 OAuth token breach of private repositories came through trusted integrations, not user passwords.
• Webhooks: TLS enforced and a shared secret or signature on every webhook, both called out by the OpenSSF SCM best practices and the Scorecard Webhooks check.
• Built-in CI controls: if the SCM includes CI, a read-only default token for pipelines, restriction to approved actions or components, and runner groups that public repositories cannot use. These map to OWASP CICD-SEC-4 Poisoned Pipeline Execution and CICD-SEC-5 Insufficient PBAC. See the CI/CD platform selection guide.

Code security features

• Secret scanning with push protection: detection on push, blocking before the secret lands in history, partner revocation where available and alert APIs. See the Git Secret Scanning Guide.
• Dependency and code analysis hooks: dependency alerts, dependency review on pull requests and integration points for SAST and software composition analysis, whether native or third party.

Audit, evidence and provenance

• Audit log scope: sign-ins, permission and role changes, protection rule changes and bypasses, token creation and use, app installations, repository visibility changes, clones and archive downloads, and administrator actions.
• Export: streaming to your SIEM or object storage in near real time, with retention you control. CISA's pledge asks vendors to give customers the logs needed to detect and investigate intrusions; a platform that charges for or truncates audit data fails this.
• Source provenance: for SLSA Source Level 2 and above, the platform (or a tool around it) must record who changed each named reference and when, and issue source provenance or a Source Verification Summary Attestation (VSA). See the SLSA Source Track Guide.

Platform security and resilience

• Vendor assurance: current independent attestation reports, a published vulnerability disclosure policy, CVE practice and incident notification commitments in the contract.
• Encryption and keys: encryption at rest and in transit, and for dedicated or regulated tenants the option of customer-managed keys.
• Backup and exit: repository, metadata (issues, reviews, rules) and audit log export in standard formats, with documented restore testing. Code that cannot be recovered after a ransom-style wipe is a business continuity failure; see the Gitloker extortion campaign.

Evaluation criteria

Small organisations should weight SSO, MFA, branch protection and token governance most heavily and accept native features elsewhere. Large or regulated organisations should add provenance, log retention, residency and customer-managed keys as must-haves, and score how well policy can be enforced across thousands of repositories without per-repository configuration.

Questions to ask vendors

• Can organisation-level branch and tag rules be overridden by a repository administrator, and is every bypass logged with the actor and reason?
• Which credential types can access repositories (passwords, personal tokens, SSH keys, deploy keys, app tokens, OAuth tokens), and can each be restricted, expired and revoked centrally?
• When a user is removed from the identity provider, which of their tokens and SSH keys stop working, and how quickly?
• Which events appear in the audit log? Are git clone, fetch and archive download events included, and for which plans?
• How is audit data exported, with what latency, and what is the retention without extra cost?
• Can we require phishing-resistant MFA for owners and administrators only, and enforce it?
• Do you produce source provenance or verification summary attestations, and to which SLSA Source level can a customer reach on your platform?
• How do you isolate tenants, and how would you notify us of a compromise of your own infrastructure or of an integration partner's tokens?
• For self-managed editions, what is the patch cadence, how are critical fixes announced, and which service accounts and secrets does the server itself hold?
• What can we export on exit, in what format, and does it include reviews, rules and audit history?

Red flags

• Branch protection that administrators bypass silently, or that cannot apply to administrators at all.
• Classic tokens with no expiry and no way to list which tokens can reach the organisation.
• Audit logs that omit clone and token-use events, or that are only available on screen.
• MFA and SSO sold as a premium tier add-on, which pushes smaller teams to run without them.
• No policy to block private repositories being made public or forked to personal namespaces.
• Self-managed builds that ship with default administrator credentials or open self-registration; the 2020 Mercedes-Benz source code leak came through open registration.

Where identity fits

An SCM platform is an identity system as much as a code store. Its non-human identities include CI tokens, deploy keys, app installations, bots and, increasingly, AI coding agents that open pull requests. Each needs an owner, a scope, an expiry and a log trail. Leaked repository tokens keep producing breaches, including the New York Times source code breach and the Home Depot token exposure. Score vendors on whether you can inventory these identities through an API and feed them into your NHI programme. See the CI/CD Pipeline Identity Security Guide for the operational side.

Proof of concept

1. Connect the platform to your identity provider, enforce SSO and MFA, then remove a test user and confirm their token and SSH key stop working.
2. Apply an organisation ruleset to a pilot group of repositories in evaluate mode, review what it would block, then enforce it.
3. As a repository administrator, try to force push to a protected branch, delete a release tag and merge your own pull request. All three should fail or leave a logged bypass.
4. Create a fine-grained token and an app installation, then confirm you can find both, see their scopes and last use, and revoke them centrally.
5. Push a test credential and confirm push protection blocks it and records any bypass.
6. Change a repository from private to public in a sandbox organisation and confirm the policy blocks it.
7. Stream the audit log to your SIEM and check that each action above arrived with actor, IP, token identifier and timestamp.
8. Export a repository with its reviews and rules, restore it to a clean instance, and time the restore.

Framework mapping

At control level, the requirements also sit in CIS Controls v8.1 Control 6 (Access Control Management), Control 8 (Audit Log Management) and Control 16 (Application Software Security).

Standards and references

• SLSA: Source Track requirements (v1.2)
• NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
• NIST: SP 800-204D Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines
• NIST: SP 800-53 Rev. 5
• OpenSSF: Source Code Management Platform Configuration Best Practices
• OpenSSF: Scorecard checks
• OWASP: Top 10 CI/CD Security Risks
• CISA: Secure by Design Pledge

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for SCM platforms, including the tokens, apps and bots that reach your code. Browse vendors in our NHI and AI products directory or contact us.

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · SLSA Source Track Guide · Git Repository Security Guide · Security Requirements for Selecting an Artifact and Container Registry · Source Code Leak Response Playbook