Connecting GitHub

Install the Seal GitHub App and import GitHub repositories as Seal Projects.

Connecting GitHub installs the Seal GitHub App on your organization, gives the Seal Platform read access to the repositories you choose, and makes the GitHub-only automatic pull request feature available. It is the most complete of the three source-control integrations Seal supports.

Before you start

• You have the Admin or Sealer role in Seal.

• You can install GitHub Apps on the GitHub organization (typically an org owner, or a user with the appropriate org-level permission).

• You have decided whether to grant the app access to all repositories in the organization or to a specific list. You can change this later from GitHub.

Steps

1. Open the Projects page in the Seal UI.

2. Click Import projects and select GitHub from the dropdown. The Select projects to import from GitHub modal opens.

3. If the Seal GitHub App is already installed on the organization you want to import from, the modal lists its repositories directly. Skip to step 6.

4. If the Seal GitHub App is not yet installed on the organization, click the install link in the modal. You are redirected to GitHub.

5. On GitHub, choose the organization, pick All repositories or Only select repositories (and pick the list), and authorize the install. GitHub returns you to Seal, and the modal now lists the organizations the Seal GitHub App can see.

6. Select the repositories you want to import as Seal Projects, then confirm.

Selecting GitHub repositories to import as Seal Projects

Verify

Each imported repository becomes a Seal Project in source code mode. The first scan starts in the background; results appear on the Protection page's Vulnerable packages tab as the scan completes.

If you do not see your Seal Projects on the Projects page within a minute of import, refresh the page.

Automatic pull requests

The Seal GitHub App can open pull requests against your repositories that propose Sealing Rules for the vulnerable packages Seal has discovered. The PRs do not modify your dependency manifests directly. Instead, they write the proposed Sealing Rules into a .seal-actions.yml file at the repository root, where they become local Sealing Rules scoped to that repository.

When automatic PRs make sense

Automatic PRs are useful only when the Seal Project's deployment method is Local, which runs the Seal CLI in CI in local fix mode and reads its rules from .seal-actions.yml. Other deployment methods either ignore that file (Remote and Automatic Remediation, which take rules from elsewhere) or do not run the CLI at all (Artifact Server, Manual), so a merged automatic PR has no effect.

After you review and merge an automatic PR, the Seal CLI still has to run in CI on the merged commit to actually replace the vulnerable packages with sealed versions. Automatic PRs are an authoring path for local Sealing Rules, not a no-CLI deployment channel.

Configuring automatic PRs

Automatic PRs are configured at Settings > Preferences > PR Setting. Configuring this setting requires the Admin role.

Settings:

• Trigger: On demand or After every scan.

• Update .snyk file: if your CI/CD also runs Snyk and the repository contains a .snyk policy file, the automatic PR also updates that file to mark the vulnerabilities Seal remediated as resolved.

• Update .grype.yaml file: the same for Grype, against a .grype.yaml policy file in the repository.

What the Seal GitHub App can see

The Seal GitHub App needs read access to your repository contents to read dependency manifests for discovery. If you want to use automatic pull requests, the App also needs write access to pull requests; otherwise read access is sufficient. The exact scopes are presented by GitHub during the install flow.

Related

• Source code mode: what Seal sees once GitHub is connected, and how source code mode handles remediation.

• Managing source control connections: viewing the installation later, or disconnecting.

• The onboarding wizard: the wizard's source-control step uses this same flow.