# CLI Integration 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[^1] 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. ```bash 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. ```bash 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. ```bash seal fix --mode=all ``` > **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. ```bash SNYK_URL SNYK_TOKEN SNYK_ORG_ID SNYK_PROJECT_ID seal fix --mode=XXX ``` #### 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. ```bash seal fix --mode=XXX --use-sealed-names=TRUE ``` #### 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.* ``` # Standard dependency fix seal fix --mode local # If fixing OS packages seal fix os --mode local ``` **Scenario B: Remote Mode (Security Team Managed) with Renaming** *Using Seal Platform rules and renaming packages to satisfy external scanners.* ``` # Standard dependency fix seal fix --mode remote --scanner-strategy rename # If fixing OS packages seal fix os --mode remote --scanner-strategy rename ``` **Scenario C: "All" Mode with Snyk Integration** *Fix everything automatically and sync results to Snyk.* ``` # You must provide the Snyk token for API integration export SNYK_TOKEN=your_token_here seal fix --mode all --scanner-strategy integration --scanner snyk ``` **Scenario D: The "Kitchen Sink" (Java Project + OS + Post-build)** *A complex pipeline running in Remote mode.* ``` # 1. Fix Maven dependencies mvn dependency:resolve seal fix --mode remote # 2. Fix Linux OS packages seal fix os --mode remote # 3. Fix an existing Wheel file in the libs folder seal fix fs --path ./libs/math_lib.whl --mode remote ``` [^1]: A sealed version is a fully compatible version built by Seal to remediate the vulnerabilities in a package. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sealsecurity.io/cli-integration.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.