Editing Dependencies

If you choose not to integrate Seal's CLI into your CI, then to use the sealed packages you must manually edit your dependency files.

For direct dependencies this is usually trivial, however editing transitive dependencies can be challenging on some ecosystems (for example npm). It is therefore advised to use this configuration only if integrating Seal's CLI as part of your CI isn't possible, and to always verify build results after every manual edit.

Example:

With this approach, suppose you have in your package.json file a dependency on the npm library ejs, and the version range specified is "^2.0.0". This dependency will resolve to the latest ejs version 2, which is version 2.7.4. This version has a critical vulnerability, so you will want to replace it with the sealed version ejs@2.7.4-sp1. You will have to replace this line of code:

"ejs": "^2.0.0"

with this line:

"ejs": "2.7.4-sp1"

This will cause the npm package manager to look for ejs@2.7.4-sp1 on the next npm install. However, this version obviously is not found on the standard npm server, only on Seal's artifact server.

Therefore to use this method to seal packages we must first configure our package manager to use Seal's artifact server.

Connecting to the artifact server

If you already connected to Seal's artifact server in order to provide package discovery as detailed here, you can skip the rest of the page.

The first thing you must do is generate an access token to the artifact server.

Afterwards, you will need to configure the Seal artifact server as an artifact source in your package manager (or third-party artifact server provider such as JFrog or Nexus). The main server configurations are explained in this page. For package manager-specific information see here.

Artifact server configurations

Primary server:

The recommended configuration is just to configure Seal's artifact server as the primary artifact server used by your package manager. That way, every package the package manager tries to download is requested from Seal's server. The Seal server will then redirect all ordinary traffic to the default global servers, while serving sealed packages on-demand. This will provide the platform with visibility to all vulnerable packages that are being downloaded.

The major advantage of this configuration is its relative simplicity together with the full visibility it provides.

Note that due to caching issues, and depending on your CI's configuration, not all packages are necessarily downloaded every time you build your project. Make sure to clear your cache at least once to provide the server with complete visibility to all the packages you're downloading.

Secondary server:

Another way to configure Seal's artifact server is as a kind of server-of-last-resort, that is only used to pull sealed packages.

In this configuration, the Seal server is configured after some ordinary public server, such that any ordinary package is pulled from the public server. This way, the package manager turns to the Seal server only for packages that aren't available on the public server, i.e sealed packages.

With this configuration, Seal has no visibility as to the vulnerable packages that are in use by the organization.

Private artifact servers

Seal's artifact server can be used in conjunction with a private artifact server, in the same manner as the regular public servers.

Each package manager has its own way to configure more than one artifact server. Since the private packages won't ever be found on Seal's server, and the sealed packages won't be found on the private server, it doesn't matter in what order the servers are defined in relation to one another.

Third party artifact servers

Another common setup is to use some external artifact server provider, for example JFrog or Nexus. Each such solution has its own way of declaring remote repositories.

To use Seal's artifact server with such a solution you will only need to add Seal's server as another remote server. Note that as described above, it's important to configure Seal's server in a higher priority than the normal public servers, otherwise the platform will have no visibility as to which vulnerable packages are in use.

How to configure your package manager?

For more details about how to configure each package managers, see this section.