FAQ
Last updated
Last updated
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.
Licenses are annual and based on the number of developers and/or actively patches versions, depending on the product(s) included.
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.
, with the Seal platform you can detect vulnerable packages in your source code, or as part of your CI pipeline.
Seal Security is certified with SOC-2 type II and ISO-27001. See more information on our page.
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.
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.
Seal Security offers 24/7 support, including direct Slack / Teams channels with our customers.
We currently support for Java, Python, Javascript, C/C++, Go, PHP, C#, Ruby.
We support all major Linux distributions, including RHEL, CentOS, Alpine, Debian and many more.
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.
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.
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.
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.
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.
Seal Security has proprietary technology to make sure that external scanners run by your customers don’t falsely mark the sealed packages as vulnerable.
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.
The Seal platform has built-in integrations with GitHub, GitLab and Azure DevOps.
Yes, while our solution works best as a SaaS solution, it’s possible to use our remediated versions in an on-prem setup.
Seal OS supports all of the above - containers, virtual machines as well as bare metals.
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.
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.
None! We’re entirely a build-time solution, so no permissions are necessary.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Turn on the Remote configuration in the Preferences tab in the Settings screen (accessible by clicking at the bottom left of the screen).
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.
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.
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.