// DOCUMENTATION
Repository permissions.
A full account of what Veyra can and cannot do with your source code — written to be handed straight to whoever approves the installation.
The principle
Veyra requests the minimum access required to perform the analysis you are paying for, and nothing that would let it change your systems. Where a capability would require broader access, that capability does not ship until it can be requested separately and explicitly.
Permission by permission
- CONTENTS — READ
- Reads the source tree, dependency manifests, lockfiles, and configuration on monitored branches, plus commit history for secret detection. This is the core of the analysis: without it there is nothing to assess. It grants no ability to write, and GitHub will reject any write attempt made with this token.
- METADATA — READ
- Mandatory for every GitHub App. Provides repository names, visibility, default branch, and detected languages. Used to route each repository to the correct analyzers.
- PULL REQUESTS — READ
- Requested only where pull-request analysis is enabled. Lets Veyra see the diff associated with a pull request so security-relevant changes can be assessed before merge. Read-only: Veyra cannot comment, approve, or merge.
- SECURITY EVENTS — READ
- Optional and off by default. Lets Veyra ingest existing Dependabot and code-scanning alerts so they can be deduplicated against Veyra’s own findings rather than sitting in two queues.
- WEBHOOK DELIVERY
- Push events only, used to trigger change-based reassessment. Payload is limited to the metadata needed to decide whether a change is security-relevant.
What Veyra cannot do
These are not policy commitments. They are consequences of the permission set, enforced by GitHub:
- Push commits or create branches
- Open, approve, or merge pull requests
- Modify repository settings, secrets, or environments
- Delete a repository, branch, tag, or release
- Trigger, modify, or read GitHub Actions workflows and their secrets
- Access repositories that were not selected in the installation
- Access any other organization your account belongs to
- Invite, remove, or change permissions of any member
Verify this yourself
Do not take our word for it. Before approving, GitHub shows you the complete permission set the App is requesting. After installation, Settings → Applications → Veyra → Permissions shows the same list at any time. If it ever shows a permission not documented on this page, do not approve it, and tell us at security@veyra.example.
Access inside Veyra
Repository access being read-only does not by itself answer the question of who at Veyra can see your code. That is covered by internal controls:
- Source is retrieved only into an ephemeral, per-assessment analysis environment, and the working copy is destroyed when the run completes.
- Ordinary support personnel cannot browse customer source code. Support tooling exposes finding metadata only.
- Where an investigation genuinely requires deeper access, it is time-bound, justified, approved, and recorded in your audit log — you can see when a Veyra administrator accessed your organization.
- Multi-factor authentication is required for every Veyra team member on every system that touches customer data.
The full detail is in the Trust Center.
Evidence retention
Findings include code excerpts as evidence, limited to the lines needed to explain and reproduce the issue. These are retained for the same period as the parent finding — 90 days, one year, or two years depending on plan — and are deleted when you request deletion. Veyra does not retain a copy of your repository beyond the assessment run.