What a sealed package is

How a sealed version is built, the sealed-version suffix, what is covered by default, and what an open vulnerability means.

A sealed package is a version of an open-source package that Seal has built from the public source code of a specific release, with security fixes backported into it.

Built from the origin version

The starting point is the origin version: the public release the customer is currently using. Seal pulls the source for that release, applies a targeted patch for each vulnerability in scope, and rebuilds the package. The diff against the origin version is published; see the code diff page.

Backporting means taking a fix from a newer release (or, when no upstream patch exists, writing one) and applying it to the older codebase, without bringing in the rest of the newer release. The sealed version is, in practice, a fork of one specific release with targeted security patches applied.

The sealed-version suffix

A sealed version's identifier is the origin version with a sealed-version suffix. The exact form of the suffix depends on the ecosystem's versioning rules.

For npm, the first sealed build of ejs@2.7.4 is ejs@2.7.4-sp1. If a new vulnerability is later disclosed and Seal ships a fix for it, the next sealed version is ejs@2.7.4-sp2, which contains every fix from -sp1 plus the new one. Each iteration is cumulative.

Other ecosystems use different separators (+sp1 for Maven and PyPi, for example) and Alpine uses a different scheme entirely. The full table is in Naming and versioning conventions.

The safest version

The safest version for a given origin version is the most recent sealed version released for that origin. Each origin version has its own safest counterpart; cumulative fixes flow into the same line.

Seal calls this "safest" rather than "latest" because, in package-manager parlance, "latest" usually refers to the most recent upstream public release of the package, which is a completely different concept. The safest version of ejs@2.7.4 is the most current sealed counterpart of ejs@2.7.4, not a newer upstream release of ejs.

What is covered by default

Seal backports fixes for critical and high severity vulnerabilities by default. Coverage of medium and low severities is available on request through your Seal account team. Once a fix is built for any customer, it ships in the same sealed-version line and is available to every customer using that package.

A sealed package can carry open vulnerabilities: vulnerabilities that have not been remediated in the current sealed version. There are several reasons:

• The severity is below the default scope (medium or low) and no customer has requested a fix.

• The vulnerability was disclosed after the current sealed version shipped; the next iteration will address it.

• The vulnerability's severity, or even its validity as a vulnerability, is disputed.

• The vulnerability cannot be remediated without a behavioral change that would break compatibility. These cases are addressed by private versions. A private version is not perfectly backwards compatible with the origin version, but the difference is usually small and often does not affect the customer's actual use of the package. Seal walks each customer through the change so they understand it, then selectively enables the private version for the Seal Projects where it applies.

The Protection page shows which vulnerabilities are sealed and which remain open in each sealed package.

Related

• Drop-in replacements, not upgrades: the mental model.

• How sealed packages are delivered: the technical model.

• Naming and versioning conventions: the full version-suffix grammar across ecosystems.