Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

In the fast-moving world of software supply chains, the discovery of a malicious version of a popular library often triggers a state of emergency. Traditional security tools take a reactive approach: they scan, they find a match, and they fail the build. But what happens if the malicious version was merged before it was flagged? What if it’s already running in your production containers? Or what if it’s being pulled dynamically across hundreds of different pipelines?

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. ‍

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.

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.

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.

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.

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".

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.

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.

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.