|
By Lev Pachmanov
Building a supply chain security company comes with an uncomfortable truth: our remediated packages run inside our customers' production environments. A compromise on our end is a compromise on theirs. We take that responsibility seriously. I want to pull back the curtain on how we actually secure our own supply chain - from the code we write, to the artifacts we deliver, to the infrastructure that holds it all together.
|
By Alon Navon
A definitive guide to how automated and human-reviewed patch-in-place remediation solves both direct and transitive open source vulnerabilities - without forcing risky upgrades. Learn why traditional tools miss transitive risk, and how to evaluate modern platforms based on SLA, provenance, and CI/CD fit.
|
By Itamar Sher
Open source made software development faster. It also made software delivery more fragile. Most teams already understand that dependencies can contain vulnerabilities. Fewer teams fully internalize the other half of the problem: dependencies can also change underneath them. When versions are not pinned, code from outside your organization can enter your build, CI pipeline, or runtime environment without a deliberate engineering decision. Your repo may be unchanged. Your app may be unchanged.
|
By Itamar Sher
Security teams can now eliminate container vulnerabilities at the source without developer effort or version upgrades. At Seal Security, we believe vulnerability management should start with secure foundations.That’s why we’re excited to share that Seal’s pre-patched packages to harden base and secure images are now officially integrated in Wiz. This partnership brings together Wiz’s best-in-class cloud visibility with Seal’s remediation-first approach to container security.
|
By Amit Agam
In the world of Software Composition Analysis (SCA), we often treat the tuple of (package_name, version) as a unique identifier. For example, given an NPM package angular version 1.8.0 - we would know precisely which source code was used, and what vulnerabilities affect that version.It is a common misconception that a package version maps directly to a fixed set of source code and, by extension, a static vulnerability profile.
|
By Lev Pachmanov
In the world of database security, few things are as alarming as an unauthenticated memory leak. It recalls the panic of OpenSSL’s Heartbleed - a vulnerability where a simple heartbeat request could bleed out sensitive secrets from a server's memory. Now, MongoDB users are facing their own version: CVE-2025-14847, widely dubbed "MongoBleed".
|
By Itamar Sher
Earlier this year, FedRAMP RFC-0012 signaled a coming shift in how cloud service providers (CSPs) working with the U.S. federal government are expected to handle vulnerabilities. It outlined plans to move FedRAMP away from simple CVSS-score thresholds and toward continuous, context-aware, exploitability-driven, and automation-first vulnerability management.
|
By Itamar Sher
On December 3rd, CVE-2025-55182 was published by CISA. This CVSS 10.0 vulnerability allows unauthenticated remote code execution, where a threat actor can exploit a flaw in React’s process to decode payloads sent to React Server Function endpoints. It is important to note that while not every team is using React Server Function endpoints in their app, they still may be vulnerable if their app supports React Server Components.
|
By Itamar Sher
Once again, the npm supply chain has been compromised, putting developers relying on these vital open source components at risk. On November 24th, a sophisticated attack that borrows techniques from the Shai-Hulud malware used in the npm hijacking this past September was discovered. This is not an isolated incident. It’s a continuation of an existing campaign that is now abusing CI/CD pipelines, and GitHub automation to spread faster and steal more secrets than before.
|
By Alon Navon
We are excited to announce a new wave of updates designed to streamline your development process, enhance security auditability, and dramatically improve platform performance. At Seal Security, our focus remains on giving you the easiest and most effective way to manage and remediate open source vulnerabilities. Your feedback drives our innovation, and we're thrilled to introduce capabilities that make the platform faster, cleaner, and more compliant.
|
By Seal Security
30% of open source vulnerabilities are marked “unfixable”. Not because they can’t be fixed but because traditional tools stop there. Your customers don’t care. They just see unresolved CVEs. And they won’t sign off on software that fails a scan. That’s where the real business risk lies. In mid-size software companies, “unfixable” means delayed deals, failed audits, and lost revenue. Seal Security was built to close that 30% gap.
|
By Seal Security
Automatic updates were supposed to make us safer. Instead, they’ve become one of the easiest entry points for supply-chain attacks. When a public repository is compromised, an attacker uploads a malicious version and waits, for 30 minutes to a few hours, before the community detects and removes it. During that window, automated tools like Dependabot can pull that version straight into production. That small window of time is enough to compromise thousands of systems.
|
By Seal Security
Most teams think vulnerability scanning equals progress. But scanning without effective remediation is just expensive noise. Two things block real fixes: Meanwhile, our own research shows as much as 30% of vulnerabilities in transitive dependencies remain unresolved, simply because upgrades break production. That means most organizations aren’t “secure”. They’re sitting on unfixed issues their scanners excluded.
|
By Seal Security
Watch the demo to discover how Seal Security and Snyk offer a unified, efficient solution for delivering open source security patches. See how their partnership ensures seamless, predictable remediation of open source vulnerabilities across both application code and container images.
|
By Seal Security
Watch a overview of Seal Security's integration with Github and learn how Seal Security empowers organizations to adopt a "secure by default" approach to open source software. Our unique technology decouples the security patching process from regular updates, enabling organizations to automate the remediation of vulnerabilities in both application code and images seamlessly within their SDLC. For more information contact us a info@sealsecurity.io or request a demo at seal.security/book-a-demo.
|
By Seal Security
Watch a demo of Seal Security to learn how our solution enables security teams to automate and scale their vulnerability remediation. We provide organizations centralized control over the vulnerability patching process, without requiring involvement from R&D, reducing the MTTR from months to hours. for more information contact us a info@sealsecurity.io or request a demo at seal.security/book-a-demo.
|
By Seal Security
In this white paper we conducted extensive research on how organizations manage their open source vulnerabilities. This white paper explores the challenges and limitations they encounter, as well as the available solutions.
- April 2026 (2)
- March 2026 (1)
- January 2026 (2)
- December 2025 (6)
- November 2025 (5)
- April 2025 (1)
- March 2025 (3)
- February 2025 (2)
- January 2025 (1)
- December 2024 (3)
- August 2024 (1)
- June 2024 (1)
- May 2024 (1)
- February 2024 (1)
- January 2024 (1)
- December 2023 (1)
- August 2023 (1)
Seal Security provides standalone security patches that are fully compatible with existing versions of open source packages, ensuring seamless and predictable fixes for vulnerabilities in both application code and Linux operating systems.
Eliminate all your open source risks with one unified solution:
- Secure open source vulnerabilities without impacting your development: Strengthen your supply chain with patches for both direct and transitive dependencies.
- Secure containers and base images: Secure your existing images without upgrading—even if you're running older distributions.
- Secure end-of-life code: Receive security patches post-EOL for platforms like CentOS and RHEL 6, and continue to meet compliance standards.
- Secure legacy and hard-to-manage code: Streamline the process of fixing security issues in old or legacy code. Address vulnerabilities in difficult-to-patch applications—even those outside your control.
- Uphold compliance and meet customer SLAs: Maintain vulnerability-free images to ensure you meet your customers' SLA requirements and successfully pass any security audit, including FedRAMP, PCI DSS 4.0, and NYDFS 500.
We fix all open source vulnerabilities so you don’t have to.