GitHub compliance integration:
13 read-only checks on how code reaches production.
Connect a GitHub organisation with a read-only token and TryTrustable checks two-factor enforcement, branch protection, review and CI policy, real review on merged pull requests, Dependabot and secret scanning, then files each passing result as evidence.
What does the TryTrustable GitHub integration check?
The GitHub integration runs 13 read-only checks through the GitHub REST API: organisation two-factor enforcement, a repository inventory, protection on default and long-lived branches, required approving reviews, required CI checks, signed commits, CODEOWNERS, CI configuration, Dependabot alerts, secret scanning, whether recently merged pull requests were approved by someone other than the author, and stale pull requests.
Most of the checks are about change management, because that is the question an auditor asks of a code host: can a change reach production without someone else looking at it? Settings answer half of that. The other half is whether the settings held, so one check samples recently merged pull requests and inspects their reviews, since an admin override or a self-approval leaves the policy switched on and the control broken.
| Check | What it reads | How it decides | Evidence filed against |
|---|---|---|---|
| Two-factor authentication is required | GET /orgs/{org}, field two_factor_requirement_enabled. For a personal account with no organisation, GET /user, field two_factor_authentication | Pass if required, fail if not. GitHub shows the organisation setting only to organisation owners; if the token cannot see it the result is could not verify, never a pass. | SOC 2 CC6.1 ISO/IEC 27001 A.8.5 |
| Source-code repositories are inventoried | GET /orgs/{org}/repos?type=all (or GET /user/repos?affiliation=owner), 100 per page, up to five pages | Pass if repositories were enumerated; the counts of active, archived and private repositories are the evidence. Could not verify if the token can see none. | ISO/IEC 27001 A.5.9 |
| Default branches are protected | GET /repos/{r}/branches/{default}/protection and GET /repos/{r}/rules/branches/{default} on each sampled repository | Pass for a repository if its default branch has classic branch protection or an active ruleset; fail if it is not protected. Any failing repository fails the check, and each is named. | SOC 2 CC8.1 ISO/IEC 27001 A.8.32 |
| Release and long-lived branches are protected | GET /repos/{r}/branches?per_page=100, the protected flag | Fail for a repository if any long-lived branch is unprotected: the default branch, main, master, develop, development, staging, production, prod, release* or hotfix*. Short-lived feature branches are not required to be protected. | SOC 2 CC8.1 ISO/IEC 27001 A.8.32 |
| Pull requests need an approving review | required_approving_review_count from branch protection or the ruleset's pull_request rule on each default branch | Pass for a repository if at least one approving review is required before merge. | SOC 2 CC8.1 ISO/IEC 27001 A.8.32 |
| Merges wait for required CI checks | Required status checks from branch protection or the ruleset's required_status_checks rule on each default branch | Pass for a repository if at least one named status check must pass before merge. | SOC 2 CC8.1 ISO/IEC 27001 A.8.32 |
| Commits to default branches must be signed | required_signatures from branch protection, or a required_signatures ruleset rule | Pass for a repository if unsigned commits are rejected. Marked informational: a fail is shown as a gap, not an audit exception. | SOC 2 CC8.1 ISO/IEC 27001 A.8.32 |
| A CODEOWNERS file assigns reviewers | GET /repos/{r}/contents/?ref={default}, then the .github and docs directory listings | Pass if a CODEOWNERS file exists at the root, in .github/ or in docs/ on the default branch. Not applicable for an empty repository. | SOC 2 CC8.1 ISO/IEC 27001 A.8.32 |
| CI runs on the default branch | The same directory listings, plus .github/workflows | Pass if the default branch has a GitHub Actions workflow (.yml or .yaml) or a known CI file: .gitlab-ci.yml, Jenkinsfile, azure-pipelines.yml, bitbucket-pipelines.yml, cloudbuild.yaml, .circleci/ or .buildkite/. | SOC 2 CC5.2 ISO/IEC 27001 A.8.25 ISO/IEC 27001 A.8.29 |
| Dependabot vulnerability alerts are enabled | GET /repos/{r}/dependabot/alerts?per_page=1 | Pass if the endpoint answers; fail only if GitHub says the feature is disabled. Any other refusal, such as a missing token permission, is could not verify. | SOC 2 CC7.1 ISO/IEC 27001 A.8.8 |
| Secret scanning is enabled | GET /repos/{r}/secret-scanning/alerts?per_page=1 | Pass if the endpoint answers; fail only if GitHub says secret scanning is disabled or not enabled. Any other refusal is could not verify. | SOC 2 CC7.1 ISO/IEC 27001 A.8.8 |
| Merged pull requests had an independent approval | GET /repos/{r}/pulls?state=closed&per_page=20 and GET /repos/{r}/pulls/{n}/reviews: up to five merged pull requests in each of the five most recently pushed repositories | Pass for a pull request if it has an APPROVED review from someone other than its author. Any merge without one fails the check and is listed by number. | SOC 2 CC8.1 ISO/IEC 27001 A.8.32 |
| No long-lived open pull requests | GET /repos/{r}/pulls?state=open&per_page=100 on the same five repositories | Fail for a repository with an open pull request older than 30 days. Marked informational. | SOC 2 CC8.1 ISO/IEC 27001 A.8.32 |
A check over several resources passes only if every resource passes. One that could not be read makes the whole check could not verify, not a pass on the rest.
Each check returns one of four results: pass, fail, not applicable (nothing of that kind exists, or a plan limit makes the setting unavailable) or could not verify (the call was refused or failed). A check over several resources shows a value such as 6/8 passing and names every resource it looked at. Nothing is simulated, and a check that could not look is never shown as a pass.
Only passing checks become evidence: one evidence item for each reference in the last column, so a single pass can evidence SOC 2, ISO/IEC 27001 and the DPDP Act at once. Each item expires after 90 days and every sync renews it, so evidence from a connection that has stopped syncing stops counting. A failing result is shown on the connected account with the resources that caused it, and is not filed as evidence.
Which compliance controls does GitHub evidence?
Each check belongs to a shared control in the TryTrustable control library, and is filed only under requirements the library maps to that control. The same control answers requirements in other frameworks; the table shows them, read from the library. The cross-framework mapping page explains the model, and the SOC 2 to ISO 27001 mapping lists every shared row.
| Shared control | Checks that speak to it | SOC 2 | ISO/IEC 27001:2022 | DPDP Act | ISO/IEC 42001 |
|---|---|---|---|---|---|
| Multi-factor authentication enforcedCTL-MFA | Two-factor authentication is required | CC6.1 | A.5.17, A.6.7, A.8.2, A.8.5 | §8(5) | None |
| Asset inventoryCTL-ASSET-INV | Source-code repositories are inventoried | None | A.5.9, A.5.11, A.7.9, A.7.13 | None | None |
| Formal change managementCTL-CHANGE-MGMT | Default branches are protected; Release and long-lived branches are protected; Pull requests need an approving review; Merges wait for required CI checks; Commits to default branches must be signed; A CODEOWNERS file assigns reviewers; Merged pull requests had an independent approval; No long-lived open pull requests | CC3.4, CC5.2, CC8.1 | A.8.9, A.8.19, A.8.31, A.8.32 | None | A.6.2.5 |
| Secure software development lifecycleCTL-SDLC | CI runs on the default branch | CC5.2, PI1.2, PI1.3 | A.5.8, A.8.4, A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.33 | None | A.6.1.2, A.6.1.3, A.6.2.2, A.6.2.3 |
| Vulnerability scanning and remediationCTL-VULN-SCAN | Dependabot vulnerability alerts are enabled; Secret scanning is enabled | CC3.2, CC7.1 | A.5.7, A.8.8 | None | None |
Requirement references are read from the TryTrustable control library. A dash means the library maps no requirement in that framework to this control.
All references use the ISO/IEC 27001:2022 numbering. An earlier version of the connector filed the inventory and Dependabot results under 2013 numbers, A.8.1 (A.5.9 in the 2022 edition), A.12.6 (A.8.8 in the 2022 edition); that evidence is expired rather than counted.
What permissions does the GitHub token need?
A fine-grained token with read-only access to Metadata, Contents, Administration, Pull requests, Dependabot alerts and Secret scanning alerts on the repositories in scope, plus organisation Members (read) for the two-factor check. A classic token needs repo and read:org. GitHub shows the organisation's two-factor setting only to organisation owners, so an owner should create the token.
Prefer a fine-grained token scoped to the organisation: a classic token's repo scope also grants write access, because that is how GitHub groups it, and the connector needs none of it. Every request the connector makes is a GET.
How to connect GitHub
- In GitHub, an organisation owner creates a fine-grained personal access token for the organisation with the read permissions listed above
- In TryTrustable, open Integrations, choose GitHub and paste the token. Add the organisation login if the token belongs to several organisations; otherwise the first one it belongs to is used
- The first sync runs immediately and the results appear on the account card. Passing checks land in the evidence ledger as automatic evidence
The token is encrypted at rest with AES-256-GCM and is never written to logs. Removing the account deletes the stored credential.
What the GitHub integration does not do
It does not scan code. Static analysis, dependency and secret scanning of the code itself run in your pipeline through the SDK and CI gate, which is how compliance as code works on the platform. It does not change repository settings, open issues or comment on pull requests. And it cannot tell you whether a review was careful, only whether one happened and who gave it.
The things people ask us
What permissions does the GitHub token need?
A fine-grained token with read-only access to Metadata, Contents, Administration, Pull requests, Dependabot alerts and Secret scanning alerts on the repositories in scope, plus organisation Members (read) for the two-factor check. A classic token needs repo and read:org. GitHub shows the organisation's two-factor setting only to organisation owners, so an owner should create the token.
Does the GitHub integration read our source code?
No. It reads metadata: the organisation record, the repository and branch lists, branch protection and rulesets, pull requests and their reviews. To find CODEOWNERS and CI configuration it lists the file names in the repository root, .github, .github/workflows and docs on the default branch; it never fetches a file's contents or clones a repository. For Dependabot and secret scanning it asks for a single alert only to learn whether the feature is on.
Which repositories does it check?
It inventories up to 500 repositories in the organisation. The branch, review, CODEOWNERS, CI, Dependabot and secret-scanning checks run on the ten most recently pushed repositories that are not archived, because that is where change happens. The two pull-request checks look at the five most recent of those. Every result names the repositories it evaluated.
What happens on GitHub Free with private repositories?
Branch protection and rulesets are not available for private repositories on GitHub Free, and the API says so. The protection-based checks then report not applicable with the plan limitation named, never pass, even if other repositories pass. The remediation shown is the one an auditor will accept: upgrade the plan, or document a compensating control and file it as evidence.
Why does a check say could not verify?
Because GitHub refused or failed the request, most often for a missing token permission. The check does not guess: Dependabot, for example, fails only when GitHub says the feature is disabled. Give the token the permission named in the result and sync again.
How often are the GitHub checks re-run?
The first sync runs as soon as you connect. After that the platform's scheduler re-syncs each connected account on a fixed interval, six hours by default, and you can press Sync at any time. Scheduled and manual syncs run the same code, so they cannot drift apart.
Does it work with GitHub Enterprise Server?
Not today. The connector calls api.github.com, so it covers organisations on GitHub.com, including GitHub Enterprise Cloud organisations hosted there. A self-hosted GitHub Enterprise Server instance has its own API address, which the connector does not accept.
See your GitHub organisation checked live.
Thirty minutes. We connect a read-only token and show the change-management results, with the pull requests behind them, landing as evidence.