Editing Dependencies
Last updated
Last updated
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.
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.
The first thing you must do is 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 .
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.
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.
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.
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.
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 at least once to provide the server with complete visibility to all the packages you're downloading.
For more details about how to configure each package managers, see .