# Partial fixes & open vulnerabilities A sealed package is a drop-in replacement for an origin version with security fixes backported in. "Backported" sometimes means "every vulnerability the origin version had is gone" but not always: a sealed version may still list **open vulnerabilities** in the [Vulnerabilities tab of the drawer](/new-documentation/new-docs/vulnerability-detail.md#the-vulnerabilities-tab). When that happens, the package is **partially fixed**. There are three reasons a sealed version may carry an open vulnerability, plus a related case where a vulnerability you expected to see does not appear at all. The first two are routine; partial fixes for those reasons are still worth deploying. The third needs a separate conversation. ## 1. The vulnerability is medium or low severity By default, Seal builds sealed versions that remediate **critical** and **high** severity vulnerabilities, not medium or low. A package with one open critical, three open highs, and two open mediums will, after sealing, still list the two mediums as open. They are not in scope for the default coverage. If your environment requires coverage of medium and low severities for a specific package or set of packages, your Seal account team can extend the scope. ## 2. The vulnerability was disclosed after the sealed version was released Seal builds a sealed version against the vulnerabilities it knows about at build time. A new vulnerability disclosed after the sealed version ships is open against that sealed version until Seal builds the next iteration: `sp2`, `sp3`, and so on, each one sealing every previous vulnerability plus the new one. What happens in your tenant when Seal publishes a new sealed version for a package you have already sealed depends on whether your existing Sealing Rule is pinned to a specific sealed version or tracks the safest version. * **Unpinned (safest version)**. The Sealing Rule automatically points at the new sealed version. The row for the previously-sealed version (for example, `ejs@2.7.4-sp1` once `sp2` ships) appears in Pending deploy; on the next CLI run, the build pulls `sp2` and the row moves to Sealed. The original origin-version row (`ejs@2.7.4`) continues to show Sealed throughout, because the package has been sealed the whole time. * **Pinned to a specific sealed version**. The Sealing Rule does not move on its own. The original origin-version row stays in Sealed (the pinned version was, and still is, sealed). A new row appears for the now-vulnerable previously-sealed version, with a **Seal** button next to it. Clicking the button is the path to update the Sealing Rule, either by pinning to the new sealed version or switching to the safest-version option. The same update can be made directly on the [Sealing rules tab](/new-documentation/new-docs/protection-page/sealing-rules-tab.md). ## 3. The vulnerability cannot be remediated without breaking changes Some vulnerabilities can only be removed by changing behavior the package's users may rely on. The pattern is usually one of these: * **Removing a feature that is itself the vulnerability.** For example, support for a deprecated, insecure cryptographic algorithm. The fix is to remove the algorithm; the breaking part is that callers still using the algorithm stop working. * **Changing a default from insecure to secure.** For example, switching a setting that was permissive by default to restrictive by default. Existing configurations that relied on the permissive default fail or behave differently after the change. The functionality being removed or changed is often obscure or undocumented, but some users do depend on it. Seal does not backport a fix that would silently break the customers using the sealed package: a sealed version is a drop-in replacement, by definition, and a behavior-changing patch is not. For these cases, Seal can build a [private version](https://github.com/seal-community/gitbook/blob/main/new-docs/discovering/private-versions.md) on request: a sealed version that includes the fix, with the customer's explicit acknowledgement of the compatibility impact. Private versions are not enabled in your tenant by default; ask your Seal account team to enable one for a specific package. ## A related case: a vulnerability that does not appear at all Sometimes a vulnerability that one of your other scanners flags does not appear in Seal's view at all, neither sealed nor open. The most common reason is that Seal has determined the vulnerability is not really a vulnerability for this package and version, and removed it from its database. The dispositions Seal applies: * **Not a vulnerability.** The reported issue is a regular bug with no security impact, or a legitimate feature the original researcher misclassified. * **Wrong package.** The vulnerable code is not actually compiled into this package, even though the source repository overlaps. This happens when several packages share a source tree but each only compiles a subset of the files; the researcher attributed the issue to the parent package without checking which artifact actually ships the code. * **Wrong version.** The vulnerability was introduced in a later version than the published affected-version range claims, so the version on the row is not actually affected. When Seal disposes of a vulnerability this way, it is removed from Seal's database. If it was the package's only vulnerability, the row does not exist on the Vulnerable packages tab at all. If the package has other vulnerabilities, the disputed one is absent from both the sealed and open lists in the drawer. Other scanners that have not made the same disposition may still report the vulnerability against the package; that is a downstream noise problem, addressed in [Scanner Exclusions](https://github.com/seal-community/gitbook/blob/main/new-docs/using-the-platform/scanner-exclusions/README.md). ## Where partial fixes show up in the UI * **The Vulnerabilities column on the Vulnerable packages tab** splits the chip count between sealed and open vulnerabilities. A row whose package has been sealed but still has open vulnerabilities shows both counts. * **The drawer's Vulnerabilities tab** lists sealed and open vulnerabilities side by side. Each open vulnerability is an entry with the same fields as a sealed one (identifier, severity, advisory link), so you can see exactly what is left. * **The package's row state** stays as Sealed when the package has been replaced with the sealed version, even if open vulnerabilities remain. The Sealed state means "the sealed version is in use", not "every vulnerability is gone". ## Related * [Vulnerability detail](/new-documentation/new-docs/vulnerability-detail.md): the drawer where the open list lives. * [private versions](https://github.com/seal-community/gitbook/blob/main/new-docs/discovering/private-versions.md): the path for vulnerabilities that need a behavior-changing patch. * [Package states](/new-documentation/new-docs/package-states.md): why a row stays in Sealed state even when open vulnerabilities remain. * [Scanner Exclusions](https://github.com/seal-community/gitbook/blob/main/new-docs/using-the-platform/scanner-exclusions/README.md): the workaround for vulnerabilities that other scanners flag but Seal has disputed. --- # 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/partial-fixes.md?ask= ``` 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.