Most security platforms treat GitHub as an afterthought. CloudVista runs 25 automated security checks across your GitHub organisation — branch protection, secret scanning, Dependabot, Actions permissions, org 2FA — and surfaces findings alongside your AWS, Azure, OCI, and GCP posture in one place.
Get Started Free View Live DemoGitHub is where your code lives, your CI/CD pipelines run, and your secrets often end up. It's also the vector for some of the highest-profile supply chain attacks in the last five years — from SolarWinds to the GitHub Actions token compromise affecting thousands of repositories.
Yet most cloud security tools stop at the cloud provider boundary. They scan your AWS S3 buckets and Azure VMs, but leave your GitHub repositories completely unaudited. The result: security teams pass SOC 2 audits with open Dependabot alerts, unprotected default branches, and GitHub Actions workflows that can write to any repository.
CloudVista adds GitHub as a first-class provider — the same way it treats AWS, Azure, OCI, and GCP. Security checks run automatically on your sync schedule. Findings appear in your unified posture score. Compliance evidence is collected for your auditors.
Key stat: According to GitHub's own 2024 security report, 40% of enterprise organisations have at least one repository with branch protection disabled on the default branch. CloudVista surfaces this in seconds after connecting.
When you connect a GitHub organisation to CloudVista, the following resource types are inventoried on each sync:
Name, 2FA enforcement status, verified domains, billing plan
Visibility, branch protection, default branch, archived status, last push, topics
Workflow name, path, state, last run status, permissions scope
Per-repository deploy keys, read/write flag, created date, expiry status
Login, organisation role (member/owner), 2FA enabled status
All resource data is stored in CloudVista's inventory and searchable from the main inventory view. You can filter by repository visibility, branch protection status, or member 2FA state — the same way you filter EC2 instances or Azure VMs.
CloudVista runs the following checks automatically on each sync. Findings include the affected repository or resource, severity, and compliance control mappings.
| Check | Severity | What It Detects |
|---|---|---|
| Critical-severity Dependabot vulnerability alerts open | Critical | The repository has one or more open Dependabot alerts rated critical severity (CVSS 9.0–10.0). (CIS 4.6) |
| Organisation does not require two-factor authentication | Critical | Detects GitHub organisations that do not enforce two-factor authentication (2FA) for all members. (CIS 1.2.2) |
| Repository has exposed secrets detected by secret scanning | Critical | GitHub secret scanning detected one or more secrets (API keys, tokens, passwords, certificates) committed to this repository. (CIS 4.6) |
| Secret scanning is not enabled | Critical | GitHub's native secret scanning is not enabled for this repository. (CIS 4.5) |
| Branch protection allows force pushes | High | The default branch has a protection rule but force pushes are permitted. (CIS 4.2.2) |
| Dependabot alerts unresolved on inactive repository | High | Detects repositories with open Dependabot vulnerability alerts that have not been addressed on repositories with no recent commits (> 90 days). (CIS 2.4.1) |
| Fork pull requests can trigger workflows with secrets | High | Detects private repositories where workflows triggered by pull requests from forks can access repository secrets. (CIS 4.2.5) |
| High-severity Dependabot vulnerability alerts open | High | The repository has one or more open Dependabot alerts rated high severity (CVSS 7.0–8.9). (CIS 4.6) |
| Open code scanning (SAST) alerts detected | High | Detects repositories with open code scanning alerts from GitHub Advanced Security (CodeQL or third-party SAST tools). (CIS 2.4.2) |
| Production environment has no required deployment reviewers | High | Detects production-like deployment environments (named prod, production, live, or release) with no required reviewers configured. (CIS 4.3.5) |
| Repository default branch has no protection rules | High | The repository's default branch has no branch protection rule. (CIS 4.2) |
| Branch protection does not require pull request reviews | Medium | The default branch has a protection rule but pull request reviews are not required before merging. (CIS 4.2.3) |
| Dependabot vulnerability alerts are disabled | Medium | Dependabot vulnerability alerts are not enabled for this repository. (CIS 4.4) |
| Dependabot vulnerability alerts are not enabled | Medium | Dependabot vulnerability alerts are not enabled for this repository. (CIS 4.6) |
| GitHub Actions uses unpinned action versions | Medium | Detects workflows referencing third-party actions by branch (e.g. (CIS 4.2.4) |
| GitHub Actions workflow has overly broad permissions | Medium | Detects GitHub Actions workflows that use write-all permissions or have no top-level permissions block, granting the GITHUB_TOKEN more access than necessary. (CIS 4.2.3) |
| Organisation allows GitHub Actions from any source | Medium | The organisation's Actions policy is set to allow workflows from any source. (CIS 4.1) |
| Protected branch does not require signed commits | Medium | The default branch has a protection rule but does not require commit signature verification. (CIS 1.1.10) |
| Repository has open Dependabot vulnerability alerts | Medium | Open Dependabot alerts indicate that one or more third-party dependencies have known security vulnerabilities (CVEs). (CIS 4.5) |
| Repository has write-enabled deploy keys | Medium | The repository has one or more deploy keys with write access. (CIS 1.3.5) |
| Repository is publicly visible | Medium | The repository is visible to the public internet - its code, commit history, and issues are readable by anyone. (CIS 1.1.15) |
| Stale pull-request approvals are not dismissed on new commits | Medium | The default branch requires pull-request reviews but does not dismiss existing approvals when new commits are pushed, so approvals remain valid for code that was never actually reviewed. (CIS 1.1.4) |
| Write-access deploy keys have no expiry | Medium | The repository has one or more deploy keys with write access. (CIS 4.3) |
| No CODEOWNERS file defined | Low | Detects repositories that have no CODEOWNERS file, meaning pull requests have no automatic reviewer assignment. (CIS 1.1.14) |
| No security policy (SECURITY.md) found | Low | Detects repositories that have no SECURITY.md file defining a vulnerability disclosure policy. (CIS 1.1.12) |
Every GitHub security check in CloudVista is mapped to one or more compliance framework controls. When a check fails, the finding includes the specific control IDs it violates — making evidence collection and audit preparation straightforward.
| Check Category | CIS GitHub | SOC 2 | ISO 27001 | NIST SP 800-53 |
|---|---|---|---|---|
| Branch Protection | 1.1, 1.2, 1.3 | CC8.1 | A.12.1.2 | CM-2, CM-3 |
| Secret Scanning | 2.1, 2.2 | CC6.1 | A.9.4, A.12.6 | AC-3, SC-28 |
| Dependabot / Vulnerabilities | 3.1, 3.2 | CC7.1 | A.12.6.1 | SI-2, SI-3 |
| Actions Permissions | 4.1, 4.2 | CC6.6 | A.9.2, A.9.4 | AC-6, CM-7 |
| Org 2FA Enforcement | 1.5 | CC6.1 | A.9.3, A.9.4 | IA-2, IA-5 |
Compliance findings feed directly into the CloudVista compliance posture dashboard. If you're tracking SOC 2 readiness, your GitHub posture score is included alongside your AWS and Azure scores. Evidence snapshots are captured automatically for audit export.
Connecting a GitHub organisation takes under 5 minutes. You need a GitHub Personal Access Token (PAT) with the following read-only scopes:
repo read:org read:user security_events
No write access is required at any level. CloudVista only calls GitHub's REST API — it never reads, stores, or transmits code content.
Security note: CloudVista recommends using fine-grained PATs with organisation resource owner scope rather than classic tokens. Fine-grained tokens allow you to restrict access to specific repositories and set a mandatory expiry date.
CloudVista runs 25 automated GitHub security checks: branch protection missing, force push allowed, no required reviews, secret scanning disabled, public secret scanning alerts open, Dependabot disabled, Dependabot alerts open, GitHub Actions write permissions, GitHub Actions allowed from any repo, CODEOWNERS file missing, org 2FA not enforced, default branch not protected, and deploy keys without expiry.
CloudVista uses a Personal Access Token (PAT) with four read-only scopes: repo, read:org, read:user, and security_events. No write access is required. The token is AES-256 encrypted at rest. CloudVista calls GitHub's REST API only — no code content is ever read or stored.
Yes. CloudVista shows findings from all connected providers in a single unified view. You can filter by provider (GitHub, AWS, Azure, OCI, GCP, VMware), severity, status, or compliance framework — across your entire estate in one table.
No. CloudVista does not read code content. For secret scanning, CloudVista reads the count of open secret scanning alerts from GitHub's native scanner via the security_events API scope. The actual secret details remain in GitHub — CloudVista only surfaces whether open alerts exist and how many.
GitHub is supported as a provider on the free tier. The free plan covers up to 100 resources across all connected providers — GitHub repositories, members, and workflows all count toward this limit. Security checks and compliance mapping are included on all plans.
Yes. Each GitHub organisation is added as a separate credential in CloudVista. There is no limit on the number of organisations you can connect. Findings and inventory from all organisations appear in the unified view with an organisation label for easy filtering.
Connect your GitHub organisation and get your first 25-check security report in under 5 minutes — no agents, no code access, no configuration beyond a read-only PAT.
Get Started FreeAlso see: GitHub Security Blog Post · Compliance Guide · Multi-Cloud Inventory