Seal Security FAQ

Question 1

What is Seal Security?

Accepted Answer

Seal Security delivers one-click, backported, compatible patches for existing versions of open source packages. Seal identifies and fixes vulnerabilities across Linux OS, base images, and application dependencies, including EOL and legacy systems. Seal's approach reduces technical debt, prevents risk downtime, and helps teams ship faster, without breaking changes or compromising security and compliance posture.

Question 2

What is the typical POV process?

Accepted Answer

The typical proof-of-value includes the customer selecting a test project, us providing the remediated versions for several vulnerable packages, and the customer testing it to see that everything works as expected. The entire process shouldn't take more than 2-3 weeks.

Question 3

Do you provide a scanning solution?

Accepted Answer

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

Question 4

How does Seal's platform affect the package licenses?

Accepted Answer

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 requirements of the original package's license.

Question 5

What kind of support do you have?

Accepted Answer

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

Question 6

What programming languages do you support?

Accepted Answer

We currently have support for Java, Python, JavaScript, C/C++, Go, PHP, C#, and Ruby.

Question 7

How does it integrate with my existing security scanners?

Accepted Answer

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.

Question 8

Do you support containers, virtual machines, bare metals?

Accepted Answer

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

Question 9

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

Accepted Answer

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 change in a typical 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.

Question 10

How are you different from other AppSec tools?

Accepted Answer

Other AppSec tools usually focus on visibility, providing you with a list of your open source vulnerabilities, or on prioritization, trying to creatively arrange that list. At Seal Security we focus on remediation, actually fixing the underlying vulnerabilities for you, clearing the list instead of just shuffling it around.

Question 11

What is your SLA for new vulnerabilities?

Accepted Answer

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.

Question 12

Can Seal fix vulnerabilities before a CVE is published?

Accepted Answer

Yes. Many security fixes land in open-source projects quietly, days or weeks before a CVE or advisory is published, and scanners can't flag a vulnerability that has no CVE yet.

Seal monitors upstream code changes for these silent security fixes. When we find one, our researchers reproduce the vulnerability and backport the fix to the versions you run, so a sealed version can be ready before the CVE goes public, and before attackers start working from the public fix.

Question 13

What compliance certifications does Seal Security have?

Accepted Answer

Seal Security is certified with SOC 2 Type II and ISO 27001.

Question 14

How far back do you support?

Accepted Answer

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.

Question 15

How can I contact support?

Accepted Answer

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 will immediately trigger our on-call support.

Question 16

How do I deploy the Seal platform in my organization?

Accepted Answer

Seal fits into the build you already have, and you can choose a method per project:

Seal CLI in your CI/CD pipeline (recommended). One step after your dependency install swaps vulnerable packages for their sealed versions. Sealing rules can live in the Seal platform, so the security team can remediate without pull requests or developer time, or in a .seal-actions.yml file in the repository for developer-led teams. You can also run it in automatic mode to seal everything that has a fix.

Seal Artifact Server. Point your package manager, or your JFrog Artifactory or Sonatype Nexus, at Seal and pin the sealed versions in your manifest. Nothing changes in CI.

Manual download. Download sealed packages from the Seal Repository and install them yourself. This also covers air-gapped environments.

Setup guides for every method are in our documentation.

Question 17

Where can I find Seal's documentation?

Accepted Answer

Our documentation is at docs.sealsecurity.io. It includes step-by-step setup guides for every deployment method, guides for connecting your scanners, registries and source control, and the Seal CLI and API references. Every page is also available as Markdown, and docs.sealsecurity.io/llms.txt indexes it all for AI assistants.

Can't find what you need? Reach out on your shared Slack or Teams channel, or email support@sealsecurity.io.

Question 18

What permissions do you need for my production environment?

Accepted Answer

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

Question 19

Do you support on-prem and air-gapped environments?

Accepted Answer

Yes. If your build hosts can't reach the internet directly, set up your JFrog Artifactory or Sonatype Nexus as a proxy to the Seal Artifact Server, so your builds only talk to your internal registry.

For fully air-gapped networks, download the sealed versions you need from the Seal Repository on a connected machine. Sealed packages are standard artifacts in the same format as the originals (.jar, .whl, .tgz, .rpm, .deb, .apk and so on), so you can install them directly or publish them to your internal artifact server (Nexus, Artifactory, or an internal npm, PyPI, Maven, apt, yum or apk repository). Nothing inside the isolated network needs to talk to Seal: no agent, CLI or token. Your Seal team lets you know when new sealed versions are released.

Question 20

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

Accepted Answer

If the choice were simply between always staying on the latest version or never upgrading, we wouldn't be having this conversation. 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.

For a deeper dive into why "new" isn't always better, check out our blog post: Vulnerability-Free Dependencies Beyond Version Chasing

Frequently asked questions