# What is Seal Security Seal Security is a platform that **remediates open-source vulnerabilities by replacing the affected packages with sealed versions**. A sealed version is built from the same origin version, with security fixes backported in. Two properties make a sealed package useful: 1. It is **fully compatible** with the version it replaces. The public release's API, behavior, and dependencies are preserved. No new features, no breaking changes, no migration burden. 2. It is **free of high and critical vulnerabilities**. Coverage of medium and low severity vulnerabilities is available through your Seal account team. Drop a sealed package in. Your build keeps working. The vulnerabilities are gone. ## What Seal covers The platform supports five products at the same level. Each addresses a different layer of your stack. * **Seal Apps** remediates vulnerabilities in your application's third-party open-source dependencies (npm, pip, Maven, Gradle, Go modules, Composer, Bundler, NuGet, and more). * **Seal OS** remediates vulnerabilities in OS-level packages and language runtimes (Node.js, Python, JVM, .NET, and others) on your servers and inside your containers, including EOL distributions. * **Seal Base Images** delivers clean container base images derived from existing public images, with the underlying OS-level packages and language runtimes already remediated. * **Seal My Container** produces a sealed copy of your existing private container images that you push back to your own registry. * **Seal Vendor Apps** remediates vulnerabilities in the open-source dependencies and language runtime of vendor-supplied container images you run, such as a Kafka image. Seal Apps covers the layer of open-source dependencies that your code pulls in. The other four products cover the layers below: language runtimes and OS-level packages. They differ in how the fix is delivered: * **Seal OS** applies fixes in place via the Seal CLI on your servers and inside your containers. * **Seal Base Images** delivers a clean base container image you build on top of. * **Seal My Container** produces a sealed copy of your existing private container images. * **Seal Vendor Apps** runs like Seal OS, applying fixes in place inside vendor-supplied containers in your environment. See [The Seal product family](/new-documentation/new-docs/product-family.md) for one page per product. ## What is in scope Seal builds sealed packages and base images covering these ecosystems: * **Application package ecosystems**: JavaScript, Java, Python, Go, Ruby, C/C++, C#, PHP. * **OS package ecosystems**: APK, DEB, RPM. * **Container images**: Alpine, Debian, Ubuntu, CentOS, Red Hat, and other major Linux distributions, including out-of-support releases. By default, Seal backports fixes for **critical** and **high** severity vulnerabilities. Coverage of medium and low severity vulnerabilities is available through your Seal account team. ## What is not in scope Seal does not build sealed versions for ecosystems beyond those listed above. Seal does not modify your application code or your infrastructure without your explicit instruction. Depending on the deployment method, that instruction takes a different form: a Sealing Rule, a CLI flag, or a manifest change you make yourself. ## How Seal works alongside your existing tools Seal includes its own scanning capability for identifying vulnerable packages in your environment, and you can use it as your primary scanner. If you already use a vulnerability scanner like **Snyk**, **Black Duck**, **GitHub Advanced Security**, or **Ox Security**, Seal synchronizes its remediation findings into theirs so your existing dashboards stay accurate. For external scanners that customers of yours run against your products (**Trivy**, **Wiz**, and others), Seal publishes a vulnerability feed and Vulnerability Exploitability eXchange (VEX) records that those tools can consume directly. For scanners that do not consume the feed, Seal supports a renaming feature. A renamed sealed package presents a different package name in your manifests, so the scanner does not find a matching entry in its vulnerability database and raises no warning. ## How Seal fits into your environment Seal connects through one of four [package discovery modes](/new-documentation/new-docs/package-discovery-mode.md): integrating the Seal CLI into your CI/CD pipeline, connecting Seal directly to your source control (GitHub, GitLab, or Azure DevOps), configuring the Seal Artifact Server as a remote, or uploading a manifest one-shot. The deepest integrations (CLI in CI/CD or source-control connection) give Seal the most accurate view of your packages and the smoothest day-to-day experience. **Seal can operate without any access to your source code.** If your organization restricts source access for privacy or compliance reasons, the Seal CLI in CI/CD is the right path. The CLI runs inside your build, sees your dependencies there, and reports back to the Seal Platform without any source-repository connection. Once Seal can see your packages, you decide what gets remediated. The most common path is to create Sealing Rules in the platform: instructions for which packages to replace and with which sealed versions. The Seal CLI applies those rules on your next CI/CD run. Other deployment methods apply fixes through different mechanisms: full-automatic replacement when the CLI runs in **all mode**, manifest pinning when the Seal Artifact Server is your remote, or manual download from the Repository page. For the deeper "why patches over upgrades" framing, see [The remediation problem](/new-documentation/new-docs/remediation-problem.md). For the conceptual model, see [The Seal approach](/new-documentation/new-docs/seal-approach.md). --- # 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/what-is-seal.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.