Skip to content
Pilot Docs

Code Security (GitHub / GitLab)

The Code Security page in the sidebar is how Pilot reaches into your private repositories to scan for leaked credentials. Public-repo leaks already get picked up by GitHub’s own secret scanning; Pilot’s value here is private repos, historic commits, and SaaS keys that the default scanners miss.

What it does

For each connected GitHub or GitLab organisation, Pilot:

  1. Lists the org’s repositories (you choose which to scan).
  2. Walks the full commit history of each scanned repo — secrets in deleted files, removed lines, and historic branches all count.
  3. Matches every file/blob against Pilot’s secret pattern catalogue (AWS keys, Slack tokens, Stripe live keys, DSNs, JWTs, vendor API keys — see Findings & secrets for the catalogue scope).
  4. Runs the same automated triage as crawl-derived secrets — probable_fp, public_by_design, or real_secret.
  5. Surfaces matches in Vulnerabilities → Secrets with a repo source badge so you can filter by where the secret lives.

Setup

Code Security needs scoped access to the repos you want scanned. Pilot supports two flows:

A first-party GitHub App that you install on the org with Contents: read scope on the repos you choose. No admin tokens, no broad permissions. Re-scopable at any time from GitHub’s app management page.

  1. Code Security → Add connection → GitHub.
  2. Click Install on GitHub. Pick the org. Pick which repos.
  3. Confirm. Pilot returns to the Code Security page and starts discovering the connected repos.
  4. Select repos to scan + click Scan now, or let the default scheduled scan pick them up.

GitLab personal access token

For GitLab orgs (where the app flow isn’t currently supported), use a PAT with read_repository scope.

  1. In GitLab: create a PAT with read_repository only. Note the value; you’ll paste it once.
  2. Code Security → Add connection → GitLab.
  3. Paste the PAT + your GitLab URL (gitlab.com or self-hosted).
  4. Pilot lists the projects the token can see. Select which to scan.

Tokens are encrypted at rest with the customer-scoped KMS key.

Scope per company

Each connection is bound to one company at setup. Findings, attack paths, and graph views stay scoped to that company. If you have multiple companies tracking different orgs / different GitHub installs, add one connection per (company, org) pair.

What appears where

  • Code Security page lists the connections and per-repo scan status.
  • Vulnerabilities → Secrets shows individual matches with a repo badge.
  • Attack Graph renders connected repos as repo nodes; secrets found there as secret nodes with a LEAKS edge between them.
  • Attack paths → REPO_TO_CLOUD chains a leaked cred all the way through to the cloud account it unlocks (and the speculative buckets that cloud account holds data in).

Costs & limits

  • Initial scans of a 1000-commit repo take ~30 seconds.
  • Re-scans (incremental, only new commits since last pass) take a fraction of that.
  • Pilot caches every commit’s scan result so you don’t re-scan the same SHA twice.
  • Rate-limit-aware on both GitHub and GitLab — slows down to stay under your API quota.

Removing a connection

From the Code Security page, click the connection’s gear → Remove. This:

  • Revokes Pilot’s access at the provider (GitHub installation uninstall, GitLab token forgotten).
  • Removes the secrets found by that connection from your customer data.
  • Removes the repo nodes from the attack graph for the affected company.

The connection cannot be partially scoped — adjust the underlying GitHub installation’s repo set instead.