Integrations / Version control & CI
Screenata + GitHubHow do you collect SOC 2, ISO 27001, and HIPAA evidence from GitHub?
Quick answer
GitHub is where change management gets proved, because SOC 2 CC8.1 asks you to show that a change was reviewed and authorized before it reached production, and the pull request record is what shows it. Having GitHub is not the control. The control is the enforced configuration, such as branch protection on production branches and a required approving review, plus the record that the configuration operated across the whole audit period. Screenata runs 21 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to GitHub read-only and runs 21 native checks against your organization: branch protection, review requirements, secrets scanning, and org-wide MFA. Repository scans run on push, code is never persisted, and each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls through a shared control catalog.
21 native checks · read-only · signed evidence
What it proves
GitHub evidence, mapped to controls.
Protection rules on production branches and whether merges require review, verified per repository.
The change management evidence auditors sample first: proof that code cannot reach production without a second set of eyes.
Whether secrets scanning is enabled across repositories so credentials committed to code get caught.
Proof that credential leakage into the codebase is detected, protecting the keys that guard production.
Whether the GitHub organization requires two-factor authentication for members.
Proof that access to your source code requires strong authentication.
Repository-level security configuration across the organization, verified against your policy baseline.
Per-repository findings showing settings match the configuration your policies describe.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on GitHub, and why each matters.
Branch Protection Rules
Without branch protection on the default branch, code can reach production with no enforced gate, which defeats change management. An auditor verifies that every repository protects its default branch.
Require Approving Reviews
If merges do not require an approving review, changes reach production without a second set of eyes, so unauthorized or untested code can ship. An auditor verifies that the default branch requires at least one approval before merge.
Status Checks Required
When passing status checks are not required before merge, untested or failing code can reach production. An auditor verifies that the default branch requires status checks to pass before a merge.
Signed Commits Required
Unsigned commits cannot be tied to a verified author, so change history can be forged and attribution lost. An auditor verifies that the default branch requires signed commits.
Protection Applies to Admins
If branch protection does not apply to administrators, privileged users can bypass review and push straight to production. An auditor verifies that protection rules are enforced for admins too.
Force Push Disabled
Force pushing to the default branch rewrites history and can erase the record of what changed and who approved it. An auditor verifies that force push is disabled on the default branch.
CODEOWNERS Review Required
Without required review from code owners, changes to sensitive paths merge without the accountable reviewer, weakening change authorization. An auditor verifies that the default branch requires CODEOWNERS review.
Linear History Required
A tangled merge history makes it hard to trace which reviewed change introduced a given commit. An auditor verifies that the default branch enforces linear history.
Organization MFA Required
Without organization-wide two-factor authentication, a stolen password is enough to reach your source code. An auditor verifies that the GitHub organization requires MFA for all members.
Secret Scanning Enabled
Credentials committed to a repository stay exploitable until found, and secret scanning is what catches them. An auditor verifies that repositories have secret scanning enabled.
Dependabot Security Updates
Vulnerable dependencies remain exploitable until patched, and Dependabot surfaces and proposes those fixes. An auditor verifies that repositories have Dependabot security updates enabled.
Repositories Not Publicly Visible
A repository set to public can expose source code and embedded secrets to anyone. An auditor verifies that repositories are private unless intentionally published.
GitHub Actions Deployment Evidence
Deployments that leave no record cannot be shown as authorized and tested, which is the core of change management. An auditor reviews recent production deployment runs and their logs as proof that changes followed the defined process.
Production Repository Access Roster
Auditors sample who can push to production code, so an accurate roster of collaborators and their permission levels is needed. This check enumerates the code-access and write or admin populations per repository as the evidence for that sample.
Dependabot Alerts Remediated Within SLA
Known vulnerabilities left open past their remediation window are the ones attackers exploit. An auditor verifies that critical and high alerts are fixed inside the defined SLA and reviews overdue alerts as evidence.
Merged PR Review & CI Evidence Sample
Change management is tested by sampling merged changes to confirm each was reviewed by someone other than the author and passed its checks. This check samples merged pull requests to production and records the review and CI status at merge.
Production Branch Bypass Audit
If protection on production branches can be overridden without a trace, the review gate is only as strong as its exceptions. An auditor reviews override events to confirm branch protection stayed enforced.
GitHub Security Scan Run History
A configured security scan that has not actually run leaves code unexamined between commits. An auditor reviews the run history to confirm security workflows execute on the expected cadence.
Drawn from Screenata’s GitHub check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
What access does Screenata need to GitHub?
A read-only connection scoped to the repositories you select. Scans read configuration and metadata; code is never persisted on Screenata's side, and the connection can be revoked from your GitHub settings at any time.
Does Screenata read my source code?
Scans evaluate repository configuration, branch protection, and security settings. Code is never persisted; what is stored is the finding, hashed and signed, not your source.
How does the GitHub integration help with SOC 2 change management?
CC8.1 asks you to prove that changes are authorized, tested, and reviewed before deployment. Branch protection and required reviews are the technical enforcement of that, and the scan-on-push cadence produces a continuous record instead of a one-time screenshot. Vera also reviews pull requests that touch controlled areas and links them to the relevant control.
What happens when a GitHub check fails?
Vera opens a ticket describing the failing configuration and re-verifies after a human applies the fix. Nothing in your organization is changed by Screenata; the connection is read-only by construction.
What are the steps to implement SOC 2 with GitHub?
First, connect Screenata to GitHub with a read-only scope covering the repositories in scope. Second, let the first scan run so the baseline reflects how the organization is actually configured rather than how you assume it is. Third, fix what fails: enable branch protection on production branches, require an approving review before merge, require status checks to pass, disable force push on the default branch, and turn on secret scanning and Dependabot security updates. Fourth, leave the scheduled scans running so passing results accumulate as signed evidence across the observation window, which for a Type 2 report is usually three to twelve months. Fifth, hand the evidence package to an independent auditor. The audit is a separate engagement with a licensed CPA firm, which issues the report; Screenata prepares and holds the evidence it asks for.
What evidence do auditors ask for about change management?
They pick a sample of merged changes and expect four things for each one. That a review happened before the merge, not after. That an enforced branch protection configuration made the review mandatory rather than a convention people follow. That the approver was someone other than the author. And that the record covers the whole audit period, not a screenshot taken the week before fieldwork. The Merged PR Review and CI Evidence Sample check produces the sample, Branch Protection Rules and Require Approving Reviews show the enforcement, and the Production Branch Bypass Audit shows whether anyone overrode the gate while it was supposedly in force.
Do auditors accept evidence Screenata collects from GitHub?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.
Connect and see
Fifteen minutes after connecting GitHub, you know your real posture.
Related: GitLab · Bitbucket · Azure DevOps · AWS