Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

The recent Zscaler breach has sparked significant attention in the cybersecurity community not just because of its impact, but also because of the complexity of the attack and the multiple claims of responsibility surrounding it. Here’s a breakdown of what happened, who’s claiming involvement, and what we can learn from the incident. This was not a direct hack of Zscaler’s core systems. Instead, it was a supply chain attack that exploited a third-party integration.

Fast-moving cloud environments demand speed, but without the right access controls they invite risk. Resources such as virtual machines, containers, and services are created, modified, and terminated at a rapid pace. At the same time, workloads are becoming increasingly distributed, with data and applications spanning multiple regions, accounts, and even across different cloud service providers (CSPs).

New Linux malware evades antivirus detection, UNC5518 deploys CORNFLAKE.V3 using ClickFix and fake CAPTCHA pages, and a PRC-Nexus campaign hijacks web traffic.

For years, the cybersecurity industry has hyped AI as a game-changer, but what vendors often delivered was basic machine learning driven or simple predefined rules. The rise of ChatGPT and similar tools dramatically reshaped the landscape, prompting vendors to hastily identify real AI use cases in their offerings.

The digital interdependence of today’s healthcare supply chain has created new systemic risks. Cybersecurity is no longer limited to internal systems, but vulnerabilities in the innumerable third-party suppliers can now expose entire networks to disruption. From patient records stored in the cloud to diagnostic tools and logistics platforms, every element is a potential entry point for attackers.

I'm going to show you how to build a Lambda Runtime API extension that automatically scans and redacts sensitive information from your function responses, without touching a single line of your existing function code.

An AI Bill of Materials (AIBOM) addresses this gap. It is a concise, living profile for every AI capability an organization can invoke—models, agents, SaaS features, plug‑ins, and APIs. Kept in a machine‑readable format, it serves as a practical record that can inform runtime decisions in a control plane. An AIBOM summarizes five things about each AI capability: who provides it, what it can do, what data it sees, where it runs, and how it should be treated.

This blog post may sound a bit personal. That’s because it is. It is also a long story, so you might want to grab yourself some coffee (or your favorite beverage).

These days it seems everyone is obsessed with MCP servers, me included. After studying the topic and building a few MCP servers myself, I have decided to share the knowledge I have gained with a series of blogs on MCP servers and their security implications.

In cybersecurity, the biggest lie we tell ourselves is that our systems are safe because we think they’re not reachable. Firewalls, policies, and cloud rules look good on paper, but attackers don’t read your policies and they don’t trust your intentions. They test. If you aren’t testing from the outside too, you’re not defending, you’re guessing. And in this game, guessing gets you breached.