Privacy & Data Handling

Last updated: 2026-05-11

This document describes what RepoWave processes when installed as a GitHub App, used through the CLI, or used through the hosted service at repowave.dev.

This document is a product-specific operational draft and should be reviewed by counsel before broad commercial rollout.

What we receive from GitHub

When you install RepoWave on a repository or organization, GitHub sends signed webhook events to the Service. Depending on configuration, RepoWave may process:

• Installation ID and account metadata.
• Repository owner, name, visibility, default branch, and selected settings.
• Commit SHAs, branch names, pull request metadata, issue metadata, labels, comments, check runs, workflow metadata, and delivery IDs.
• GitHub App permissions and installation scope.

Webhook payloads do not normally include repository secrets. RepoWave should not request or store GitHub secrets.

What we read from repositories

When a scan runs, RepoWave may use a GitHub App installation token or other authorized credential to read selected repository content needed for analysis.

RepoWave may read:

• Python, FastAPI, GitHub Actions, Docker, dependency, and configuration files.
• Pull request diffs, issue content, comments, labels, and check output when a rule or workflow needs them.
• Repository paths and identifiers needed to report findings.

RepoWave should not intentionally read or persist files that are blocked by the configured denylist, such as .env files, secrets directories, credential files, token files, private keys, or other sensitive paths.

What we persist

RepoWave may store:

• Account, organization, repository, and installation identifiers.
• Scan jobs, statuses, timestamps, retry counts, and finding counts.
• Finding records such as rule ID, severity, category, message, file path, line number, confidence, and related metadata.
• Audit records for writes performed through GitHub, such as draft pull request creation or comments.
• Billing plan, subscription status, marketplace account identifiers, and support contact information when paid plans are enabled.
• Operational logs needed for debugging, abuse prevention, security, and service reliability.

RepoWave should not persist full repository contents, secrets, private keys, generated patches, or complete cloned worktrees unless a future feature explicitly documents that behavior and receives user authorization.

What we write back to GitHub

When write permissions are enabled, RepoWave may:

• Create branches and draft pull requests.
• Post pull request comments, commit comments, or check summaries.
• Open or update issues.
• Add labels or status checks.
• Record write actions in audit logs.

Users are responsible for reviewing generated output before merging, deploying, or relying on it.

Retention

Default retention targets:

• Scan jobs, findings, and write audit rows: 90 days.
• Operational logs: as provided by the hosting/logging provider, usually short operational windows.
• Installation records: kept while the GitHub App remains installed.
• Deleted or uninstalled installations: purge associated installation data within 30 days where technically practical.
• Billing records: retained as needed for tax, accounting, fraud prevention, and payment processor requirements.

Subprocessors

| Subprocessor | Role | | --- | --- | | GitHub, Inc. | GitHub App platform, repository authorization, marketplace billing where enabled | | Render Services, Inc. | Application hosting, managed database, managed background services where used | | Payment processor TBD | Subscription billing, checkout, receipts, fraud checks, and payment records when enabled | | Email/support provider TBD | Support communications and operational notices when enabled |

Additional subprocessors should be added before production use if RepoWave adds analytics, customer support tooling, AI providers, error monitoring, email, or other third-party services.

AI providers and model training

RepoWave's current public positioning is static analysis and bounded automation. If AI providers are added, the product must disclose what data is sent, what is stored, whether outputs are retained, and whether customer content is used for model training.

Default policy target: customer repository content should not be used to train third-party models unless a customer explicitly opts in through a separate, clear agreement.

Security controls

• Webhooks should be HMAC-SHA256 signed and rejected when signatures are invalid.
• GitHub App private keys and tokens must be stored only in approved secret stores.
• Repository clones should be temporary and deleted after scan completion.
• Sensitive paths should be denylisted and excluded from persistence.
• Write actions should be logged for auditability.
• Production database connections should require SSL.

User controls

• Revoke access by uninstalling the GitHub App from GitHub settings.
• Request export or deletion by emailing support@repowave.dev.
• Remove repository access by narrowing the GitHub App installation scope.
• Cancel paid plans through the billing channel used at checkout or through GitHub Marketplace when applicable.

Contact

Privacy questions: support@repowave.dev