Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

CLI Integration

Streamline your remediation workflow with a CLI-driven deployment in your CI/CD

This guide focuses on deploying Seal Security using the Seal CLI. This is the primary method for integrating Seal Apps and Seal OS protection into your CI/CD pipelines.

When integrated, the Seal CLI intercepts your build process, identifies vulnerable packages, and replaces them with sealed versions.

1. Select Your Remediation Mode

The Seal CLI operates in one of three modes. This setting establishes the "Source of Truth" for remediation rules, determining exactly which packages the CLI is authorized to seal.

Option A: Local Mode (Developer Controlled)

The rules for sealing packages are defined in a .seal-actions.yml file located within your project's root directory.

  • Pros: Fully tracked by source control (Git). Every change requires a Pull Request, keeping developers in full control of the remediation process.

  • Cons: Decentralized. Security teams cannot force a fix without engineering involvement.

seal fix --mode=local

Option B: Remote Mode (Centralized Control)

Rules are defined and stored on the Seal Server via the Seal UI.

  • Pros: No code changes or PRs required. Security organizations (Sealer or Admin permissions) can apply rules to multiple repositories instantly. Ideal for scaling remediation without engineering bottlenecks.

  • Cons: Changes are not tracked in the project's source control. The Seal Platform becomes the source of truth.

seal fix --mode=remote

Option C: All Mode (Automated)

The CLI automatically replaces any vulnerable package it encounters with a sealed version.

  • Pros: "Set and forget." Zero configuration and no PRs required.

  • Cons: Least amount of granular control. Every package fixed counts towards your quota. Low visibility into specific changes until they happen.

Note: For a deeper dive into rule logic, please refer to the Remediation Logic & Rules section of the documentation.

2. Handling Vulnerability Scanners

Using sealed packages can sometimes confuse vulnerability scanners, as they may look at the package version number and assume it is still vulnerable.

Choose the strategy that fits your auditing requirements:

Strategy 1: API Integration (Recommended for Internal Scanners)

Seal supports direct API integrations with a variety of major scanners (Snyk, BlackDuck, GitHub Advanced Security, Ox Security, etc.).

  • How it works: The Seal CLI communicates with your scanner's API to synchronize findings, marking specific vulnerabilities as "remediated" within the scanner's dashboard.

  • Best for: Internal scans and operational dashboards.

Strategy 2: Package Renaming (Recommended for External/Audit Scanners)

The CLI renames the package artifact during installation (e.g., pcre becomes seal-pcre).

  • How it works: Since the remediated version is effectively a fork, renaming it makes the change explicit. Scanners simply won't find the vulnerable package name in the manifest or binary.

  • Best for: External audits, customer-run scans, and scanners not supported by API integration.

Strategy 3: Manual Ignore

Manually marking alerts as "False Positive" or "Ignored" in your scanner's UI.

  • Best for: Small teams or one-off exceptions.

3. CI Integration Workflow

Regardless of the CI system, the golden rule of Seal CLI integration is Timing.

Timing Rule: The Seal CLI must run immediately after packages are fetched/installed, but before the project is compiled or built.

Common Integration Patterns

  1. Standard CI (Jenkins, GitLab CI, CircleCI): Add a shell step to download the CLI and run the seal fix command after your dependency fetch step (e.g., after npm install or go mod download).

  2. GitHub Actions: Seal Security provides a dedicated GitHub Action. Simply add it to your workflow file .github/workflows/main.yml.

  3. Docker: Add the CLI run command directly into your Dockerfile (often strictly for the build stage to keep the final image slim).

4. Ecosystems and Command Usage

The seal fix command is context-aware but requires specific sub-commands depending on what you are fixing. Complex pipelines may require multiple calls to the CLI.

Supported Ecosystems

  • Programming Languages: Javascript, Python, Java (Maven/Gradle), Go, etc.

  • Linux Packages (Seal OS): RPM, APK, APT (Red Hat, Debian, Alpine, etc.).

  • Post-Build Artifacts: Existing JAR and Wheel files (includes extraction, replacement, and repackaging).

Multi-Context Example

If you have a pipeline that builds a Node.js app, runs on Linux, and includes a legacy JAR file, you will execute three commands in sequence:

  1. Fix the Code: Run seal fix immediately after npm install.

  2. Fix the OS: Run seal fix os to patch C/C++ libraries and OS-level packages.

  3. Fix Artifacts: Run seal fix fs --path ./libs/legacy-app.jar to patch the compiled file.

5. Quick Start Commands

Copy the command relevant to your deployment strategy below.

Scenario A: Local Mode (Developer Managed)

Using .seal-actions.yml config.

Scenario B: Remote Mode (Security Team Managed) with Renaming

Using Seal Platform rules and renaming packages to satisfy external scanners.

Scenario C: "All" Mode with Snyk Integration

Fix everything automatically and sync results to Snyk.

Scenario D: The "Kitchen Sink" (Java Project + OS + Post-build)

A complex pipeline running in Remote mode.

Last updated