Metadata in, evidence out. The code never leaves GitHub.
Warestack evaluates the process around a change: who opened it, who reviewed and approved it, which checks ran, what deployed, and the linked work item. It does not clone repositories or read file contents. Nothing it writes can block a merge until you require the check in branch protection. This page lists what it reads, what it writes, where the data lives and who can see it.
Verified GitHub App. Permissions are shown on the install screen and can be reduced per repository.
1 blocking Warestack rule violation detected.
Detect pull request scope drift: Linked Linear issue ORB-418, Batch mute alert rules by label, does not match this pull request. The change pins the kaniko executor and passes base_ref through the preview build.
Recommended action: Limit the pull request to ORB-418, or link the issue that describes this build change.
Installed on the repositories you choose.
A GitHub App, not a personal token. Permissions are approved once by an organization admin and shown here as they appear on the install screen. Remove a repository and Warestack loses access to it immediately.
Observing pull requests, reviews, checks and deployments needs read access only. Rules report with no write permission at all.
Posting the Warestack check, commenting on a pull request or requesting a reviewer is a chain step. Each uses the write permission named next to it.
There is no permission for repository contents. Diffs, files and commit contents stay on GitHub.
- Pull request title, author, reviewers, labels, branch and changed file paths
- Reviews, approvals and review comments as events, with who and when
- Check runs and workflow results, pass or fail
- Deployments and deployment reviews, environment and state
- Linked work item key, status, assignee and description
- Organization members, to map handles to people
- File contents or diffs
- Commit contents
- Secrets, environment variables or CI logs
- Slack message content
- Linear or Jira document bodies
Read the pull request and its reviews. Write one comment per pull request, edited in place, and request reviewers when a chain says so.
Read check results. Post the Warestack Rules check run with the finding and next step.
Deployments and deployment reviews: environment, state, approver.
Workflow run results for the release and verification rules. No logs.
Linked GitHub issues for the work item rules.
Repository names, branches and collaborators. Required by GitHub for every app.
Not requested. Warestack cannot read files, diffs or commits.
Organization: read members, to map reviewers and owners to people. Account: read email, for sign-in. Webhooks: pull requests, reviews, check runs, deployments, workflow runs, issues.
Three places, each a chain step you turn on.
Rules only report. Anything that touches a work tool is a step on a chain, with a dry run before it is enabled.
The Warestack Rules check run with the finding and next step, and one comment per pull request, edited in place. Optional: request a reviewer. The check is informational until branch protection requires it.
Post and update messages in channels the app is invited to; direct messages to people who confirmed their link. The app reads channel names and members. It reads no message content.
Linear: admin, read, write, issues:create, actor application. The admin scope is required to install the agent on the workspace. Jira: Atlassian Forge, scoped to the projects you select; the app says so when a project denies it. Neither reads documents or code.
What is stored, for how long, and where.
Warestack keeps the evidence behind each change so a report can answer later. Retention is the plan dimension; the rest is the same on every plan.
TLS in transit. Production volumes and stored objects are encrypted at rest. Access to a space is limited to its members and admins.
Uninstall the app and request deletion of the space. Evidence expires at the end of the plan’s retention.
Space admins control who joins. Members see the record; admins manage rules, chains, integrations and billing. Integrations are admin-only on the API, not only in the UI.
Pull request, review, check, deployment and work item metadata: titles, authors, reviewers, timestamps, states, file paths. Rule results and the evidence rows behind each report.
File contents, diffs, commit contents, Slack message content, Linear or Jira document bodies.
14 days on Free, 90 on Pro, 365 on Enterprise. Rules, chains and reports are kept; the evidence behind each change expires.
The application runs in AWS eu-west-2. Versioned backups are replicated to us-east-1. Enterprise can request dedicated infrastructure.
A current list, with purpose and region, is available on request.
Custom rules are interpreted into checks by a model once, when written; interpretations are pinned and versioned.
Where the program stands.
Stated plainly so a security review takes one read, not a call.
Specified date 30 September 2026. No report has been issued. Policies and evidence are available on request.
Permissions are approved per repository and can be reduced at any time. Admin-only actions are enforced on the API.
Email security@warestack.com, or use the support page. That is the intake for a security report.
Send us the questionnaire.
Send the questionnaire to security@warestack.com. We answer from the permissions, retention, and hosting on this page.
Enterprise adds SSO/SCIM, 365-day retention and dedicated infrastructure on request.