Artifact Server


With this deployment, vulnerable dependencies are directly replaced in the relevant dependency or lock files (for example npm’s package-lock.json).

In the future, whenever a vulnerable dependency is identified by Seal’s GitHub app, it will automatically create a pull request updating the dependencies accordingly, so that next time the package manager will search for the sealed version instead. However for now, automated pull requests aren't available for this setup.

The package manager (or Artifactory) must be configured to use Seal’s artifact server so it will find the sealed packages. This can be done in a centralized manner if all pipelines are using Artifactory. Otherwise it must be configured individually for each pipeline.


The initial integration requires configuring Seal's artifact server as an artifact source in each CI pipeline. For example, here is how you would configure Seal as the artifact server on npm:


Sealing a package

The dependencies must be manually edited by the developers.

Unlike the CLI deployment which uses the local configuration file, here the developers are required to directly edit their dependencies to use the sealed packages. For example, here is how you would replace a transitive dependency on npm:

  "overrides": {
    "ini@1.3.5": "1.3.5-sp1"

Manually editing transitive dependencies can be challenging, and misconfigured dependencies might lead to quirky behaviors.

Developers are advised to verify after every manual edit that the packages pulled are what they expect them to be.

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