FAQ
Frequently asked questions about Seal Security.
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 patched versions, depending on the products 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?
Yes. With the Seal platform you can detect vulnerable packages in your codebase, 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 compliance 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; 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 on 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?
The best method is to contact us via the joint Slack / Teams channel we have with your organization. You can also email support@sealsecurity.io. For urgent cases you can email emergency@sealsecurity.io which immediately triggers our on-call support.
Technical questions
What programming languages do you support?
We currently support Java, Python, JavaScript, C/C++, Go, PHP, C#, and 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?
There are 2 main ways (which you can read about more in the deployments chapter):
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 replaces 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 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 you 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.
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 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 is 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, and bare metals.
Do you support SSO?
We support a variety of SSO providers, including Google, GitHub, Microsoft, and Facebook.
Do you support SAML/OIDC?
Yes. Seal Security fully supports both SAML and OIDC, so you can integrate with your existing identity provider.
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 are 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 are running and fix them without any permissions to your organization's source code. 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.
On the rare occasion when there is 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 cannot fix?
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 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 will not 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, 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 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 verify the vulnerability was properly remediated. This both lets us confirm the vulnerability was remediated in the sealed version, and provides 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, and so on.
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 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 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 of lines of code. The vast majority of these are entirely irrelevant to any vulnerability, and include new features, API changes, and more. And it is 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 ifs the developers forgot in the code to block the vulnerability. Our patches are not an upgrade to the latest version, they do not introduce new features, they do not 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 either configure Seal as their artifact server, or 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 would not 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 is often not feasible due to compatibility issues, breaking changes, and operational constraints. That is why Seal Security helps you remediate vulnerabilities without disrupting your software.
For a deeper dive into why "new" is not always better, check out our blog post.
Isn't it better to just stay with the standard versions? At least they are 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, and so on) 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 is 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?
Go to the Projects screen. Click the Import projects button, select the relevant code repository, and follow the instructions. For documentation about how to link your source control with the Seal platform see Connecting source control.
What if I need you to fix a package that you have not fixed yet?
Click the Generate fix button. This triggers an automated process that creates 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 scan 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, plus various administrative tasks such as setting user roles and inviting or removing users.
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.
Connect it to your CI pipeline and it will identify what packages you are using.
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 the Settings icon at the bottom left of your screen. Go to the User permissions tab, and click the Invite new user button.
How do I configure automatic pull requests?
Click the Settings icon at the bottom left of your screen. Go to the Preferences tab, and click the Automated pull requests section.
How do I configure automatic code scanning?
Click the Settings icon at the bottom left of your screen. Go to the Preferences tab, and click 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:
Turn on Remote configuration in the Preferences tab in the Settings screen (accessible by clicking at the bottom left of the screen).
Use the CI deployment that runs the Seal CLI tool.
Use remote mode in the CLI.
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?
It depends on how you want to decide which packages to fix.
You can use local mode and save the remediation instructions in a configuration file in your project's root directory. This requires 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.
Last updated