Vulnerability detail

What the Protection page drawer shows for a discovered package.

When you click a package on the Vulnerable packages tab or Sealed packages tab, a drawer opens with the package's detail. The drawer is where you see why a package is flagged, what Seal can do about it, and how to apply the fix.

The drawer is organized into four tabs:

• Package info: top-level metadata for the package version (name, version, ecosystem, project, last seen).

• Vulnerabilities: the list of vulnerabilities affecting the package version.

• Sealing instructions: per-deployment instructions for getting this package sealed.

• Package diff (only when a sealed version exists): the per-vulnerability code diff between the sealed version and its origin version.

The drawer's footer shows a Generate fix button when the package is in the Generate available state. See Triggering Generate fix for what that does.

The Vulnerabilities tab

The Vulnerabilities tab lists every vulnerability affecting the package version, split into two groups side by side:

• Sealed: vulnerabilities Seal has remediated in the current sealed version. These are gone in the sealed counterpart of the origin version.

• Open: vulnerabilities that remain. The Seal UI labels this group "unsealed"; in this documentation we use open vulnerability.

Some published packages contain other packages compiled into the same artifact: a Java fat JAR that bundles several smaller packages into one file, a statically-linked C/C++ package, or any other case where one distributed artifact actually includes the code of separate dependencies. Vulnerabilities that originate in those bundled packages rather than in the host package's own code are grouped together under an Embedded package - <name> version <version> indicator, with a count of how many vulnerabilities came from that embedded package. The drawer does not show regular transitive dependencies under this indicator: those appear as their own rows on the Vulnerable packages tab, with their own drawers, because each one is its own distributable artifact.

Each vulnerability shows the same fields:

Field	Contents
Identifier	The CVE, GHSA, Snyk ID, or other reference. Malicious-package warnings are flagged as such instead of by CVE.
CVSS score	A numeric score, or N/A when no source has published a score.
Severity	Derived from the CVSS score: Critical for 9.0 or higher, High for 7.0-8.9, Medium for 4.0-6.9, Low below 4.0. Vulnerabilities with no score are treated as Low. Malicious packages are always Critical.
KEV badge	Marks vulnerabilities included in the CISA Known Exploited Vulnerabilities catalog.
Status	Sealed or open, matching the group the vulnerability is listed under.
Advisory link	One link to an upstream advisory, routed by the identifier shown: cve.org for CVEs, github.com/advisories for GHSAs, snyk.io for Snyk IDs, osv.dev for malicious-package records.

How the CVSS score is chosen

A vulnerability often appears in multiple databases (the National Vulnerability Database, GitHub Advisories, Snyk, Red Hat's CSAF feed) with potentially different CVSS scores. Seal does not pick one feed and ignore the rest. Instead, the score the drawer shows is the highest of the scores the available feeds have published for that vulnerability. If no feed has published a score, the field is empty and the vulnerability is treated as Low severity. Malicious packages are scored 10.

Package-level versus vulnerability-level severity

The Vulnerable packages tab's Vulnerabilities column on the row shows a single severity for the whole package. That value is the maximum severity across the package's open vulnerabilities. A package with one critical vulnerability and four low ones shows as critical on the row even though most of its vulnerabilities are low. Open the drawer to see the breakdown.

A package's risk is set by the worst vulnerability it carries. A single open critical vulnerability is enough to make the whole package critical to remediate; how many lower-severity vulnerabilities sit alongside it does not change that. An average or a count would understate the urgency of the worst case, which is the part you actually have to act on. Sealed vulnerabilities are excluded because they are no longer in the package: Seal's backport patched them out of the sealed version, so they are not part of the risk profile of the version actually in use.

Identifiers when a CVE is missing

Not every vulnerability has a CVE assigned. When the identifier in the drawer is not a CVE, Seal uses the next one available, in priority order:

1. CVE (CVE-YYYY-NNNNN).

2. Snyk ID (SNYK-...).

3. GitHub Security Advisory (GHSA-...).

4. Any other vendor-assigned identifier.

Malicious packages are flagged separately and labeled as such.

The Sealing instructions tab

The Sealing instructions tab gives you three deployment-method-specific paths for getting this package's sealed version into your build. The paths are themselves split into three sub-tabs.

Remote

Default state: a small form for creating a new remote Sealing Rule for this package and version, with a radio choice between making it project-specific (the default) or tenant-wide. Submitting the form has the same effect as the Seal button on the row.

When a Sealing Rule already covers this package and version, the Remote sub-tab shows the existing rules under "Existing applicable rules" instead of the form, with an Unseal action to remove the rule. When several rules cover the package, the sub-tab points you to the Sealing rules tab to manage them collectively.

Local

A copy-and-paste-ready Seal CLI command that adds a local Sealing Rule for this package to the project's .seal-actions.yml. Run the command from the project's working directory and commit the resulting change. See Local Sealing Rules for the file's full schema and the command's options.

Manual

Per-package-manager instructions for editing your dependency manifest so that your build pulls the sealed version through the Seal Artifact Server. The Manual sub-tab is for the Artifact Server deployment method specifically, not for the Manual deployment method (which uses the Repository page download). The instructions show your ecosystem's syntax (for example, the relevant package.json change for npm, the relevant pom.xml change for Maven).

When the Sealing instructions tab changes shape

• The package is already in the Sealed state: only the Remote sub-tab is shown, with the existing rule and the Unseal action.

• No sealed version exists yet: the tabs do not let you point your build at a version that does not exist. The drawer's footer shows the Generate fix button instead.

The Package diff tab

When a sealed version exists, the Package diff tab shows the code diff between the sealed version and its origin version. You can pick one vulnerability inside the tab and see the diff for that vulnerability alone, rather than the whole-package change set.

The diff covers every change Seal made to remediate the vulnerability: the patch itself, plus the dedicated tests Seal added to confirm the patch is effective. The tests are backported alongside the patch so the proof of remediation lives in the same artifact.

Related

• The Protection page: the parent page that hosts the drawer.

• Triggering Generate fix: the action behind the Generate fix button in the drawer footer.

• Code diff: the canonical home for the per-vulnerability patch view.

• Partial fixes & open vulnerabilities: why some vulnerabilities may show as open in the drawer even after a sealed version is in use.