How Seal discovers your packages
The four package discovery modes Seal supports, and the trade-offs each one makes.
Before Seal can remediate a vulnerable package, it has to know the package is in your environment. The mechanism is package discovery: a per-Seal-Project setting that controls how the Seal Platform learns about the packages in your codebase. Seal supports four package discovery modes, and a Seal Project uses exactly one at a time.
The mode determines how complete the platform's picture is and how much of your environment Seal needs access to. If your organization restricts source-code access to third-party tooling, the three no-source modes still give you full remediation. Only the discovery side changes.
The four modes
Source code
A connected SCM integration reads your dependency manifests directly.
Read access to the repository.
CLI
The Seal CLI runs in your CI/CD pipeline and reports the manifest it scanned.
The Seal CLI integrated into your build.
Artifact server
The Seal Artifact Server records each sealed package your build pulls.
Your package manager configured to use the Seal Artifact Server.
Imported manifest
A one-shot upload of a manifest, lockfile, or SBOM.
The file.
The full reference for each mode is in Package discovery mode.
Trade-offs
The four modes are not equivalent. They differ on three axes that matter day to day.
Completeness. Source code mode sees the manifest as Seal's integration parses it. Artifact server mode only sees what your build actually pulls, which can miss declared-but-unused dependencies. CLI mode sits between the two, reporting what the CLI's scan reads on each run. Imported manifest mode is whatever was in the file you uploaded, nothing more.
Freshness. Source code mode tracks the latest commit. CLI mode updates each pipeline run. Artifact server mode accumulates over time as pulls happen, so the picture builds up but never reflects the very latest commit. Imported manifest mode does not refresh at all; the snapshot ages from the moment it is uploaded.
Source access. Source code mode requires read access to the repository. The other three modes do not. CLI mode in particular is the strongest fit when your organization restricts third-party access to source: Seal still gets a complete picture, because the CLI does the manifest reading inside your pipeline and reports back only what is needed.
Picking a mode
A Seal Project's mode is set when the project is created. After creation, it can move toward more reliable signal sources (toward source code) but not back. The mechanics are covered under Mode changes in Creating a Seal Project.
A starting point for the choice:
If Seal has SCM integration with your organization and the repository is in scope, source code mode is the most accurate.
If you want full remediation without granting source access, CLI mode is the strongest no-source option.
Use artifact server mode when the Seal CLI cannot run in the build (for example, when a vendor or another team owns the pipeline) but the build can be pointed at a configured remote.
Use imported manifest mode for one-shot evaluation: an SBOM you received, a Snyk export, a snapshot from a vendor.
The per-mode "when to choose this" detail and the connector how-tos live under Package discovery mode.
Related
Package discovery mode: the reference for the four modes.
Creating a Seal Project: where a project's mode is set, and the rules for changing it later.
Last updated