veriomGitHub repository access
Connect personal and organization installations for scoped reviews and human-approved pull requests.
Veriom uses one GitHub App for account authorization, source selection, audits, and approved remediation. A workspace can connect multiple personal and organization installations, and each installation keeps its own repository boundary.
Connect
- Sign in to Veriom and choose a workspace.
- Select Repositories → Add repositories, or connect GitHub during workspace setup.
- Choose an existing GitHub connection or connect a personal or organization account.
- Authorize access in GitHub, then choose the repositories for the named Veriom workspace.
- Confirm your selection. The GitHub window closes and your workspace updates on the same page.
The callback verifies the actor, account, installation, and accessible repositories before presenting your choices. Temporary GitHub user authorization is discarded after verification. A GitHub installation can be connected to several Veriom workspaces, and each workspace chooses its own repositories. You need Owner or Admin access to the destination workspace and GitHub access to the repositories you select.
Add repositories later
Open Repositories → Add repositories in the workspace you want to update. Choose the existing GitHub account and select the additional repositories. Repositories already connected to that workspace remain selected, including repositories added by another workspace member.
After GitHub authorization, the account connection is retained even if you close the repository picker. You can return to Add repositories to finish choosing projects later.
If a repository is missing, use Manage access in GitHub to add it to the App's installation access. Return to Veriom and choose repositories again to refresh the available choices. Granting GitHub access alone does not add that repository to every connected workspace.
To use the same GitHub organization in another workspace, open that workspace's Add repositories dialog, choose the existing organization, and authorize its separate selection. Direct GitHub installation links ask you to select a destination when several workspaces are available.
Choose a branch and repeatable scope
Repository reviews capture the selected branch and exact commit. Use saved audit profiles for branch and include/exclude directory choices, inspect repository health history, and compare successful audits of compatible scopes. Follow repository reviews and branch comparisons for the complete flow.
Access by operation
The App has the capability to read source and publish pull requests, but each operation receives a short-lived token narrowed to what it needs:
| Operation | Effective access |
|---|---|
| Sign in and connect | identify the actor and verify the installation |
| Run an audit | metadata read and contents read for one selected project |
| Check a pull request | pull requests read and checks write for one selected project |
| Publish remediation | contents write and pull requests write for one selected project |
| Modify workflow files | workflows write, requested only when an approved patch touches .github/workflows/ |
Source write access is never used during an audit. Checks write is limited to the Veriom architecture guard status and its evidence summary; it cannot change source, branch protection, or pull-request content. Publishing remediation still requires an Analyst, Admin, or Owner to approve the proposal. Veriom never merges automatically.
Manage the connection
The Integrations page shows every connected account, account type, project count, installation status, and a direct management link. The Repositories page groups projects by provider and account, supports server-side account or project search, and uses cursor pagination so even large organization inventories remain manageable without merging their access boundaries. If the App is suspended, removed, or loses required permissions, new work is blocked while historical reviews remain available.
Prefer least privilege
Veriom supports selected-project and all-project installations. Choose only the repositories the workspace is expected to review whenever that boundary is practical.
Protect merges with architecture evidence
In Continuous audits → GitHub events, enable Pull request checks. For every opened, reopened, ready-for-review, or synchronized pull request that matches the branch, path, and size policy, Veriom audits the exact head commit and posts Veriom architecture guard. The check includes:
- added, removed, and changed architecture entities and relationships;
- trust-boundary movements and privilege changes;
- newly reachable paths from public or untrusted entry points to sensitive assets;
- newly failing versioned invariants, insufficient evidence, and the consequence gate verdict.
The first run captures a neutral baseline. Later runs succeed when no invariant newly fails, and fail when a new invariant failure or release-blocking consequence is present. If another audit is active, the check remains queued and follows the policy's conflict behavior. Human-approval policies publish action_required before any audit starts.
Existing installations must accept the new Pull requests: read and Checks: write permissions before native checks can run. Historical results remain available while permission repair is pending.
Alternatively, add the deterministic merge-check workflow. That repository-owned workflow uses contents: read and publishes its own job result, which is useful when an organization does not permit App-authored check runs.
If code also lives in GitLab or Bitbucket, use the read-only repository provider connections. Their project inventory and exact-revision audits share the same explicit selection and evidence contract, but their credentials are never reused for remediation writes.
Was this guide useful?
Your response stays in this browser unless you open a GitHub issue.