Skip to main content
SourceTrustSign in

Help center

Guides for SourceTrust: Importing dependencies, reviewing licenses, external obligations, publishing attestation pages, billing, plain-language license explainers, and procurement-oriented explainers for common open-source licenses.

GitHub importing

← All articles

Connect a GitHub repository so lockfile changes import automatically on every push. SourceTrust watches the chosen branches and applies the resolved inventory.

For reconnect, keep the same repository authority and Production and optional Testing selections. Retained extra watched branches are included automatically, preserving their inventory, reviews and comments. A different repository or changed Production or Testing selection is refused.

If a previously synced branch cannot be read, its inventory stays visible and a branch-specific Sync issue needs attention. Restore the branch or repository access and run Re-sync. Restoring the same commit also recovers a completed empty inventory without losing removal evidence. The warning clears only after all connected branches are healthy. If the branch was deliberately retired, change or remove Testing or the watched branch in project settings, or select an existing valid Production slot. Reconnecting with different branch roles is not supported.

Instead of uploading a file by hand, connect one GitHub repository per project. On a watched-branch push, SourceTrust imports the full exact external package set represented by every discovered lockfile, including transitive packages, and marks new or changed packages Needs review. Only a complete repository scan made entirely from complete inputs can flag an absent package Removed. Partial scans carry existing packages forward and show a warning instead. Removed packages stay available for review until you remove them from inventory or publish the reviewed change. There is no separate preview or apply step.

Setup

  1. Open the project → Settings → GitHub integration.
  2. Click Connect GitHub. You need SourceTrust admin permission in this organization. GitHub decides which App installations your signed-in GitHub account can see, and who may install GitHub Apps on a GitHub organization. If GitHub will not let you install SourceTrust, ask someone who can install GitHub Apps there to install it, or to grant you that GitHub permission, then Connect GitHub again. If the GitHub organization must approve App installs, ask someone who can approve them, then Connect GitHub again. SourceTrust does not require GitHub organization Owner. After the first link, other SourceTrust admins in this organization can reuse that installation. Several SourceTrust organizations can connect the same GitHub App installation and the same repositories. Each organization connects with its own GitHub sign-in, so one team per organization is a normal setup.
  3. Choose your Production branch (feeds the public attestation page). Optionally turn on Watch a testing branch for an internal review lane. Both sync on connect and on push. You can change or remove Testing later in project settings.
  4. On the first repository connection, any manually uploaded Production and Testing inventory is permanently deleted, including review decisions, pasted license text, obligation acknowledgements, vulnerability findings and acknowledgements, and package comments. Manual upload is disabled while connected. Disconnecting or a failed initial sync cannot restore the deleted upload work. Published attestation history remains unchanged.

Every push to a watched branch checks all discovered lockfiles, including changes outside the primary file, newly added lockfiles, and documentation-only pushes. SourceTrust still reads and checks the files when the inventory is unchanged, but creates no duplicate inventory change. New or changed packages need review, and the public page changes only when you publish the reviewed inventory.

Auto-discovered lockfiles

Supported files still import when other repository inputs are malformed, unreadable, too large, or binary bun.lockb files. Coverage stays partial and the warning names rejected files, with a summary when details are omitted. If every input is rejected, an established connection reports the cause and keeps the previous inventory. Fix or trim the named repository files, commit Bun’s text bun.lock instead of bun.lockb where needed, then run Re-sync. Disconnect first if you want to upload manually. An initial Connect with no usable dependencies stays unconnected; fix the files and Connect again or upload a supported file manually.

GitHub sync recursively scans the repository tree and combines every supported dependency file into one resolved inventory, up to 25 files per repository. Common generated and vendor folders are skipped. CycloneDX and SPDX SBOM files are not auto-discovered. A degraded tree listing can still add exact packages, but it shows Partial coverage and cannot infer removals. Common candidates include:

  • NuGet: packages.lock.json (all resolved entries, format v1 or v2).
  • Bun: bun.lock text versions 0, 1 and 2 (all external packages; version 3 and bun.lockb are unsupported).
  • npm: package-lock.json (lockfile v1, v2, or v3).
  • Cargo: Cargo.lock (versions 1 through 4).
  • uv: uv.lock
  • Poetry: poetry.lock (full resolved set).
  • pnpm: pnpm-lock.yaml (schema versions 5 through 9, including pnpm 11 multi-document files). Includes represented configuration and package-manager packages.
  • Yarn: yarn.lock (classic v1 or Berry v2+).
  • Go: go.mod (all exact require entries; Partial coverage).

For all 17 formats, resolved-set coverage, and relationship rules, see Help center → Manual importing (Manual importing).

Pull requests can receive informational dependency comments comparing base and head lockfiles. Inventory changes only happen on pushes to watched branches. Pushes with zero dependency changes are silent. See Help center → Production vs Testing branches (Production vs Testing branches).
A known problem with dependency files on an established public repository, such as an unsupported or oversized lockfile on Testing, does not remove free OSS qualification. The sync warning stays visible, and ordinary reviews still apply before publishing. Publishing changes and exporting do not use your lifetime Community allowance for that reason. If repository access is lost, visibility is private or unknown, or the cause cannot be confirmed as a file problem, free OSS output needs qualification again. Already published pages stay online.

If the connection breaks

For a package metadata-limit error, see Help center → Manual importing (Manual importing) for the supported scope and license-claim limits. Correct the input or contact support with the filename before running Re-sync; retrying unchanged metadata cannot resolve the failure.

A connection can stop working without anyone touching SourceTrust: the GitHub App gets uninstalled or suspended, the repository is removed from the App's access, or a sync starts failing (for example an unsupported or oversized lockfile). You will not discover this by accident. The Projects overview shows a Needs your attention banner and a Sync issue badge on the affected project, the project's Settings GitHub card switches to Connection lost with the cause, and your organization's notification recipients get an email (at most one per connection per day).

  • Reconnect from project settings only with the same GitHub installation, repository, and branches. A GitHub App reinstall creates a new installation, so connect it to a new project. Your existing inventory and finished reviews remain on the original project.
  • If Connect finds no supported lockfile or finds one that is too large, SourceTrust creates no project connection. Choose a different repository in the same Connect flow, upload the file manually, or fix the repository and run Connect again.
  • A project stays with the repository it first synced. To use a different repository or provider, create a new project. This protects finished reviews and comments.
  • Deleting one project does not disconnect a GitHub installation that another project in the organization still uses. Organization settings → Integrations keeps the GitHub organizations entry and disconnect control. Disconnecting there only unlinks SourceTrust; the App stays installed on GitHub until you uninstall it there. Disconnecting or deleting in one SourceTrust organization never affects another organization that connected the same installation. That organization keeps its connections and keeps syncing. Reconnect from a project → Settings → Connect GitHub authorizes once and reuses that install (no need to reinstall). SourceTrust uninstalls the App during project or organization deletion only when no other SourceTrust organization is still linked to that installation and no other project in this organization needs it. You can also uninstall the App directly on GitHub. That Integrations page only lists GitHub App installs (shared across projects). GitLab and Azure DevOps stay on each project's settings.
  • Disconnecting a repository yourself is silent: no banner, no email. Only connections GitHub cut or broke raise alerts.
  • If the disconnect was deliberate, you can dismiss a lost connection from the project's GitHub settings card to stop the reminders without reconnecting.
  • As a safety net, SourceTrust re-checks every watched branch about twice a day, so a lost push notification from GitHub cannot leave a branch silently stale.
  • An unsupported dependency-file version stops the whole sync and keeps your previous inventory visible. Bun text versions 0, 1 and 2 are supported; version 3 is not. For an established connection, fix the file and push the change, wait for the next scheduled check, or run Re-sync. The warning clears when the latest scan for every connected branch succeeds. If the first connection failed, fix the file and run Connect again.
  • If a received push overlaps inventory verification or a review change, SourceTrust retries automatically after a delay. Your previous inventory stays visible while it retries. If all attempts fail, the project shows a Sync issue. Run Re-sync from project settings after the competing changes settle. A delayed result from an older import does not hide the failure.
  • A Sync issue badge stays until the latest scan succeeds for every connected branch. A valid push, a scheduled check or Re-sync can clear an unsupported-version error.