Seal backports the security fix into the open-source version you already run. Same version line, same API, no code changes. Your scanner sees a fixed version.
| Obligation | Window it sets | What you are held to |
|---|---|---|
| PCI DSS v4.0.1 | One month | Requirement 6.3.3: critical security patches installed within one month of release. |
| DORA (EU) | Your policy | A documented patch and update process inside your ICT risk management framework. |
| NYDFS Part 500 | Your policy | Section 500.5: timely, risk-prioritised remediation of vulnerabilities. |
| SOX ITGC | Change control | Every change reviewed and approved. A version-preserving patch is the smallest change you can put in front of a CAB. |
The upgrade is the right long-term move. It is the wrong tool for a one-month clock. So the exception gets signed, carried forward, and read by the next examiner.
The patch arrives on the version line you already approved. You ship the fix now and schedule the upgrade on your own timeline, instead of the other way round.
Frontier AI models such as Anthropic's Claude Mythos find and exploit vulnerabilities faster than most human researchers. Expect more critical CVEs in your scanner, with working exploits close behind.
PCI DSS still gives you one month for a critical. A major-version upgrade still needs a full regression cycle. More findings means more signed exceptions.
Seal's remediation agent backports and verifies the fix on the exact version you run. Sealed packages ship before the CVE, and before a fixed version is released, so patching keeps pace with discovery.
The fix, without the migration. A sealed version is your exact version plus the security patch, 6.5 lines on average.
Seal ingests findings from Snyk, GitHub Advanced Security, Checkmarx, Wiz and Trivy. It does not replace them. It gives their critical and high findings a fix.
A sealed version is a distinct published artifact. It lands in your lockfile, SBOM and change history, so the finding closes with a dated change, not a carried exception.
Seal Security holds SOC 2 Type II and ISO 27001. Patches are delivered at build time, into the registry you already control.
No API changes means no regression cycle for a new major. It rides your next scheduled release, inside the window.
"Thanks to Seal's product, we swiftly addressed security vulnerabilities in our outdated code packages, saving us valuable time."
No. Seal does not make any organisation compliant, and this is not compliance or legal advice. Seal removes one blocker to meeting a patch-window control: the absence of a fix you can deploy while the clock is still running.
No. Seal ingests findings from the scanners you already run, such as Snyk, GitHub Advanced Security, Checkmarx, Wiz and Trivy, and supplies a patched version for them. Seal works at build time; it is not a runtime protection product.
No code changes. The sealed version keeps the same API as the version you run today, and your package manager resolves it like any other release.
Java, Python, JavaScript, C/C++, .NET, Go, PHP and Ruby libraries, plus Linux packages.
Sealed packages are ordinary published artifacts. The ones already in your registry stay there and keep working.
You pick a method per project. Most teams add the Seal CLI to CI: one step after the dependency install swaps vulnerable packages for their sealed versions, following sealing rules the security team sets in the Seal platform, so no pull requests are needed. You can also point your package manager, Artifactory or Nexus at the Seal Artifact Server and pin sealed versions in the manifest, or download sealed packages and install them yourself. Setup guides for each method are at docs.sealsecurity.io.
Yes. If your build hosts can't reach the internet, proxy the Seal Artifact Server through your Artifactory or Nexus, so builds only talk to your internal registry. For fully air-gapped networks, download the sealed packages on a connected machine and publish them to your internal registry. They are standard artifacts in the same format as the originals, so nothing inside the isolated network talks to Seal: no agent, CLI or token.
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 is ready before the CVE goes public, and before upstream releases a fixed version. In Seal's Silent Patch Gap research, 94% of CVEs had a public fix commit before the advisory, a median of 11 days earlier.