Local Configuration

Overview

With this deployment, each project has its own local configuration file called .seal-actions.yml, which is saved in the project’s root directory. This file defines which packages are replaced with their sealed version.

To fix a vulnerability, the .seal-actions.yml must be updated (or created from scratch if it doesn't already exist). It is possible to configure automatic pull requests through the web interface. Just click on the Settings button (bottom left corner), then the Preferences tab, and then Automatic pull requests. With these configured, whenever a vulnerable dependency is identified by Seal’s source control integration, it will automatically create a pull request updating the file to signify that the vulnerable package should be replaced by its sealed version.

The actual substitution is done by Seal’s CLI, which is integrated in the CI pipeline immediately after the packages are installed (for example npm install). The CLI reads the local configuration file, and then replaces the vulnerable packages with the sealed versions accordingly.

Integration

The initial integration requires:

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

2. Connecting Seal to all relevant repositories in your source control. Note that this is not strictly required, however without it automatic pull requests will not be available, and the developers will be forced to edit the local configuration file manually or using the CLI.

Sealing a package

The simplest way to seal a vulnerable package is by using the automatic pull requests feature. Seal will identify the vulnerable package in the source code, and create a pull request modifying the project's local configuration file.

Manually editing the .seal-actions.yml

The local configuration file is a straightforward yaml file, making even manual edits easy. The following is an example for such a file:

meta:
  schema-version: 0.1.0
  created-on: "2024-05-01T09:59:51Z"
  cli-version: 0.2.0
projects:
  seal-sec-demo-demo:
    targets:
      - package.json
    manager:
      ecosystem: node
      name: npm
      version: "9"
    overrides:
      ejs:
        2.7.4:
          use: 2.7.4-sp1
      postcss:
        8.4.30:
          use: 8.4.30-sp1
        7.0.39:
          use: 7.0.39-sp2

If you don't already have a .seal-actions.yml, and you want to seal your first package:

1. Download the Seal CLI.

2. From your project's root directory, run:

   seal add package-name version

   Note that this will create a new .seal-actions.yml that only replaces the specific package provided with its remediated version.

3. If you want to fix in your project everything that has a sealed version, run instead:

   seal scan --generate-local-config

Once you have a valid .seal-actions.yml file, adding or removing remediation instructions only entails changing the overrides section in an obvious way. This can be done either using the CLI with the aforementioned commands, or manually.

Merging your pull request

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. However, as the pull requests naturally trigger the automated tests in the pipeline, the developers can verify there’s no negative impact.

Once a developer reviews and approves the changes, the pull request will be merged and the changes will be reflected on Seal's web application.

Sealing a package using the local configuration