--- title: "Planned GitHub App boundaries · GSCDump" canonical_url: "https://gscdump.com/trust" last_updated: "2026-07-29T12:10:50.644Z" meta: description: "The proposed GitHub App permissions and data-handling boundaries for the private-beta gscdump Fix product." "og:description": "The proposed GitHub App permissions and data-handling boundaries for the private-beta gscdump Fix product." "og:title": "Planned GitHub App boundaries · GSCDump" --- gscdump on GitHub # GitHub App launch boundaries. Fix is still in private beta, and its GitHub App is not open for general installation. This page records what the app must be allowed to do and how it must handle repository data before installation opens. ## Permissions Proposed scopes The proposed permission set for the private beta. These scopes must be checked against the final GitHub App manifest before installation opens. GitHub recommends requesting only the minimum permissions required. If an installed app later requests more, the account owner must approve the change or that installation keeps its old permissions. See GitHub's [~~permission guide ~~](https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app). GitHub's merge endpoint accepts installation tokens with Contents write, so “can create commits but cannot merge” is not a distinct app permission. The launch boundary needs two controls: gscdump must not call that endpoint, and the repository must enforce a protected default branch without an app bypass. See the official [~~merge endpoint permissions ~~](https://docs.github.com/en/rest/pulls/pulls#merge-a-pull-request) and [~~ruleset controls ~~](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-a-pull-request-before-merging). TABLE · GitHub App scope plan8 scopes Proposed GitHub App permissions and why each permission is needed | **scope ** | **level ** | **why ** | | --- | --- | --- | | **Contents** | R+W (planned) | Read repository files and create commits. GitHub does not limit this scope to `gscdump/` branches, so branch naming is an application rule, not a permission boundary. | | **Pull requests** | R+W (planned) | Open pull requests with proposed fixes and descriptions. You decide whether to merge. | | **Metadata** | Read | Required by GitHub for any app install. | | **Checks** | Write (planned) | Post verification results, such as URL Inspection output, on the pull request. | | **Issues** | None | We do not read or write issues. Out of scope. | | **Actions** | None | No access to workflow runs, logs, artifacts, or Actions settings through the Actions APIs. | | **Workflows** | None | No access to modify files under `.github/workflows`. Tracked workflow YAML can still be read through Contents access. | | **Secrets** | None | No access to Actions secret metadata or management APIs. Sensitive values committed to repository files remain visible through Contents access. | ## Launch requirements Required before release - [!]Enforced default-branch boundary The service writes only to `gscdump/` branches. The installation gate must also verify an active ruleset or branch-protection rule on the default branch and ensure the app has no bypass. - [!]No merge calls The service must never invoke GitHub merge endpoints. Contents write is enough to authorize the merge endpoint, so this is an application control backed by repository rules, not a separate permission toggle. - [!]No force-pushes The design permits new commits on its feature branch, not history rewrites. - [!]No background PR review The planned app will not subscribe to unrelated pull-request comments or push events. - [!]User-controlled runs The proposed controls are manual invocation plus weekly, monthly, or disabled schedules. - [!]Narrow analyzer input Contents read is repository-wide. The pipeline must allowlist files needed for the detected issue, exclude sensitive paths, and record which files reach analysis. ## Data handling Current GSC storage and the proposed Fix data path are listed separately below. **GSC data** Stored in a per-user Cloudflare D1 database and team-scoped R2 Parquet storage. OAuth tokens are application-encrypted before database storage. **Repo contents during an audit** The proposed private-beta design uses a shallow clone in ephemeral compute. Because Contents access is repository-wide, the clone can include any tracked file; deletion and retention controls must be tested before launch. **Secrets in repo files** The launch gate must combine a file allowlist with secret scanning. Excluding `.env*`, `*.pem`, `*.key`, and `secrets/*` is a minimum denylist, not a guarantee that committed credentials are absent. **LLM inputs** The proposed pipeline sends only the generated diff and issue type for pull-request description drafting. This boundary is a launch requirement, not a description of the current read product. **Analytics** The planned Fix telemetry is limited to aggregated operational metrics. ## Compliance Certification roadmap No third-party certification listed here is complete. Treat this table as a roadmap, and email us if a control is a prerequisite for your team. Current availability and timing for planned compliance work | **item ** | **status ** | **timing ** | | --- | --- | --- | | **DPA** | on-request | Email hello@gscdump.com | | **SOC 2 Type I** | planned | Targeted on first enterprise agreement | | **SOC 2 Type II** | roadmap | After Type I + 6 months evidence | | **ISO 27001** | not-yet | Based on customer demand | | **HIPAA** | n/a | Not offered for workloads containing PHI | ## Questions ## Contact still have questions? email [~~hello@gscdump.com~~](mailto:hello@gscdump.com) or [~~security@gscdump.com~~](mailto:security@gscdump.com) for security issues. [**← Back to home **](https://gscdump.com/)