User Guide
  • Fundamentals
    • Quick Start Guide
      • Signing Up
      • Package Discovery
        • Connecting to GitHub
        • Connecting to GitLab
        • Connecting to Azure DevOps
        • Connecting to the CI Pipeline
        • Connecting to the Artifact Server
      • Package Sealing
        • Integrating the CLI in the CI
        • Editing Dependencies
    • Deployments
      • Choosing Your Deployment
      • Automatic Remediation
      • Remote Configuration
      • Local Configuration
      • Artifact Server
    • CLI
      • Download and Installation
      • Scanning
      • Fixing All Dependencies
      • Fixing Specific Dependencies
      • Fixing OS Vulnerabilities
      • Integrating with the CI
      • Uploading Scan Results
      • Commands
      • SCA Integrations
      • JFrog Integration
      • Usage Examples
        • Sealing Application Dependencies
        • Sealing Linux Environments
    • Artifact Server
      • Generating a Token
      • Artifact Server Ordering
      • Configuring the Package Manager
        • Configuring apk
        • Configuring Composer
        • Configuring Go
        • Configuring Gradle
        • Configuring Maven
        • Configuring npm
        • Configuring pip
        • Configuring Poetry
        • Configuring yarn
        • Configuring yum
      • Clearing the Cache
      • Editing Your Dependencies
    • Web Interface
      • Rules Screen
  • APIs
    • List Vulnerable Packages
  • FAQ
  • Vulnerability Disclosure
Powered by GitBook
On this page
  • The Seal platform
  • Technical questions
  • How to use the platform

FAQ

PreviousList Vulnerable PackagesNextVulnerability Disclosure

Last updated 17 hours ago

The Seal platform

What are the key benefits of the Seal platform?
  • Allow security teams to independently remediate open source vulnerabilities without being dependent on dev teams.

  • Fix multiple instances of the same vulnerabilities from one centralized location, with one click.

  • Dramatically reduce MTTR, and reduce the time developers waste on chasing upgrades instead of building your product.

  • Extend the life of EOL components, including Linux machines, without compromising on security.

  • Fix otherwise impossible to fix vulnerabilities in core components.

  • Eliminate the friction between security teams and developers.

What is the licensing model?

Licenses are annual and based on the number of developers and/or actively patches versions, depending on the product(s) included.

What is your SLA for new vulnerabilities?

We handle all critical and high rated vulnerabilities within 72 hours of being made public. Lower rated vulnerabilities are handled in accordance with the contractually agreed SLA.

Do you provide a scanning solution?

, with the Seal platform you can detect vulnerable packages in your source code, or as part of your CI pipeline.

What compliance certifications do you have?

Seal Security is certified with SOC-2 type II and ISO-27001. See more information on our page.

How does the Seal platform affect package licenses?

Seal Security’s patches do not affect your organization’s licensing requirements. Our patches are released with a permissive license, however you still must abide by the terms of the original package’s license.

How far back do you support?

We don’t have a hard limit for how far back we support. As long as the source code is publicly available, we can fix it.

What kind of support do you offer?

Seal Security offers 24/7 support, including direct Slack / Teams channels with our customers.

How can I contact customer support?

Technical questions

What programming languages do you support?

We currently support for Java, Python, Javascript, C/C++, Go, PHP, C#, Ruby.

What Linux operating systems do you support?

We support all major Linux distributions, including RHEL, CentOS, Alpine, Debian and many more.

How do I deploy the Seal platform in my organization?
  1. Use Seal as an artifact server - the developers specify the sealed versions in the requirements files, and the package manager pulls them from our server.

  2. Incorporate the Seal CLI into your CI pipeline - immediately after pulling the packages as you would normally do, our tool will replace the vulnerable packages with their remediated versions according to preset instructions. These instructions can be found either:

  • In a configuration file in the project’s git repository, controlled by the developers.

  • On the Seal server, allowing security teams to independently remediate vulnerabilities without needing permissions to the source code.

What CI pipelines do you support?

We work with all CI pipelines. The CI integration just requires running a simple command on our standalone CLI tool, which can be incorporated as a build step in any pipeline.

How does the Seal platform integrate with my existing security scanners?

The Seal platform supports a variety of integrations with existing security scanners. These scanners will then know that a specific vulnerability in a specific package was remediated by Seal Security, and present it accordingly.

What happens if a new vulnerability comes out to one of the remediated packages?

Typically scanner APIs allow to specify that a specific vulnerability was remediated in a package, not that the entire package is vulnerability-free. Therefore, if a new vulnerability is published in a previously remediated package, your scanner will show just the new vulnerability as affecting your environment.

then Seal Security will provide a newer version remediating the old vulnerabilities as well as the new one, and meanwhile your scanner will show just the new vulnerability as affecting your environment.

How do you handle external scanners?

Seal Security has proprietary technology to make sure that external scanners run by your customers don’t falsely mark the sealed packages as vulnerable.

What if I have an existing artifact server provider?

Seal Security integrates with a variety of artifact server providers, by setting our server as an additional remote. Note that if you use the CI deployment then your artifact server configuration is irrelevant.

What source controls do you have integrations with?

The Seal platform has built-in integrations with GitHub, GitLab and Azure DevOps.

Do you support on-prem setups?

Yes, while our solution works best as a SaaS solution, it’s possible to use our remediated versions in an on-prem setup.

Do you support containers, virtual machines, bare metals?

Seal OS supports all of the above - containers, virtual machines as well as bare metals.

Do you support SSO?

We support a variety of SSOs, including Google, GitHub, Microsoft and Facebook.

Do you support SAML/OIDC?

Yes! Seal Security fully supports both SAML and OIDC, ensuring seamless integration with your existing identity provider. Our authentication solutions are designed to be secure, flexible, and easy to configure, so your team can enjoy a smooth and hassle-free login experience.

How does the product work?

The Seal platform leverages our proprietary backporting technology.

We backport the community’s security fixes to the exact older open source versions your organization is using, creating fully compatible vulnerability free versions that may be used in place of the vulnerable versions. The developers may then use these versions without doing any changes to their code.

What permissions do you need for my production environment?

None! We’re entirely a build-time solution, so no permissions are necessary.

What permissions do you need for my source code?

None! Our platform can identify what vulnerable packages you’re running and fix them without any permissions to your organization’s source code. Though note that if you provide us with read permissions, we will be able to scan your code for vulnerable dependencies more accurately.

Do you fix vulnerabilities that have no public fix?

In general, every “interesting” open source vulnerability has a public fix. In the vast majority of cases the vulnerability is published in tandem with the patch that fixes it.

However, on the rare occasion when there’s no community fix available to a critical or high rated vulnerability, we may create our own fix based on our vulnerability researchers’ understanding of the vulnerability.

Are there some vulnerabilities you can’t fix?

Yes, rarely (less than 5% on most ecosystems, less than 1% for C/C++ code) there is no clean way to backport a security fix without causing breaking changes. This happens when the vulnerability was previously considered a legitimate functionality of the library.

For example, support for an out-of-date cryptographic algorithm may be considered a vulnerability. Fixing the vulnerability means dropping support for that out-of-date algorithm, which is inherently breaking.

How do I know you won’t break my code?

As a rule, we use the community fixes with the minimal necessary changes. Our fixes are tiny, usually fewer than 10 lines-of-code, compared with the hundreds or thousands of lines that typically change in a version upgrade, thereby dramatically reducing the risk of unforeseen side effects.

All our remediated versions undergo thorough testing and quality assurance processes, including manual inspection by our vulnerability research team, and by a dedicated AI tool that verifies there are no breaking changes.

And, since our platform runs at build-time, all of your existing tests run on our remediated version, providing an extra layer of assurance.

If something bad happens, how can I roll back?

Our versions are built to be fully compatible by design, so switching from the vulnerable to the remediated version or back is trivial, requiring no code changes by the developers. This greatly simplifies roll backs. All you need to do is to delete the suspected remediation rule, rebuild, and redeploy your component.

How do you test your packages?

We have several layers of testing:

  • We run the entire suite of tests the open source library has on all the relevant environments.

  • We backport the dedicated tests that were written to make sure the vulnerability was properly remediated. This both allows us to make sure the vulnerability was remediated in the sealed version, as well as provide us coverage tests for the exact code areas that were changed.

  • For complicated patches we add our own tests to make sure there are no breaking changes.

  • We run a wide variety of sanity tests to make sure the sealed version is identical in every way to the original version, including the same dependencies, files, metadata, etc.

  • We run our proprietary AI tool to make sure there are no breaking changes that our vulnerability researchers may have missed.

How can I know your patches work?
  • Our patches are based on the community fixes. Our customers have access to see the code changes for themselves.

  • You are welcome to do any kind of pen testing on the remediated package, including running some well known exploits.

  • Trust - our entire product is based on trust. While we do try to be as transparent as possible with our changes, the fact is you need to trust us and our platform.

How are your patches different from regular upgrades?

Typical upgrades of a decent sized library include hundreds, thousands, or even tens of thousands lines of code. The vast majority of these are entirely irrelevant to any vulnerability, and include new features, API changes, and more. And it’s these lines that break the developers’ existing code.

In contrast, our patches are on average 6.5 lines of code, essentially just adding the missing if’s the developers forgot in the code to block the vulnerability. Our patches are not an upgrade to the latest version, they don’t introduce new features, they don’t even include non-security related bug fixes. Our patches include the minimum code changes required to block the vulnerability without affecting any legitimate existing behavior.

How will the developers build using the remediated package like the CI pipeline?

Depending on the chosen deployment, the developers will either configure Seal as their artifact server, or otherwise run our CLI tool when building the code - exactly the same as in the CI pipeline.

Isn’t it better to just stay on the latest version all the time?

If the choice were simply between always staying on the latest version or never upgrading, you wouldn’t be reading this.

The real question is whether you patch vulnerabilities or live with the risk. Staying on the latest version sounds ideal, but in practice, it’s often not feasible due to compatibility issues, breaking changes, and operational constraints. That’s why Seal Security helps you remediate vulnerabilities without disrupting your software.

Isn’t it better to just stay with the standard versions? At least they’re vetted by the community.

While the open source community is full of hard working volunteers, the reality is that in most projects (including well known ones such as core-js, npm, axios, etc...), there are only a handful of developers, working on it in their spare time. Plenty of code gets merged without even going through proper code review, never mind audited for its security.

In contrast, our code is vetted by both trained vulnerability researchers and advanced AI tools. Moreover, unlike a regular open source library, if there’s an issue, our support team is available 24/7.

How to use the platform

How do I import a new repository from my source control?
What if I need you to fix a package that you haven’t fixed yet?

Just click on the Generate fix button. It will trigger an automated process that will create a remediated version for the relevant package. The newly remediated version should become available within 72 hours.

What's the difference between Watcher, Collaborator, Sealer and Admin?
  • Watchers have only Read-Only permissions to the platform.

  • Collaborators can also ignore vulnerable packages, archive projects, configure automated scans frequency, and overall control everything regarding package discovery, but not remediation.

  • Sealers can affect your production environment by creating, editing and deleting remediation rules.

  • Admins can do all of the above, in addition to various administrative tasks such as setting user roles, inviting and removing users, etc.

How does the Seal platform know what vulnerabilities I have?

There are 3 primary ways to let the Seal platform know what vulnerabilities you have:

  • Connect it to your source control and it will scan your dependency files.

  • Configure it as your artifact server. It will identify any vulnerable package that is pulled. Note that this view is incomplete, since most setups have several layers of caching.

How do I invite new users to the platform?

As an Admin, click on the Settings icon at the bottom left of your screen. Go to the User permissions tab, and click on the Invite new user button.

How do I configure automatic pull requests?

Click on the Settings icon at the bottom left of your screen. Go to the Preferences tab, and click on the Automated pull requests section.

How do I configure automatic code scanning?

Click on the Settings icon at the bottom left of your screen. Go to the Preferences tab, and click on the Source code scanning section.

How do I configure remediation rules?

In the Protection screen go to the Rules tab. Here you can create remediation rules specifying which packages to replace with their remediated version. These rules can either be for individual packages in individual projects, or they can apply more broadly to entire projects or even all projects.

Remember that to use the remediation rules, you must:

  1. Turn on the Remote configuration in the Preferences tab in the Settings screen (accessible by clicking at the bottom left of the screen).

What is the frequency I should update the CLI?

If your CI pipeline has access to the internet, the best practice is to always pull the latest version. Otherwise, take care to upgrade the CLI at least once every quarter.

How should I configure the CLI?

You can use local mode and save the remediation instructions in a configuration file in your project’s root directory. This will require every change to go through a pull request approved by the developers.

You can use remote mode and define the remediation rules using the web interface. This allows every person with Sealer or Admin permissions to define remediation rules, potentially allowing security teams to independently remediate the vulnerabilities without going through the R&D team.

You can use all mode and have our CLI automatically replace every vulnerable package it finds with its remediated version. No user input necessary.

How can I generate a report listing the sealed packages that I’m using?

In the Protection screen go to the Sealed packages tab. Click on the download button at the right of the screen.

The best method is to contact us via the joint Slack / Teams channel we have with your organization. You can also email . For urgent cases you can email which will immediately trigger our on-call support.

There are 2 main ways (which you can read about more in the section):

For a deeper dive into why “new” isn’t always better, check out our blog .

Go to the Projects screen. Click on the Import projects button and select the relevant code repository, and follow the instructions. For documentation about how to link your source control with the Seal platform see .

and it will identify what packages you’re using.

Use the CI deployment that the Seal CLI tool.

Use mode in the CLI.

It on how you want to decide which packages to fix.

Yes
compliance
support@sealsecurity.io
emergency@sealsecurity.io
deployments
post
here
Connect it to your CI pipeline
runs
remote
depends