Your source control platform holds the code, the pipeline definitions and often the credentials that reach production, yet its settings drift quietly as teams create organisations, add bots and switch off protections to ship faster. This health check gives you thirteen quarterly metrics, each with a formula, a data source type and thresholds, to measure whether the platform that hosts your repositories is still configured the way you intended. It is written for the platform engineering or developer experience team that runs the source control service and the application security lead who signs off on it. It measures the platform's configuration and the identities that use it; commit signing practice and history rewrites are covered in the Git Repository Security Guide, and finding secrets in code is covered in the Git Secret Scanning Guide.
What this health check covers
The scope is every hosted or self-managed source control service your organisation uses, at three levels: the enterprise or instance (authentication, administrators, audit log), the organisations or groups within it (membership, outside collaborators, installed integrations, default permissions) and the repositories (branch protection, visibility, deploy keys, webhooks, security features). It covers human developers and the non-human identities that act on the platform: bot and machine users, personal and project access tokens, deploy keys, integration apps and the CI/CD systems that clone and push. Pipeline execution itself is measured in the CI/CD server health check, and estate-wide supply chain outcomes in the Software Supply Chain Health Check.
The review is run by the source control platform owner and approved by the application security lead. The metrics draw on the OpenSSF Source Code Management Platform Configuration Best Practices and the CIS Software Supply Chain Security Benchmarks, expressed as measurable ratios rather than a list of settings to tick. For what to require when choosing or replacing a platform, see Security Requirements for Selecting a Source Code Management Platform.
Key takeaways
- Measure protection on the branches that ship. Default and release branches without required review and with force pushes allowed are the single largest integrity gap.
- Tokens and keys outnumber developers. Personal access tokens, deploy keys and integration apps are non-human access to your code, and each needs an owner, a scope and an expiry.
- Federate every human sign-in. Accounts that authenticate outside corporate SSO survive offboarding and miss MFA policy.
- Count your administrators. Owner and administrator roles at enterprise and organisation level should be a short, named list.
- The audit log is evidence only if it leaves the platform. Measure delivery to the SIEM, not whether logging is switched on.
How to use this template
Copy the metrics table and the findings log into your own tracker, then run this source control platform health check at the cadence below. Collect each figure from the data source types described, score it against the green, amber and red bands, and record every amber or red result as a finding with an owner and a due date. Run the same workbook for each platform instance if you operate more than one, and report each separately and in total. Replace bracketed placeholders such as [Organisation] and [Name, role] with your own values.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Full thirteen-metric health check | Quarterly | Source control platform owner | Application security lead | Metric workbook, settings and membership exports, findings log |
| Administrator and outside collaborator snapshot (SCM-02, SCM-04) | Monthly | Platform engineering | Source control platform owner | Role export, collaborator list with sponsor |
| Token, deploy key and integration review (SCM-06 to SCM-09) | Quarterly | Platform engineering with identity security | Application security lead | Credential and integration inventory with owners, scopes and last use |
| Branch protection drift check (SCM-10, SCM-11) | Monthly | Platform engineering | Application security lead | Ruleset export for production repositories |
| Ad hoc rerun | After a source code leak, a token exposure, an acquisition or a platform migration | Source control platform owner | CISO delegate | Same as quarterly |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. Bands are contiguous: a value sits in exactly one band. "Production repositories" means repositories whose code or pipeline definitions deploy to production; tag them before the first review so the denominator is stable.
| ID | Metric | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| SCM-01 | Human sign-in through SSO | Human member accounts that can authenticate only through the corporate identity provider / total human member accounts | Platform member export joined to identity provider assignment export | 98% or above | 90% to below 98% | Below 90% |
| SCM-02 | Administrator count within limit | Organisations or groups with no more than [3] owner or administrator accounts, each a named person on the approved list / total organisations or groups | Role and membership export at enterprise and organisation level | 95% or above | 80% to below 95% | Below 80% |
| SCM-03 | Dormant member accounts | Member accounts with no sign-in, push or API activity in 90 days / total member accounts | Member export joined to audit log activity | Below 5% | 5% to 15% | Above 15% |
| SCM-04 | Outside collaborators with a sponsor and expiry | Outside collaborators with a recorded internal sponsor and an access end date / total outside collaborators | Collaborator export, access request records | 95% or above | 80% to below 95% | Below 80% |
| SCM-05 | Unexpected public repositories | Public repositories not on the approved open source list / total public repositories | Repository list with visibility, open source register | 0% | Above 0% to 5% | Above 5% |
| SCM-06 | Access tokens with expiry and narrow scope | Active personal, project or group access tokens with an expiry of 90 days or less and scope limited to named repositories / total active access tokens | Token inventory from the platform's credential management export | 90% or above | 70% to below 90% | Below 70% |
| SCM-07 | Unused tokens and deploy keys | Active tokens and deploy keys not used in 90 days / total active tokens and deploy keys | Credential inventory with last-used dates | Below 5% | 5% to 20% | Above 20% |
| SCM-08 | Write-enabled deploy keys | Deploy keys with write access on production repositories without a recorded owner and business reason / total deploy keys on production repositories | Repository deploy key export | 0% | Above 0% to 5% | Above 5% |
| SCM-09 | Integrations with an owner and reviewed permissions | Installed integration apps and OAuth grants with a named owner and a permission review in the last 12 months / total installed integrations and grants | Organisation integration and OAuth grant export | 95% or above | 80% to below 95% | Below 80% |
| SCM-10 | Protected default and release branches | Production repositories whose default and release branches require at least one approving review from someone other than the author and block force pushes and deletion / total production repositories | Branch protection or ruleset export | 98% or above | 90% to below 98% | Below 90% |
| SCM-11 | Protection bypasses | Merges or pushes to protected branches in the quarter that used an administrator bypass or override / total merges to protected branches | Audit log events for protection bypass, merge history | Below 1% | 1% to 3% | Above 3% |
| SCM-12 | Signed commits required on protected branches | Production repositories whose protected branches require signed or verified commits / total production repositories | Branch protection or ruleset export | 90% or above | 70% to below 90% | Below 70% |
| SCM-13 | Audit log delivery | Days in the quarter on which the platform audit log was received by the SIEM or log archive / days in the quarter | SIEM ingestion report for the platform audit source | 100% | 97% to below 100% | Below 97% |
SCM-10 and SCM-11 belong together: a ruleset that every administrator bypasses weekly is a recommendation, not a control. SCM-06 to SCM-09 measure the non-human identities on the platform; stolen tokens and keys are how attackers reach code repositories (MITRE ATT&CK T1213.003 Code Repositories) and how code leaves (T1567.001 Exfiltration to Code Repository). The Nissan source code exposure, where a Git server was left with default credentials, shows how quickly weak platform access becomes a full leak; see the Nissan Source Code Leak 2021.
How to collect the data
- Membership and role exports (SCM-01 to SCM-04): export members, roles and outside collaborators at enterprise and organisation or group level, and join them to the identity provider's assignment list for the source control application. Accounts in the platform with no identity provider match fail SCM-01.
- Repository inventory (SCM-05, SCM-10, SCM-12): export every repository with visibility, production tag, branch protection or ruleset settings and security feature settings. Read effective settings, including rules inherited from organisation-level rulesets, not only repository-level ones.
- Credential inventory (SCM-06 to SCM-08): export access tokens and deploy keys with owner, scope, creation date, expiry and last-used date. Self-managed instances usually expose this to instance administrators; hosted services may require organisation-level token approval to be switched on before tokens are visible.
- Integration export (SCM-09): list installed apps and OAuth grants with their requested permissions and the repositories they can reach. Record who approved each installation; an integration with no approval record counts as unowned.
- Audit log (SCM-03, SCM-11, SCM-13): take 90 days of audit events from the SIEM, filtered for sign-in, push, protection bypass and settings changes, plus the SIEM's daily ingestion count.
Use a dedicated read-only audit token with an expiry, record its scope in the workbook, and revoke it when the review closes: the audit credential is itself an NHI with wide read access to your code.
Red flags that need action now
- A production repository whose default branch accepts force pushes or direct pushes without review.
- An access token or deploy key with write access to many repositories and no expiry.
- A private repository made public without an approval record.
- Human accounts that sign in with a local password while the person has already left the organisation.
- An integration app with write access to code or administration that nobody can name an owner for.
- A rise in protection bypasses before a release, or bypasses by accounts that are not administrators on the approved list.
- Secret scanning alerts left open for production repositories beyond your SLA.
- Days with no audit log in the SIEM, especially around settings or membership changes.
If a red flag points to code or credentials already in the wrong hands, follow the Source Code Leak Response Playbook.
Findings log
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-SCM-01 | [Number] production repositories without branch protection | SCM-10 | [Critical / High / Medium / Low] | [Name, role] | [YYYY-MM-DD] | [Open / In progress / Closed / Risk accepted] |
| HC-SCM-02 | [Number] tokens without expiry or with broad scope | SCM-06 | [Severity] | [Name, role] | [YYYY-MM-DD] | [Status] |
| HC-SCM-03 | [Number] outside collaborators without sponsor | SCM-04 | [Severity] | [Name, role] | [YYYY-MM-DD] | [Status] |
| HC-SCM-04 | [Finding] | [SCM-nn] | [Severity] | [Name, role] | [YYYY-MM-DD] | [Status] |
Suggested severity: red on SCM-05, SCM-08, SCM-10 or SCM-13 is critical with a 30-day due date; other reds are high at 60 days; ambers are medium at 90 days.
Remediation map
| Finding type | Where the fix is described |
|---|---|
| Branch protection and bypasses (SCM-10, SCM-11) | Git Repository Security Guide, protected branches and tags section |
| Unsigned commits accepted on protected branches (SCM-12) | Git Repository Security Guide |
| Tokens, deploy keys and integrations (SCM-06 to SCM-09) | OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide; CI/CD Pipeline Identity Security Guide |
| Members, administrators and collaborators (SCM-01 to SCM-04) | Developer Access Lifecycle |
| Public repositories (SCM-05) | Source Code Leak Response Playbook |
| Platform baseline against the benchmark (all) | CIS Software Supply Chain Benchmark Guide |
Framework mapping
| Metric | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | MITRE ATT&CK |
|---|---|---|---|
| SCM-01 to SCM-04 | AC-2 Account Management; AC-2(3) Disable Accounts | PR.AA-01 | T1078.004 Cloud Accounts |
| SCM-05 | AC-6 Least Privilege | PR.AA-05 | T1213.003 Code Repositories |
| SCM-06 to SCM-09 | IA-5 Authenticator Management; AC-6 Least Privilege | PR.AA-05 | T1528 Steal Application Access Token |
| SCM-10, SCM-11 | CM-3 Configuration Change Control; SA-15 Development Process, Standards, and Tools | PR.PS-06 | T1195.002 Compromise Software Supply Chain |
| SCM-12 | SI-7 Software, Firmware, and Information Integrity | PR.PS-06 | T1195.002 Compromise Software Supply Chain |
| SCM-13 | AU-2 Event Logging; AU-6 Audit Record Review, Analysis, and Reporting | DE.CM-09 | T1567.001 Exfiltration to Code Repository |
In NIST SP 800-218 (SSDF) the platform controls support practice PS.1, protecting all forms of code from unauthorised access and tampering. In CIS Controls v8.1 they sit mainly in Control 5 (Account Management), Control 6 (Access Control Management) and Control 16 (Application Software Security).
Related guides
- Git Repository Security Guide: repository integrity controls these metrics test.
- Software Supply Chain Maturity Model: the maturity levels this platform evidence supports.
- Software Supply Chain Health Check: programme outcomes across the whole supply chain.
- Source Code Leak Response Playbook: response when code or platform credentials are exposed.
- Source control platform migration playbook: carrying these controls across when you change platform.
References
- OpenSSF: Source Code Management Platform Configuration Best Practices
- CIS: Software Supply Chain Security Benchmarks
- NIST: SP 800-218 Secure Software Development Framework
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CIS: Critical Security Controls Version 8.1
- MITRE ATT&CK: Code Repositories
Related NHI Mgmt Group resources: Software Supply Chain Security Guide, CI/CD Security Guide, Secrets scanning tool health check, Artefact and container registry health check.