Glossary

The Seal-specific vocabulary used throughout these docs.

Seal-specific terms used throughout these docs, alphabetized. Standard industry terms (CI/CD, SBOM, SSO, and so on) are not redefined here unless Seal uses them in a particular way.

Artifact

A specific file downloaded from an artifact server. Examples: ejs-2.7.4.tgz (an npm artifact), junit-4.13.jar (a Maven artifact), requests-2.31.0-py3-none-any.whl (a Python wheel).

Attestation

A signed document Seal publishes alongside each sealed artifact, listing exactly which vulnerabilities have been remediated. Two formats are produced for every artifact: a human-readable PDF, and a machine-readable Vulnerability Exploitability eXchange (VEX) record.

Build-time dependency sealing

A sealing approach in which the customer's build picks up a sealed dependency at build time and uses it in producing the customer's own artifact. The path for application-dependency ecosystems like npm, pip, Maven, Gradle, Go modules, Composer, Bundler, and NuGet.

CLI fix mode

The mode the Seal CLI runs in. Three values: local (rules from a .seal-actions.yml file in your source), remote (rules from the Seal Platform UI), all (every vulnerable package replaced automatically).

Code diff

The diff between a sealed version and its origin version. Seal publishes the code diff for every sealed package; you can view it on the Protection page or the Repository page.

CVE

Common Vulnerabilities and Exposures identifier (for example, CVE-2023-45857). Seal uses CVEs as the primary vulnerability reference. When a CVE is not assigned to a vulnerability, Seal falls back, in order of preference, to a GHSA (GitHub advisory ID), a Snyk ID, or another source's identifier (such as a Sonatype ID).

Default project

The built-in catch-all Seal Project that exists in every tenant. Collects package-detection results that cannot be attributed to a specific Seal Project, such as unattributed SBOM uploads. Treated as a view rather than a real Seal Project: it should not be connected to source control or used as a CLI target.

Deployment method

How Seal is integrated into your environment. Five named methods: Automatic Remediation, Remote, Local, Artifact Server, Manual.

Dev dependency

A dependency the package manager has marked as used only for testing or building, not for shipping to production. Seal can identify a dev dependency only when the ecosystem's package manager exposes the marking natively (for example, the devDependencies block in package.json for npm or Yarn) AND Seal has source-code access to the project. Anything not explicitly marked is assumed to reach production. Distinct from a development token, which is a tenant-level credential.

Development token

A Seal token issued for use on developer machines and other untrusted contexts. Activity authenticated with a development token is filtered out of the Protection page by default, so day-to-day developer experimentation does not pollute production posture metrics. Contrast with a production token. Distinct from a dev dependency.

Discovered package

A package Seal has seen in your environment, regardless of which package discovery mode produced the signal.

Ecosystem

A language environment or OS package format that Seal works with. Examples: Java, Python, npm, APK, RPM.

Last seen

The Seal UI timestamp showing when Seal most recently saw a given package. Accurate across all four package discovery modes.

Open vulnerability

A vulnerability that has not yet been remediated by Seal in the current sealed version. May be open for several reasons: outside Seal's default scope (medium or low severity), disclosed after the current sealed version shipped, severity disputed, or unable to be remediated without breaking compatibility (in which case a private version may be available).

Operating system / OS

The OS layer of the customer's environment, typically a Linux distribution. The abbreviation "OS" in Seal's docs always means operating system, never open source.

Origin version

The community's upstream version of a package: the public release before Seal builds a sealed counterpart from it. For example, [email protected] is the origin version that Seal builds [email protected] from.

Package

A unit of open-source software, distributed through a package manager. Examples: ejs (an npm package), commons-text (a Maven package), requests (a Python package).

Package discovery mode

The per-Seal-Project setting that determines how Seal sees the customer's packages. Four values: source code, CLI, artifact server, imported manifest.

Package manager

A specific tool within an ecosystem. Examples: Maven and Gradle within Java; npm, Yarn, and pnpm within JavaScript.

Package state

The lifecycle position of a package on the Vulnerable packages tab. Six values: Sealed, Pending deploy, Ready to seal, Version in progress, Generate available, Unfixable.

Package version

A specific version of a package, expressed in the ecosystem's version format. Example: [email protected].

Post-build artifact sealing

A sealing approach in which Seal produces a fully built artifact (typically a JAR or Python wheel) that the customer drops into a built environment, replacing an existing artifact in place. Used when a rebuild is not available or not practical, most commonly inside container images.

Private version

A sealed version that is not perfectly backwards compatible with the origin version. Seal enables a private version for a specific Seal Project after the customer has requested it and acknowledged the compatibility change.

Production token

A Seal token issued for use in production-equivalent environments: CI/CD pipelines, build infrastructure, and any other context where the resulting activity should count toward your security posture. Activity authenticated with a production token is fully tracked on the Protection page. Contrast with a development token.

Project ID

A Seal Project's machine-readable identifier. Immutable after creation, restricted to letters, numbers, dots, hyphens, and underscores. The Seal CLI and the Seal Public API both work against the Project ID; the SEAL_PROJECT environment variable holds it. Distinct from the project's display name, which is mutable and used in the UI.

Reports Manager

The Seal UI surface for creating custom reports. Three report types in scope today: Vulnerable Packages, Sealed Packages, and ROI.

Safest version

The most recent sealed version released for a given origin version. Each origin version has its own safest counterpart; cumulative fixes flow into the same line. Distinct from "latest", which usually refers to the most recent upstream public release of the package.

Seal AI Agent

The Seal chatbot in the Seal UI. Used to query your security posture, create Sealing Rules through conversation, and get help integrating the Seal CLI into your CI/CD.

Seal Apps

The Seal product that remediates vulnerabilities in your application's third-party open-source dependencies.

Seal Artifact Server

The package registry that hosts every sealed package Seal has built. The Seal CLI fetches sealed packages from it; customers can also configure their package managers to point at it directly.

Seal Base Images

The Seal product that provides sealed versions of public container base images, derived from the upstream images you would normally pull.

Seal CLI

The command-line tool customers run to apply sealed packages or to report on what is discovered.

Seal Engineer

A periodic AI workflow feature, distinct from the Seal AI Agent. A Seal Engineer runs scheduled queries, posts updates to a configured Slack channel, and (with explicit permission) creates Sealing Rules autonomously.

Seal GitHub App

The GitHub-hosted application that connects a customer's GitHub repositories to Seal. Reads dependency manifests, opens automatic pull requests for fixes, and reports findings to the Seal Platform.

Seal My Container

The Seal product that produces sealed copies of customer private container images. Also known as container-to-container sealing.

Seal OS

The Seal product that remediates vulnerabilities in OS-level packages and language runtimes on Linux servers and inside containers, including EOL distributions.

Seal Platform

The Seal backend that holds your tenant's state: discovered packages, vulnerabilities, Sealing Rules, Seal Projects, users, tokens, and the operational data the UI and the CLI both work against.

Seal Project

The entity inside the Seal Platform that represents one of your codebases or build pipelines. Distinct from the customer's source repository, which is referred to as "your repository" or "your codebase". Has two distinct identifiers: a Project ID (machine-readable, fixed) and a human-readable name (mutable).

Seal Public API

The programmable surface for integrating Seal with external tooling.

Seal UI

The Seal web application: viewing discovered packages, creating Sealing Rules, managing Seal Projects, configuring tenant settings, operating the AI surfaces.

Seal Vendor Apps

The Seal product that remediates open-source vulnerabilities inside containers shipped by your vendors, by running in place inside the vendor's container in your environment.

Sealed package

A package Seal has built from a public origin version, with security fixes backported in. A drop-in replacement for the origin version, with no breaking changes.

Sealed version

The released sealed counterpart of a specific origin version, identified by the origin version plus a sealed-version suffix.

Sealed vulnerability

A vulnerability that has been remediated by Seal in the current sealed version of a package.

Sealed-version suffix

The marker on a sealed version's identifier that distinguishes it from the origin version. The exact form depends on the ecosystem: -sp1 for npm and Go, +sp1 for Maven and PyPi, and others for Ruby and Alpine. The full table is in Naming and versioning conventions.

Sealing approach

The technical mechanism by which a sealed package reaches the customer. Two approaches: build-time dependency sealing and post-build artifact sealing.

Sealing Rule

An instruction telling Seal which package to replace and with which sealed version. A Sealing Rule can be saved on the Seal Platform through the UI (a remote sealing rule) or in a .seal-actions.yml file in your source code (a local sealing rule). Applied by the Seal CLI when it runs.

Severity

The severity rating of a vulnerability. Four categories: critical, high, medium, low. Vulnerabilities without a CVSS score are treated as low; malicious packages are always critical. Seal's default scope fixes high and critical vulnerabilities only; medium and low severity coverage is available on request.

Tenant

The customer's top-level entity in the Seal Platform. Quotas (package usage, AI tokens) are tenant-wide.

Usage page

The Seal UI surface tracking tenant-wide consumption: package usage and AI token usage, against the contractual monthly quota.

VEX record

Vulnerability Exploitability eXchange record. A machine-readable format documenting which vulnerabilities apply (or do not apply) to specific software. Seal produces a VEX record alongside every sealed artifact; scanners that consume the Seal feed (Trivy, Wiz, and others) use VEX records to update their assessment of your environment.