Import and review capacity differs from publication and export capacity. Output size depends on package details and license text, not a fixed package count. The project shows a capacity estimate before publishing. It is provisional while licenses or reviews are unresolved, and finishing review can change it. A large inventory remains available for review even when its complete output cannot fit.
Click Import on a project and upload a lockfile or SBOM. SourceTrust auto-detects the format and imports every exact external package the file represents, including transitive packages in resolved lockfiles. For automatic imports on every push, connect a repository instead (GitHub, GitLab, or Azure DevOps).
JavaScript and Node
- npm (package-lock.json): Lockfile versions 1, 2, and 3. Imports every exact external package, including transitive, development, and optional packages.
- pnpm (pnpm-lock.yaml): Supported schema versions 5 through 9, including pnpm 11 multi-document files. Imports every exact external package or snapshot, including represented configuration and package-manager packages. Legacy peer variants stay distinct. A fully represented Git or URL dependency retains Direct context without itself making coverage partial. Local workspace links are skipped. A patched entry is imported at the version it was patched from and produces a partial-coverage warning, because the public artifact does not stand for the patched bytes.
- Yarn (yarn.lock): Classic v1 and Berry v2+. Imports every exact external resolved entry. Classic does not always prove which package pulls in another, so some packages stay at the top level of the list; local links and patched entries are skipped.
- Bun (bun.lock): Bun's text lockfile versions 0, 1 and 2. Imports every exact external package. Other versions, including version 3, stop the import and keep your previous inventory. Binary bun.lockb is not supported; export or upload bun.lock instead.
Python
- uv (uv.lock): Imports every resolved non-local package, including represented optional and development groups. Package names are normalized using PEP 503.
- Poetry (poetry.lock): Imports every resolved non-local package. Which ones are direct lives in pyproject.toml and not in the lockfile, so these packages stay at the top level of the list with no relationship label.
Rust, Go, and .NET
- Cargo (Cargo.lock): Lockfile versions 1 through 4. Imports every registry or Git package and skips local workspace/path packages.
- Go (go.mod): Imports every exact external require entry, including lines marked // indirect. Coverage is Partial because go.mod is a manifest, not the complete resolved graph.
- NuGet (packages.lock.json): Format version 1 or 2. Imports Direct, Transitive, and CentralTransitive libraries across target frameworks. Repository sync finds the file next to nested .csproj files.
Java, PHP, and Ruby
- Gradle (gradle.lockfile): Imports every pinned group:artifact:version coordinate.
- Maven (pom.xml): Imports direct external dependencies with literal versions. Coverage is Partial because a POM does not contain the resolved transitive graph.
- Composer (composer.lock): Imports every package in packages and packages-dev.
- Bundler (Gemfile.lock): Imports every external resolved GEM or Git specification. DEPENDENCIES identifies direct gems.
Dart, Flutter, and Swift
- Dart / Flutter (pubspec.lock): Imports every hosted or Git package, including direct development and transitive entries. Local path and SDK packages are skipped.
- Swift (Package.resolved): Imports every external registry or remote-source pin. The file does not say which package pulls in another, so these packages stay at the top level of the list with no relationship label; local path pins are skipped.
SBOM (any ecosystem)
- CycloneDX JSON (bom.json or any *.cdx.json): Spec versions 1.4 through 1.7. Imports every external component and uses the dependency graph to label relationships when possible. License expressions and PURLs are read as claims. Coverage is Partial, and repository sync does not auto-discover the file.
- SPDX JSON (spdx.json or any *.spdx.json): SPDX 2.0 through 2.3 JSON. Imports every external package and uses supported relationships to label it when possible. License fields and PURLs are read as claims. Coverage is Partial, and repository sync does not auto-discover the file.
Resolved inventory and coverage
Resolved lockfiles import their full exact external package set, including dependencies several levels below the manifest. Use Direct or Needs attention to focus your review. Transitive lists every package your direct packages bring in, each one once, and under All you can expand a direct package to see what it brings in. Partial inputs such as go.mod, pom.xml, or an SBOM still add exact packages, but SourceTrust shows a warning because those inputs cannot prove that omitted packages were removed.
Licenses and the preview step
License fields in an imported file are hints. SourceTrust also uses real license expressions from package prefills and verifies the exact artifact after import. A license URL or an empty declaration does not supply a license claim. Before you confirm, the preview counts new, updated, and unchanged packages and shows relationship totals, coverage, and parser warnings. For a large lockfile the list of changed packages is shortened, with a line saying how many more changes are included but not listed. The counts always cover the whole file, and confirming imports every package the file represents. Manual re-import always adds or updates exact packages, even for a complete lockfile. A separate count lists present packages absent from this file but retained in inventory, including old versions. Details show at most 200 retained packages and say how many are shown out of the full count. Retained packages can remain in a later publication when eligible. Review them in the inventory and explicitly remove any you no longer need using the existing removal controls. The preview describes the inventory when it was read; later edits can change it before confirmation.
Import limits
Each exact package can include up to 8 KiB (8,192 UTF-8 bytes) of usage-scope metadata, measured as the JSON array after trimming, removing duplicates, and sorting. Each configuration or framework name must be nonempty and at most 100 characters. Up to 20 license claims are supported per exact package. All scopes within these limits are preserved, including Android build configurations. These metadata limits are separate from the 5,000 exact-package limit and the 20,000 raw occurrences plus warnings limit. Repository imports also allow up to 25 files and 32 MiB combined input.
If a package exceeds a metadata limit, use corrected input in a supported format or contact support with the filename. Repeatedly importing the unchanged file or running Re-sync cannot fix that error. Do not remove dependencies to make the inventory fit; support can help assess the input while your previous inventory stays available.
After you confirm
After you confirm, the dialog closes once your import has been accepted. One notice above the packages list then follows the whole import and tells you whether to wait or to act. While the packages are being saved it counts them, and you can keep using the project. If saving does not finish, the same notice says so, nothing was changed, and Retry starts it again without uploading the file.
We check the direct packages first and finish them before the rest starts, and the notice counts how many of how many are checked with roughly how long is left. You can keep browsing and reviewing while it runs, and closing the tab does not stop it: if a run is interrupted, SourceTrust takes it up again on its own and finishes the remaining packages. A package that does not answer on the first attempt is simply tried again inside the same run, so you are never handed a half-finished result with an invitation to start working. When it is your turn, the same notice counts the packages by kind: how many are ready for your approval, how many need a decision, how many need license text from you, how many we could not check, and how many were removed from your project. The kinds add up to the number in the heading, and each one takes you to exactly those rows in the packages list below. There is always a button to start, and it opens the first package that needs you.
When a check ends in an error, the affected inventory rows are marked License check failed. A package that hit a busy moment is tried again while the run is still going, and the row says the check is still running rather than showing an answer it is about to replace. There is no waiting state to sit and watch any more. When the run ends, the notice says how many packages we could not check, as a number, and that number has its own filter so you can open those rows. Open one to try again or to add the license yourself. Open such a package and paste license text from your installed copy or its source. Saving your text stops automatic rechecks, and an in-flight check cannot overwrite it. Use Check again in the package dialog when offered. It answers within a minute, with the license text or with a plain message that we could not get it. Checking one package that way updates only that package, and the project's progress stays where it is. Git, path, and URL installs and already confirmed licenses are not fetched again. The packages stay in your inventory throughout.
When the checks have finished and something can be bulk approved, the notice offers Bulk approve, and you can press it whenever you want to approve the licenses you choose in one press. The first time, the notice states how many can be bulk approved, how many your team has already handled, how many are for you to review, and how many we could not check, and it names the licenses inside the offer. The button opens the list rather than approving straight away: the first time you open it on a project you meet a short explanation of how Bulk approve works, then the licenses of this import with their counts, and the run starts from the button inside that dialog. Closing the dialog approves nothing. You can run it again later, for example with one more license ticked, and it never changes a project setting. Turn on Bulk approve after every import under Review automation in the project settings, and a later import or push runs it by itself with the list you saved there. Every run tells you what it did, also when it approved nothing. The notice keeps one dated sentence about it, for example: 240 packages were bulk approved on 3 June at 14:05. That sentence holds no second number, so it can never disagree with the count in the heading, and the heading always shows what is left right now. Open the remaining packages to add information or approve them. The sentence stays visible after review finishes. Failed checks and packages that need a decision always stay for your review.
A repository-connected project reads the same way. When a push, a pull request or our regular check reads your repository, the project page shows the same import steps a manual upload shows, and the same approval report at the end. If we cannot read the repository, the page says so and offers Retry.