GitHub compliance for SOC 2, with fixes as pull requests.
Obsinto turns GitHub into SOC 2 change-management evidence: it checks branch protection and reviews, and delivers cloud compliance fixes as pull requests to your Terraform, so every change is reviewed, merged and recorded.
What Obsinto does for you
Change management evidence, automatically
Every reviewed and merged pull request becomes evidence for SOC 2 change management. No exporting PR lists into spreadsheets before the audit.
Compliance as code, without writing policies
When a cloud resource fails a check, Obsinto opens a pull request that fixes the Terraform behind it, so the fix survives the next deploy instead of drifting back.
Fits the workflow you have
Fixes arrive as pull requests in the repo your team already reviews. Your branch rules, reviewers and CI all still apply.
How a compliance fix ships through GitHub
- 01 / DETECT
A cloud check fails, for example a storage account that allows public access.
- 02 / TRACE
Obsinto finds the Terraform in your repository that defines that resource.
- 03 / PROPOSE
A pull request with the exact change is opened against your repository, linked to the control it fixes.
- 04 / REVIEW
Your team reviews and merges it under your normal branch protection and CI.
- 05 / VERIFY
After deploy, the resource is re-checked and the PR, review and result are filed as evidence.
What SOC 2 change management looks like in GitHub
SOC 2 (CC8.1) asks that changes are authorized, reviewed, tested and approved before they reach production. In GitHub that means protected default branches, required reviews, passing checks and a pull request history that shows it all held. Obsinto checks those settings and keeps the history as evidence.
Fix the code, not the console
A fix clicked in the cloud console is overwritten by the next Terraform apply. Obsinto fixes compliance where your infrastructure is defined, so the control stays fixed and the change has a reviewer, a timestamp and a reason.
Where cloud fixes usually stall
Knowing which repositories lack branch protection and which cloud tests fail is the easy part. Obsinto writes the fix as a pull request your team can review and merge, re-checks the resource after deploy, and records the whole change as audit evidence.
What Obsinto covers in GitHub
Repository and change-control checks mapped to SOC 2 change management and NIST 800-53 configuration management.
Branch protection
Protected default branches, required reviews, required status checks, restrictions on force pushes
Change history
Pull requests, approvals and merges kept as change-management evidence
Infrastructure as code
Terraform fixes for failing Azure and cloud checks, delivered as pull requests
Repository settings
Repository visibility and security settings your auditor samples
What access Obsinto needs in GitHub
A GitHub App installed on the repositories you choose, with read access to settings and pull request history.
Write access to repository contents and pull requests, only if you turn on fixes, so Obsinto can push a fix branch and open a pull request. It never pushes to your default branch.
Your branch protection, reviewers and CI decide what merges. Obsinto works inside them.
GitHub compliance questions
What does SOC 2 require for change management in GitHub?
Changes must be authorized, reviewed, tested and approved before production. In GitHub that is shown with protected branches, required reviews, passing checks and a complete pull request history.
Does Obsinto push changes directly to my main branch?
No. Obsinto opens a pull request. Your branch protection, reviewers and CI decide whether it merges.
What GitHub access does Obsinto need?
A GitHub App on the repositories you choose, with read access for evidence. Write access to contents and pull requests is only needed if you want fixes delivered as code.
How is Obsinto different from Vanta or Drata for GitHub?
Both check repository settings, and both can help with Terraform fixes. Obsinto ties the whole loop together: the pull request for a failing cloud resource, the review and merge, the re-check after deploy, and the evidence filed against the control.