# What a sealed package is

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](https://github.com/seal-community/gitbook/blob/main/new-docs/trust-compliance/code-diff/README.md) 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](https://github.com/seal-community/gitbook/blob/main/new-docs/reference/naming-and-versioning/README.md).

## 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](https://github.com/seal-community/gitbook/blob/main/new-docs/discovering/private-versions.md). 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](/new-documentation/new-docs/seal-approach/drop-in-replacements.md): the mental model.
* [How sealed packages are delivered](/new-documentation/new-docs/seal-approach/sealing-approaches.md): the technical model.
* [Naming and versioning conventions](https://github.com/seal-community/gitbook/blob/main/new-docs/reference/naming-and-versioning/README.md): the full version-suffix grammar across ecosystems.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sealsecurity.io/new-documentation/new-docs/seal-approach/sealed-packages.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.