User Guide
  • Fundamentals
    • Quick Start Guide
      • Signing Up
      • Package Discovery
        • Connecting to GitHub
        • Connecting to GitLab
        • Connecting to Azure DevOps
        • Connecting to the CI Pipeline
        • Connecting to the Artifact Server
      • Package Sealing
        • Integrating the CLI in the CI
        • Editing Dependencies
    • Deployments
      • Choosing Your Deployment
      • Automatic Remediation
      • Remote Configuration
      • Local Configuration
      • Artifact Server
    • CLI
      • Download and Installation
      • Scanning
      • Fixing All Dependencies
      • Fixing Specific Dependencies
      • Fixing OS Vulnerabilities
      • Integrating with the CI
      • Uploading Scan Results
      • Commands
      • SCA Integrations
      • JFrog Integration
      • Usage Examples
        • Sealing Application Dependencies
        • Sealing Linux Environments
    • Artifact Server
      • Generating a Token
      • Artifact Server Ordering
      • Configuring the Package Manager
        • Configuring apk
        • Configuring Composer
        • Configuring Go
        • Configuring Gradle
        • Configuring Maven
        • Configuring npm
        • Configuring pip
        • Configuring Poetry
        • Configuring yarn
        • Configuring yum
      • Clearing the Cache
      • Editing Your Dependencies
    • Web Interface
      • Rules Screen
  • APIs
    • List Vulnerable Packages
  • FAQ
  • Vulnerability Disclosure
Powered by GitBook
On this page
  • Integration
  • Sealing a package
  • Unsealing a package
  1. Fundamentals
  2. Deployments

Remote Configuration

PreviousAutomatic RemediationNextLocal Configuration

Last updated 5 months ago

Overview

With this deployment, rules defining which packages are replaced with their sealed version are set on the Seal server using Seal's web interface.

To fix a vulnerability a new rule must be defined through the web interface.

The actual substitution is done by Seal’s CLI, which is immediately after the packages are installed (for example npm install). The CLI pulls the instructions from the Seal server, and then replaces the vulnerable packages with the sealed versions accordingly.

Integration

The initial integration requires:

  • Adding Seal's CLI to each CI pipeline. This can be done gradually over time.

Sealing a package

The simplest way to seal a package is through the Protection screen.

Next to the alert regarding the vulnerable package, click on the Seal button.

In the Sealing instructions dialog under the Remote tab you will be able to define a new rule for this package. A local rule will apply only for this projectt, whereas a global rule will apply for all projects.

Once you create a rule sealing the package the vulnerable package will have the green Sealed marking where the Seal button was before (see the first screenshot).

The sealed versions are made to be fully-compatible with the vulnerable ones, so other than fixing the vulnerability there are no side-effects to the substitution. The next time your CI pipeline runs it will incorporate the remediated version instead of the vulnerable one.

Unsealing a package

To unseal a package, click on the "..." next to the sealed package's row, and click Unseal package.

In the dialog that pops up you'll be able to delete the rule that sealed this package.

Note that in principle it's possible that more than one rule defines that a certain package will be sealed. For example, you may first have defined to fix ejs@2.7.4 in a particular project. Then, after encountering the same vulnerable package in a different project, you may have defined the a global rule fixing all instances of ejs@2.7.4. This means that there are actually two distinct rules that specify that ejs@2.7.4 from the first project must be remediated. If that is the situation, you will see more than one rule in the unseal dialog, and you will be able to select if and what rules to delete.

integrated in the CI pipeline
Sealing a package using the remote configuration