Configuring the Seal Artifact Server for discovery
Configure your package manager to pull through the Seal Artifact Server so Seal sees what your build uses.
When the Seal CLI cannot run in your build, but your package manager can be pointed at a remote, the Seal Artifact Server is the discovery path. Each authenticated pull is recorded against the Seal Project named in the credentials, and the project enters artifact server discovery mode the first time a sealed package is pulled for it.
This chapter is the minimum you need to know about how authentication carries the Project ID into a pull. The full per-ecosystem package-manager setup (npm, pip, Maven, Gradle, Go modules, Composer, Bundler, NuGet) lives in Seal Apps via the Seal Artifact Server.
Before you start
A production token. Per token security best practices, store it in a secret manager rather than in the package manager configuration on disk.
The Project ID of the Seal Project you want pulls attributed to. If the project does not exist yet, pre-create it from the New project button on the Projects page.
A package manager that can be pointed at a configurable remote (npm, pip, Maven, Gradle, Go modules, Composer, Bundler, NuGet).
How the Seal Artifact Server attributes a pull
The Seal Artifact Server has a single tenant-wide URL per ecosystem (for example, one URL for npm, one for pip, one for Maven). The URL is the same for every Seal Project in your tenant. The project context comes from HTTP Basic authentication on each pull:
Username: the Seal Project's Project ID.
Password: the production token.
A single token works across every Seal Project in the tenant; the Project ID in the username determines which project a given pull is attributed to. Different projects pull through the same URL with different usernames.
If the username is empty, the pull is attributed to the Default project instead of a specific Seal Project.
Steps
Generate (or reuse) a production token. See Generating and revoking tokens.
Decide which Seal Project will own the pulls. Reuse an existing project's Project ID, or pre-create a project from the New project button.
Configure your package manager to use the Seal Artifact Server, with the Project ID in the username field and the production token in the password field. The exact configuration syntax for each ecosystem is in Seal Apps via the Seal Artifact Server.
Run a build that pulls a sealed package. This is the trigger that switches the Seal Project to artifact server discovery mode.
Verify
On the Projects page, the Seal Project shows Artifact server as its package discovery mode.
On the Protection page's Vulnerable packages tab, the sealed packages your build pulled appear in the project's stream.
Coverage caveats
Artifact server discovery has more visibility caveats than the other modes (the picture depends on whether the Seal Artifact Server is your primary or fallback remote, on how aggressively your CI runners and any internal artifact-server caches cache pulls, and on whether your build still pulls origin versions from public registries). The full discussion is in Artifact server mode.
Troubleshooting
Pulls are landing in the Default project. The username in your package manager config is empty or wrong. Set it to the Project ID of the Seal Project you want to use.
The project shows up in CLI mode rather than artifact server mode. A Seal Project enters CLI mode if the Seal CLI runs against it, regardless of any artifact-server traffic. If the CLI runs for any reason against the same Project ID, the discovery mode upgrades to CLI and subsequent artifact-server signal is dropped. See Mode changes.
Related
Artifact server mode: what artifact server discovery actually sees, and the configurations that affect coverage.
Seal Apps via the Seal Artifact Server: the per-ecosystem package-manager setup.
Project ID and project name: the Project ID that goes in the username field.
Last updated