Seal Apps via the Seal CLI in CI/CD

Setting up the Seal CLI in your CI/CD pipeline so it can scan your manifest and apply Sealing Rules.

Running the Seal CLI in your CI/CD pipeline is the most complete way to use Seal Apps. The CLI scans your dependency manifest, applies the active Sealing Rules (or replaces every vulnerable package, in all mode), and produces the build that ships sealed packages instead of vulnerable ones. The same CLI run also feeds Seal's discovery side, so the Seal Project's package picture stays current.

This chapter is the canonical setup home for the three CLI-in-CI deployment methods (Remote, Local, and Automatic Remediation, see Choosing your deployment method). The chapter is structured as:

• Installing the Seal CLI: downloading and unpacking the binary on Linux, macOS, or Windows.

• The CLI fix mode: the three modes the CLI runs in (local, remote, all) and which one each deployment method uses.

• Per-platform CI integrations:

  • Integrating with GitHub Actions: the dedicated seal-community/cli-action.

  • Integrating with GitLab CI

  • Integrating with Azure DevOps Pipelines

  • Integrating with Jenkins

  • Integrating with CircleCI

• Running the CLI inside a Dockerfile: for builds that drop into a container, with or without a CI system around them.

• Setting up local development: running the CLI on a developer's machine with a development token.

• Common issues: the failures that come up most often.

Before you start

• The Seal CLI must run somewhere with network access to the Seal Platform and the Seal Artifact Server.

• You need a token for authentication. Production tokens for production-equivalent CI; development tokens for developer machines and feature-branch pipelines.

• You need a Seal Project for the CLI to attribute its activity to. The first run with a SEAL_PROJECT value that does not exist creates the project automatically; see Project ID and project name.

What the CLI does in CI

A typical CI invocation runs seal fix. The flow:

1. The CLI authenticates with the token from SEAL_TOKEN.

2. It scans the dependency manifest in the working directory and reports the discovered packages to the Seal Platform under the supplied SEAL_PROJECT.

3. Depending on the fix mode, the CLI fetches the relevant Sealing Rules (remote) or reads them from .seal-actions.yml (local), or skips the rule lookup and replaces every vulnerable package it can (all).

4. For each rule that applies, the CLI pulls the sealed version from the Seal Artifact Server and replaces the installed vulnerable version on disk.

5. Subsequent build steps run against the sealed packages in place of the originals.

When in the pipeline the CLI runs

The CLI replaces packages on disk that the dependency-install step has already put there. The right place in your pipeline is therefore after the install step (npm install, npm ci, mvn install, pip install, composer install, and so on) and before any step that packages, bundles, or compiles those dependencies together (webpack, JAR packaging, docker build, and so on).

If the CLI runs before the install step, there are no installed packages to replace and the step is a no-op. If the CLI runs after the packaging step, the packaged output is already built from the vulnerable versions.

Related

• Choosing your deployment method: the decision page for the five deployment methods.

• Connecting via the Seal CLI in CI: the discovery-side how-to that pre-dates this chapter.

• Sealing Rules: the rules the CLI applies in remote and local modes.