Connecting via the Seal CLI in CI

Run the Seal CLI in your CI/CD pipeline so it discovers your packages without source-control access.

When you cannot grant Seal read access to your source code, but the Seal CLI can run inside your CI/CD pipeline, the CLI itself becomes Seal's window into your packages. The Seal Project enters CLI discovery mode the first time the CLI runs against it.

This chapter is the minimum setup to wire CLI-driven discovery in. The deeper, per-platform CI integration mechanics (GitHub Actions, GitLab CI, Azure DevOps Pipelines, Jenkins, CircleCI, and others) live in Seal Apps via the Seal CLI in CI/CD.

Before you start

• A production token, stored in your CI's secret manager.

• A Project ID for the Seal Project. If a project with that Project ID does not exist in your tenant, it is created automatically the first time the CLI runs.

• A CI environment that can install the Seal CLI and reach Seal's servers over HTTPS.

Project ID, not project name. A Seal Project has two distinct identifiers: a human-readable name (mutable, allows spaces, used in the UI) and a machine-readable Project ID (immutable, limited to letters, numbers, dots, hyphens, and underscores, used in the API and the CLI). The two are independent. The CLI works against the Project ID; the display name has no effect on a CLI run.

Steps

1. Install the Seal CLI in your CI runner. The cross-platform install steps are in Installing the Seal CLI.

2. Configure environment variables for the pipeline step that runs the CLI:

   • SEAL_TOKEN: the production token, pulled from your CI's secret store.

   • SEAL_PROJECT: the Seal Project's Project ID.

3. Run seal scan in the working directory of the project you want to scan:

   seal scan

   The first run creates the Seal Project (if needed) with the supplied Project ID, and populates it with discovered packages. Subsequent runs with the same SEAL_PROJECT value attach to the same project and produce fresh signal.

Verify

• On the Projects page, your Seal Project appears with CLI as its package discovery mode.

• On the Protection page's Vulnerable packages tab, the packages from your manifest appear as Seal scans them.

Troubleshooting

The CLI fails with an authentication error. Confirm SEAL_TOKEN is set in the pipeline step's environment, that the token has not been revoked, and that you are using a production token. Activity authenticated with a development token is filtered out of the Protection page by default, so the scan can succeed but the results may not appear where you expect.

The Seal Project does not appear on the Projects page. Either the CLI did not finish (check the pipeline log) or the run authenticated against a different tenant than you are looking at.

The CLI rejects the value of SEAL_PROJECT. Project IDs are restricted to letters, numbers, dots, hyphens, and underscores (no spaces or other punctuation), and capped at 255 characters. Pick a value that fits the rules.

Two pipelines are clobbering each other's results. Both pipelines are running with the same SEAL_PROJECT value, so they are writing into the same Seal Project. Give each pipeline its own Project ID. See Anti-patterns in Creating a Seal Project.

Related

• CLI mode: the discovery mode this chapter sets up.

• Managing tokens: production vs development tokens, and what each one is tracked against.

• Seal Apps via the Seal CLI in CI/CD: the per-platform CI integrations and the broader fix-mode story.