Connect GitHub to CYBRET.
CYBRET reads the code, the workflows, and the OIDC trust chain that makes a pull request a privileged identity in your cloud. The supply chain and the cloud are the same path; we draw it.
Source, supply chain, and the trust to your cloud.
The GitHub integration is a GitHub App. Once installed, CYBRET reads what it needs to reason about code-to-cloud paths. Source goes into the reachability engine; workflow files and OIDC trust go into the supply-chain side of the graph.
- Repositories: code (read-only), default branch, branch protection rules, code-owners, CODEOWNERS coverage gaps, repository visibility.
- Workflows: Actions workflow files including triggers, permissions blocks, OIDC
id-tokenrequests, marketplace and reusable workflow references, self-hosted runner labels. - Secrets and environments: secret names and scopes (we never read secret values), environments and their protection rules, deployment branches, required reviewers.
- Dependencies: the dependency graph that GitHub maintains per repository, plus SBOM data when CycloneDX or SPDX manifests are present in the repo.
- Permissions: organization and repository membership, team structure, outside collaborator graph, fine-grained PAT and SSH key inventory at the org level (where org admin grants the audit scope).
- Telemetry: audit log via the GraphQL audit log API, Code Scanning and Dependabot alerts (optional, ingested as a contributor signal).
What we find in the first week.
GitHub-to-cloud paths are the highest-impact category we surface today. They're also the ones nobody owns end-to-end: AppSec sees the workflow file, Cloud sees the IAM trust, and the path between them is invisible until something breaks.
1. pull_request_target reads PR-supplied code
Workflow with pull_request_target → actions/checkout with PR ref → build step runs untrusted code with repo secrets in env.
The workflow uses pull_request_target for label-based gating, but the checkout step pulls the PR head. Anyone with PR rights can ship a build script that exfiltrates the repo's secrets. CYBRET parses the workflow YAML, recognises the checkout-of-PR-head pattern under pull_request_target, and pairs it with the secrets scope of the repo. The path is closed by switching to pull_request or removing the checkout.
2. OIDC trust + id-token: write = anyone with PR rights becomes cloud admin
Workflow grants id-token: write on PRs → AWS IAM trust policy keys on repo:org/repo:* → role has s3:*, iam:PassRole.
The trust policy's sub claim isn't scoped toref:refs/heads/main; any branch (and therefore any PR) can mint the token. CYBRET resolves the OIDC subtemplate, looks at the corresponding cloud trust policy on the other side, and shows the effective permission set an attacker inherits. This is one of the most common high-severity findings on first connect.
3. Self-hosted runner reachable from the public internet
Public repo with self-hosted runner label → PR triggers a job → attacker poisons the build cache → next pipeline runs attacker code with prod secrets.
Self-hosted runners that pick up jobs from public repos are persistent machines with privileged access. CYBRET enumerates the runner labels, identifies which workflows route to them, and joins that to the repository visibility. The remediation is either making the repo private or moving the runner behind a job-level allowlist.
One GitHub App, read-only scopes.
CYBRET ships a GitHub App that you install on the org or selected repositories. The App holds read-only scopes; we never request write access on first install.
- Open the CYBRET console and go to Integrations → GitHub.
- Click Install GitHub App. You'll be redirected to GitHub to choose org and repo scope.
- Pick the repositories. We recommend org-wide for first build, scoped to a subset for trial.
- Approve the read scopes. They are visible at install time:
contents: read,actions: read,members: read,metadata: read,secret_scanning_alerts: read(optional),code_scanning_alerts: read(optional). - Wait for the first scan. Each repository's graph builds in parallel; large repos complete inside fifteen minutes. Reachable paths land in Exposure Intelligence as files index.
- Optional: enable the audit log webhook for runtime correlation, and the Jira / ServiceNow finding bridge if you want CYBRET findings to land in your existing tracker.
To revoke, uninstall the GitHub App. Source data is purged from the CYBRET tenant within seven days, and we maintain a deletion log you can retrieve.
Read-only at install. Source never leaves your tenant.
The GitHub App requests read scopes only. We do not request write to contents, workflows, or pull requests. Source code is cloned into the CYBRET deployment in your VPC for analysis; it is not transmitted to a multi-tenant backend, not used to train models, and not retained after a graph is built unless you explicitly enable historical retention. File-level redactions (e.g. files matching **/*.secret.yml) can be configured in the integration settings.
For runtime detection, the optional audit-log webhook delivers events to the customer-tenancy CYBRET deployment. Customers who cannot accept a GitHub App can run the integration via a fine-grained PAT held in the CYBRET vault; the same scopes apply. Self-managed and air-gapped customers run the same App against GitHub Enterprise Server.
Where GitHub data shows up in the platform.
Exposure Intelligence is the product that benefits most. The reachability engine joins the source code (handlers, ORM models, RBAC checks) to the supply chain (workflows, secrets, OIDC trust), then to the cloud (IAM, network, data). The most-reported finding on first GitHub connect is a code-to-cloud path that no single tool in the stack would have caught.
Validation uses GitHub context to choose the right proof-of-exploit. When CYBRET claims a handler is BOLA-vulnerable, Validation reads the controller code and the OpenAPI spec to construct the exact request that confirms it. The proof is a non-destructive read against a non-production replica.
Runtime Detection uses the GitHub audit log as one signal among many. A PR that adds anid-token: write permission to a workflow shows up as a pre-deploy alert; a self-hosted runner that suddenly accepts jobs from a fork triggers a runtime watch. Runtime is strongest paired with the application-side collector.
Questions security engineers actually ask.
How does authentication work?
A GitHub App installed on your organization or selected repositories. The App uses GitHub-issued installation tokens; we hold the App private key in a per-tenant KMS-backed vault and never see your personal access tokens.
Where does the source code go?
Into the CYBRET deployment running inside your VPC. Source is cloned for analysis and either purged after the graph is built or retained per your configured retention. We do not move source to a multi-tenant backend, do not train models on it, and do not share it across customers.
GitHub Enterprise Server (self-hosted)?
Supported. The same GitHub App is installed on your GHES instance; CYBRET reaches it from the customer-tenancy deployment over your private network. Air-gapped GHES is supported on the same model.
What about API rate limits?
GitHub App installation tokens get a 5,000 requests/hour pool per installation, plus 15,000/hour for orgs. CYBRET uses GraphQL for inventory, REST for code retrieval, and respects the secondary rate-limit envelope. Large orgs build inside the standard 24-hour window.
Can we exclude repositories?
Yes. The App scope itself is the first cut (org-wide vs selected repos). Inside scope, per-repo and per-path exclusions let you keep contracts, customer data fixtures, or third-party vendor code out of the graph.
GitLab and Bitbucket?
Both are on the integrations roadmap. GitLab beta is available for design partners today on the same scopes model.
Connect GitHub →
Install the App, pick the org, watch the code-to-cloud paths resolve. Most pilots see at least one critical OIDC path inside the first twenty-four hours.
Connect GitHubSee Exposure Intelligence