GitHub Integration

Overview

The GitHub integration connects your GitHub organization to Fencer through two GitHub Apps, listed in the catalog as GitHub (Code) and GitHub (Monitor). The Code app scans the repositories you choose on pushes and pull requests, and reports results back to GitHub as check runs. The Monitor app forwards your GitHub organization’s webhook events to Fencer’s Security Monitoring (SIEM) for detection.

Prerequisites

• An active Fencer organization with a valid subscription.
• The Administrator role in your Fencer organization.
• Owner access to the GitHub organization where you want to install the apps. If you are not an owner, GitHub asks the organization’s owners to approve the installation instead (see Installing without owner access).
• For the GitHub Monitor app: the GitHub Code app must already be installed, and your plan must include Security Monitoring.

How it works

Fencer uses GitHub’s App installation flow. When you connect from Fencer, a popup takes you to GitHub to install the app and choose which repositories it can access. After the installation, GitHub sends you back to Fencer, which stores the installation and opens the connection’s repository settings, where you choose which of those repositories to scan.

The Code app listens for webhook events (check_suite, check_run, installation, installation_repositories, repository, pull_request) to trigger scans and keep repository state current. Scan results are reported back to GitHub as check runs, so you can see findings directly in your pull requests. Connecting the Code app also adds your GitHub organization as a SaaS account and runs organization and repository posture checks against it. Code scans include static checks on GitHub Actions workflow files. Together with Monitor detections (including package publish and workflow configuration change), this is how Fencer covers the GitHub-reachable subset of the OWASP Software Provenance Verification Standard.

The Monitor app forwards every webhook event it receives for security event analysis and detection rule execution.

Usage / Configuration

Installing the GitHub Code App

1. Navigate to Admin > Integrations in your Fencer organization.
2. Under Available Integrations, click the GitHub (Code) card, then click Continue.
3. Click Connect GitHub. A popup opens to install the Fencer GitHub App.
4. On GitHub, select the organization and choose which repositories to grant access to — All repositories or a specific selection. This only grants access; you choose which repositories to scan in Fencer.
5. Click Install. The popup closes and Fencer opens the connection’s repository settings.
6. Click Add repositories, search for a repository, and click Add next to each one you want to scan. Fencer starts a scan as soon as a repository is added.

Installing without owner access

If you are not an owner of the GitHub organization, GitHub records an installation request for its owners instead of installing the app. Fencer asks you to authorize the app so it can match the request to your account, then shows Waiting on a GitHub organization owner. As soon as an owner approves the request on GitHub, Fencer finishes the setup and emails you.

Installing the GitHub Monitor App

1. Ensure you already have the GitHub Code app installed.
2. Navigate to Admin > Integrations and click the GitHub (Monitor) card, then click Continue.
3. Review the list under Repositories to select — these are the repositories the Code app scans.
4. Click Connect GitHub Monitor. A popup opens to install the Fencer GitHub Monitor App.
5. On GitHub, select the same organization the Code app is installed on, grant access to at least the listed repositories, and click Install.

Caution

If the Monitor app does not have access to every repository the Code app scans, events from the missing repositories never reach Fencer, leaving gaps in your security monitoring. To add repositories later, open the Monitor connection’s edit page and click Edit to change the installation on GitHub.

Managing Repositories

After installation, you manage which repositories Fencer scans from the connection’s edit page:

1. Go to Admin > Integrations, find your GitHub (Code) connection under Active Integrations, and click Edit.
2. Click Add repositories to search the repositories the app can access and add them. If a repository is not listed, click Configure repository access on GitHub to grant the app access to it.
3. Under Connected repositories, each repository can be marked in or out of scope, suspended or resumed, or removed with Remove repository.
4. Repositories you remove from the installation on GitHub, archive, or delete are removed from Fencer automatically. Repositories you add to the installation on GitHub only become available to add; Fencer does not start scanning them on its own.

Code Scanning on Push and Pull Requests

Code scans are triggered automatically when GitHub sends a check_suite event, which occurs on:

• Pushes to any branch within the repository’s Branch scope. Pushes to the default branch are scanned only while Scan on push is on.
• Pull request creation or updates.

Pull requests from forks wait for a maintainer to approve the scan in Fencer, unless Automatically scan fork pull requests is on for the repository. All three settings are on the repository’s Settings tab, under Scanning.

Fencer creates a GitHub check run for each scan. The check progresses through queued, in progress, and completed states. On completion, the check reports a success or failure conclusion — failure when the scan breaks one of the repository’s Checks settings — along with:

• A summary of vulnerability counts (new, existing, resolved)
• On pull request scans, inline annotations on the changed files where vulnerabilities were found

Note

You can turn findings off, or post them as comments instead of inline annotations, with Post findings on pull requests and Post findings as on the repository’s Settings tab, under Checks. If the comment cannot be posted, the check still gets the inline annotations.

Pull Request Fix Tracking

When Fencer creates automated fix pull requests for vulnerabilities, the integration tracks their lifecycle. When a fix PR is merged, the associated open vulnerability is automatically moved to Ready for verification status. If the PR is closed without merging, the fix PR is marked as Rejected.

Identity Sync

The GitHub Code integration syncs your GitHub organization members as identities in Fencer when you connect, and then daily, when your plan includes identity management. Installations on a personal GitHub account are not synced. This includes:

• Member usernames, display names, and public email addresses
• Role detection (admin vs. member)
• MFA (two-factor authentication) status
• Bot and app identity classification

Disconnecting

1. Go to Admin > Integrations and find your GitHub connection under Active Integrations.
2. Click Remove on the connection you want to remove, then confirm.
3. Fencer uninstalls the app from your GitHub organization and removes its repositories from scanning. Existing scan results are preserved.

GitHub App permissions

This section lists every permission each app requests, what it is used for, and why it is required. When you install an app, GitHub shows you this exact list and asks you to approve it.

Note

GitHub permissions are granted at three levels — Repository, Organization, and User — and each is either Read or Read & write. Metadata: Read is mandatory for every GitHub App; GitHub requires it so the app can resolve repository names and identifiers.

GitHub Code app permissions

The Code app powers repository discovery, code and secrets scanning, commit-status reporting, automated fix pull requests, and AI code reviews.

Repository permissions

Permission	Access	Why Fencer needs it
Metadata	Read	Mandatory for all GitHub Apps. Lets Fencer list the repositories the installation can access and resolve their names, default branches, and visibility.
Administration	Read	Read repository creation, deletion, settings, teams, and collaborators. Fencer uses this to understand each repository’s configuration and access model. Read-only — Fencer never changes repository settings, teams, or collaborators.
Contents (shown as “Code” on GitHub)	Read & write	Read: fetch source code, commits, and changed files so a scan can analyze them. Write: create a branch and commit a proposed change when opening a fix pull request.
Pull requests	Read & write	Read: list the files changed in a pull request to scope a scan. Write: open automated fix pull requests and post code-review summaries with inline comments.
Checks	Read & write	Create and update the GitHub Check Run that reports scan progress (queued → in progress → completed) and surfaces vulnerability findings as inline annotations on pull requests.
Issues	Read	Receive pull request comment activity — GitHub delivers pull request comments as issue_comment events, which require read access here. The AI code-review comment itself is posted through the Pull requests permission, so this stays read-only.

Organization permissions

Permission	Access	Why Fencer needs it
Members	Read	Sync your organization’s members into Fencer as identities — including usernames, display names, email addresses, admin vs. member roles, and two-factor (MFA) status.

User permissions

These are requested and authorized on an individual-user basis, separately from the installation — not at the organization level.

Permission	Access	Why Fencer needs it
Email addresses	Read	Identify the user who authorizes the app and associate their verified email with the Fencer account.

Subscribed events

The Code app subscribes only to the events it needs to keep repository state current and trigger scans:

Event	Purpose
installation	Track when the app is installed, suspended, unsuspended, deleted, or re-permissioned.
installation_repositories	Detect repositories being added to or removed from the installation.
repository	React to a repository being archived, renamed, transferred, deleted, or having its visibility changed.
check_suite	Trigger a scan when GitHub requests checks (on push and pull request events).
check_run	Re-run a scan when a check is re-requested.
pull_request	Track pull request open/close/merge to drive fix-PR lifecycle and verification state.
issue_comment	Receive AI code-review confirmations (only when AI reviews are enabled).
pull_request_review_thread	Track resolution of review threads (only when AI reviews are enabled).

GitHub Monitor app permissions

The Monitor app exists to feed Fencer’s SIEM. Its job is to receive the full stream of GitHub activity for your organization — member changes, repository changes, permission changes, and more — and forward those events to Fencer’s data pipeline, where detection rules evaluate them for suspicious activity.

Because the SIEM’s value comes from comprehensive coverage, the Monitor app requests read access across all GitHub permission categories. GitHub only delivers a given webhook event to an app that holds the corresponding read permission, so broad read access is what makes complete monitoring possible. The Monitor app never requests write access to your code, pull requests, checks, or any other content — the only write access it holds is to organization and repository webhooks, used to manage event delivery.

Read permissions

The Monitor app holds read-only access to the full set of GitHub resources below. They are all read-only: the app observes activity, it never modifies any of these resources. GitHub only delivers a webhook event to an app that holds the matching read permission, so the breadth of this list is what gives the SIEM complete coverage.

Dependabot alerts, actions, actions variables, administration, attestations API, checks, code, codespaces, codespaces lifecycle admin, codespaces metadata, commit statuses, custom organization roles, custom properties for repositories, custom repository roles, deployments, discussions, environments, issue types, issues, members, merge queues, metadata, models, organization API insights, organization actions variables, organization administration, organization announcement banners, organization campaigns, organization codespaces, organization Copilot seat management, organization custom properties for repositories, organization events, organization network configurations, organization personal access token requests, organization personal access tokens, organization plan, organization private registries, organization projects, organization self-hosted runners, organization user blocking, packages, pages, pull requests, repository advisories, repository projects, secret scanning alerts, and security events.

The categories that matter most for security monitoring:

Permission (Read)	What it lets the SIEM observe
Metadata	Repository names and identifiers (mandatory for all apps).
Administration	Repository creation, deletion, settings, teams, and collaborator changes.
Organization administration	Organization-level setting and configuration changes.
Members	Members added, removed, or having their roles changed.
Code	Push and content-change activity.
Pull requests	Pull request lifecycle activity.
Issues	Issue and comment activity.
Secret scanning alerts	Secrets detected in repositories.
Security events	Code-scanning findings and other repository security events.
Dependabot alerts	Vulnerable-dependency alerts.
Actions	CI/CD workflow runs and configuration changes.
Deployments / Environments	Deployment and environment changes.
Personal access tokens / PAT requests	Creation, approval, and use of org-scoped tokens.
Self-hosted runners	Registration and changes to organization runners.
Packages	Package publish and access activity.

Write permissions

Permission	Access	Why Fencer needs it
Organization webhooks	Read & write	Manage event delivery at the organization level. Requested up front so future event-routing changes do not require re-authorization.
Repository webhooks	Read & write	Manage event delivery at the repository level for the same reason.

User permissions

These are requested and authorized on an individual-user basis, separately from the installation. They are all read-only:

Copilot Chat, Copilot Editor Context, blocking, email addresses, followers, interaction limits, models, plan, starring, user events, and watching.

Subscribed events

The Monitor app subscribes to the broad set of organization and repository events that GitHub makes available. Every received event is forwarded to the SIEM pipeline; events for an installation that Fencer does not recognize are discarded. The two events handled specially are:

Event	Purpose
installation	Track installation, suspension, and removal of the Monitor app.
installation_repositories	Keep the Monitor app’s repository coverage in sync with the Code app.

All other received events are forwarded to the SIEM as security telemetry.

Why two apps instead of one

The Code app needs write access (to checks, pull requests, and contents) to do its job, but it only needs to see a narrow set of events. The Monitor app needs to see almost everything, but should never have write access to your code. Splitting these responsibilities means:

• Least privilege — neither app holds permissions it does not use. The Monitor app cannot modify your repositories; the Code app cannot read your full event stream.
• Transparency — at install time GitHub shows a focused, understandable permission list for each app rather than one broad request.
• Independent control — you can install, audit, or remove SIEM monitoring without affecting code scanning, and vice versa.

Reviewing and changing permissions

You can review the exact permissions either app currently holds at any time:

1. On GitHub, go to your organization’s Settings > GitHub Apps (under Third-party Access).
2. Select Fencer Code or Fencer Monitor.
3. Review the Permissions and Repository access sections.

If Fencer adds a feature that requires a new permission, GitHub will ask an organization owner to review and approve the change before the new access takes effect — existing access is never silently expanded.

Examples

Typical workflow with a pull request

1. A developer opens a pull request on a repository you added to Fencer.
2. GitHub sends a check_suite event to Fencer.
3. Fencer creates a check run in the queued state on the PR.
4. The code scan runs, analyzing the branch for vulnerabilities and secrets.
5. On completion, the check run updates to success or failure with a detailed summary and inline annotations on the changed files that have findings.
6. The developer reviews the findings directly in the GitHub PR interface.

SIEM event forwarding (Monitor app)

1. A GitHub organization event occurs (e.g., a member is added, a repository is created, permissions change).
2. GitHub sends the webhook event to the Monitor app endpoint.
3. Fencer forwards the event payload to Fencer’s data pipeline.
4. SIEM detection rules evaluate the event and may create detections for suspicious activity.

Troubleshooting

• Connection shows an Issue status: Fencer could not authenticate to the GitHub installation — for example, the app was uninstalled or suspended on GitHub, or its permissions were revoked. Check the installation under your GitHub organization’s Settings > GitHub Apps.
• Check runs not appearing on PRs: Verify that the repository is listed under Connected repositories on the connection’s edit page and is not suspended, that the branch is within the repository’s Branch scope, and that your plan includes pull request scanning. Pull requests from forks show Waiting for approval until a maintainer approves the scan in Fencer.
• Monitor events missing for some repositories: Grant the Monitor app access to every repository the Code app scans. Open the GitHub (Monitor) connection’s edit page and click Edit to change the installation on GitHub.
• Identity sync missing members: Identity sync needs the organization Members: Read permission, and only runs for installations on a GitHub organization (not a personal account). Verify the app permissions on GitHub.

Related pages

• Integrations Overview
• Code Scanning
• OWASP SPVS Coverage
• SaaS Scanning
• Secrets Detection
• Security Monitoring (SIEM)
• Identity Management