CLI
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.
Whenever a vulnerable dependency is identified by Seal’s GitHub app, 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:
Adding Seal's CLI to each CI pipeline. This can be done gradually over time.
Connecting Seal's GitHub app to all relevant repositories. 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.
Note that the local configuration file is a straightforward yaml file, making even manual edits easy. The following is an example:
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.
Last updated
