GitHub

Access

Code Repository

Mycroft records the approval behind every merge to a protected branch in GitHub, and tests that branch protection stayed in force.

Change management usually fails not because the process is wrong but because a year of evidence is hard to reconstruct. That record already exists in pull request history. Mycroft stores it and includes repository and team permissions in access reviews.

Find out more

How Mycroft connects to GitHub

How it connects: You install Mycroft's GitHub App on your organization. That is the tighter of the two permission boundaries GitHub offers; a GitHub OAuth App connection is also supported.
What Mycroft can access: Granted scopes are repo and read:org. repo is GitHub's broad repository scope and does include code. Mycroft runs a read-only pull model: it does not write to your repositories, store code, or train models on it. The OAuth App does request write permissions that Mycroft does not use, which is the reason for moving to the dedicated app.

Which controls GitHub evidence maps to

Each row is a control an auditor tests and the specific artifact Mycroft collects from GitHub to satisfy it. Collection runs on a schedule and every result is timestamped.

GitHub compliance control mappings and the evidence Mycroft collects for each
Framework	Control	What it requires	Evidence collected from GitHub
SOC 2	CC8.1	Changes are authorized, designed, tested and approved before implementation.	Pull request records for every merge to a protected branch: author, reviewers, approval timestamp, checks status and merge time.
SOC 2	CC6.1	Logical access controls restrict access to information assets.	Repository, team and outside-collaborator permission inventory across the organization, with admin holders enumerated.
SOC 2	CC6.3	Access follows least privilege and is removed when no longer needed.	Organization member and collaborator lists reconciled against the workforce roster, surfacing accounts belonging to departed staff.
SOC 2	CC7.1	Monitoring detects vulnerabilities and configuration changes.	Secret scanning, push protection and Dependabot alert state per repository, with open alert counts by severity and age.
ISO 27001	A.8.4	Access to source code is appropriately restricted.	Per-repository permission matrix showing which teams and individuals hold read, write and admin access.
ISO 27001	A.8.32	Changes to information systems follow change management procedures.	Branch protection configuration (required reviews, required status checks, dismissal of stale approvals, restrictions on force pushes) evidenced continuously rather than at a point in time.
ISO 27001	A.8.28	Secure coding principles are applied.	Code scanning and secret scanning enablement per repository, with alerts tracked to resolution.
ISO 27001	A.8.25	A secure development lifecycle is established.	Required status checks on protected branches showing that automated tests and security gates ran before merge.
HIPAA	§164.308(a)(4)	Access to systems handling ePHI is authorized and periodically reviewed.	Repository access review records with reviewer, decision and date for every collaborator on repositories in scope.

What Mycroft collects automatically

Gathered from GitHub on a schedule, dated and stored against the controls above.

Pull request history with author, reviewers, approvals, required checks and merge timestamps
Branch protection rules on default and release branches, including force-push and admin-bypass settings
Organization member, team and outside-collaborator permission inventory
Repository visibility (public, private, internal) across the organization
Secret scanning, push protection, code scanning and Dependabot enablement per repository
Open security alerts by severity with first-seen date and time-to-remediate
Two-factor authentication enforcement status on the organization

Manual work this removes

The tasks that disappear from someone's quarter once GitHub is connected.

Reconstructing a year of pull request approvals for the auditor's sample
Screenshotting branch protection settings repository by repository
Comparing the organization member list against the leaver list by hand
Recording which administrators can bypass branch protection
Confirming Dependabot alerts were triaged rather than dismissed

Often connected alongside:

All integrations →

GitHub and Mycroft: frequently asked questions

The GitHub OAuth App is granted the repo scope, which is GitHub's broad repository scope and does include code. Mycroft runs a read-only pull model: it does not store your code, train models on it, or write to your repositories. Installing Mycroft's GitHub App rather than the OAuth App gives a tighter permission boundary.

An auditor testing CC8.1 selects a sample of production changes and asks you to demonstrate each was authorized, reviewed and approved before release. Mycroft holds the pull request record for every merge to a protected branch (author, reviewers, approval timestamp, required checks) so the sample is answered from stored evidence rather than by searching Git history.

Yes, and this is the distinction that matters. Mycroft records branch protection configuration on a continuous schedule, so you can show it was in force across the audit period, not just that it is on today. Protection that was switched on shortly before fieldwork is visible for what it is.

Yes, for GitHub Enterprise Cloud. The App is installed on your enterprise organization the same way. Teams running GitHub Enterprise Server should confirm network reachability during setup, since Mycroft needs API access to the instance.

They surface as findings, which is the useful outcome. Repositories without required reviews on the default branch appear as a gap against CC8.1 and ISO 27001 A.8.32, so you either bring them into scope or document the exception before an auditor finds it for you.

We turn the compliance nightmare into a dream

Talk to us