In the first episode of our STRIVE series on digital sovereignty, Commvault’s Alex Zinin and Osmium Data Group’s Max Mortillaro challenged one of the biggest misconceptions in the industry: Digital sovereignty isn’t a feature you buy – it’s a business problem you have to understand before you can solve.

This conversation picks up where that one left off. This time, I sat down with Thomas Maurer, EMEA Global Black Belt for Sovereign Cloud at Microsoft, to explore what happens after an organization decides sovereignty matters. How do executive teams move from broad concerns about regulation, jurisdiction, or geopolitical uncertainty into practical architectural decisions?

The answer, it turns out, is rarely as straightforward as choosing a cloud provider or selecting the right deployment model. It’s about asking better questions before making technical decisions.

Watch the full episode.

Key Takeaways

• Every organization defines digital sovereignty differently – and that’s exactly where the conversation should begin.
• Sovereignty isn’t solved by technology alone. Legal, operational, architectural, and business considerations all shape the outcome.
• Cloud and on-premises aren’t competing strategies. For many organizations, the future is a carefully designed combination of both.
• Risk management – not fear – should drive sovereignty decisions.
• Good architecture starts with understanding business requirements, not choosing infrastructure.

Sovereignty Means Different Things to Different Organizations

One of the first observations Thomas made was also one of the most important.

There is no universal definition for digital sovereignty. For one organization, it may simply mean meeting regulatory requirements or keeping data within a specific geography. For another, it may involve operational independence, business continuity, or preparing for geopolitical disruption. That difference matters because it changes the conversation entirely.

Too often, organizations assume there’s a standard sovereignty blueprint waiting to be implemented. In reality, the first challenge isn’t selecting technology – it’s understanding what problem the organization is actually trying to solve.

Only then does architecture begin to make sense.

Technology Should Follow Strategy

One theme that kept surfacing throughout our discussion was the temptation to jump straight into technical design.

It’s understandable. Architects naturally think about infrastructure, workloads, connectivity, and deployment models. But Thomas emphasized that the most successful projects begin somewhere else.

They begin by listening.

What concerns are driving the initiative? Is the objective regulatory compliance? Business continuity? Data residency? Operational control? Protection against geopolitical disruption?

Different answers lead to different architectures.

That may sound obvious, but it’s surprising how often organizations begin evaluating solutions before they’ve aligned on the business outcome they’re trying to achieve.

Sneak Peek: Start With Risk, Not Assumptions

One of the most practical moments in our conversation comes when Thomas and I discuss why sovereignty initiatives should begin with a risk assessment – not an architectural diagram.

Every organization has a different risk appetite. A Formula 1 team, a government agency, and a global manufacturer won’t make the same decisions, nor should they. The key is understanding which risks matter most to your business, what trade-offs you’re willing to make, and then designing an architecture that supports those decisions.

As Thomas points out, there is no perfect solution – only informed trade-offs. The earlier organizations adopt that mindset, the stronger their sovereignty strategy will be.

‘Cloud or On-Premises?’ Is the Wrong Question to Ask

One of the more interesting parts of the conversation challenged another common assumption – that organizations must choose between public cloud and private infrastructure.

Thomas described a very different reality.

Many organizations aren’t replacing one with the other. They’re designing environments where workloads can move between them based on business need, regulatory requirements, or resilience considerations.

That flexibility changes how we should think about architecture. Instead of asking whether cloud or on-premises is better, the more useful question becomes:

“Where does this workload belong today – and could that answer change tomorrow?”

When sovereignty becomes part of the design process, workload mobility becomes just as important as workload placement.

Architecture Is Only Part of the Equation

Another takeaway I appreciate is Thomas’s reminder that architecture alone doesn’t solve sovereignty.

• Contracts matter.
• Legal frameworks matter.
• Operational processes matter.
• The people responsible for running the environment matter.

None of those disciplines can operate in isolation. Sovereignty requires legal, security, compliance, and infrastructure teams to work together from the beginning – not hand projects off to one another after decisions have already been made.

That’s a familiar pattern for anyone working in cyber resilience. The strongest outcomes rarely come from individual teams. They come from coordinated ones.

Risk Should Drive Every Decision

Toward the end of our discussion, the conversation naturally shifted toward risk. For me, this is where sovereignty starts to feel much more familiar. Every resilience project begins by asking what the organization is trying to protect, what threats matter most, and how much risk it’s willing to accept.

Digital sovereignty is no different.

Rather than searching for a perfect solution, organizations need to identify the specific sovereignty scenarios they’re concerned about and then determine which architectural, operational, or contractual controls best address those risks.

That shift – from feature comparison to risk management – is what ultimately leads to better decisions.

Why This Conversation Matters

Digital sovereignty continues to evolve rapidly. New regulations will emerge. Technology will change. Geopolitical realities will continue to shift.

That means sovereignty isn’t something organizations solve once. It’s something they regularly evaluate as business priorities and external risks evolve.

The organizations that succeed won’t necessarily have the most restrictive architectures. They’ll have the clearest understanding of their business objectives, the discipline to assess risk thoughtfully, and the flexibility to adapt as those risks change.

Ultimately, digital sovereignty isn’t something organizations can buy off a shelf. It’s an exercise in understanding risk, managing dependencies, and making informed trade-offs long before those decisions are tested.

Watch the Full Episode

In this STRIVE episode, Thomas and I discuss:

• Why sovereignty means different things to different organizations.
• How executives should approach sovereignty strategy.
• Public cloud versus private cloud – and why it’s often not an either/or decision.
• Why risk management should guide architectural choices.
• The role of resilience in modern sovereignty planning.

Watch now.

FAQs

Q: Does digital sovereignty mean keeping everything on-premises?

A: No. Many organizations adopt hybrid approaches that balance cloud capabilities with specific sovereignty requirements.

Q: Where should sovereignty projects begin?

A: Start by defining the business problem and understanding the risks you’re trying to mitigate before evaluating technology.

Q: Is sovereignty purely a technical issue?

A: No. It requires collaboration between legal, compliance, security, operations, and architecture teams.

Q: How does sovereignty relate to resilience?

A: Both disciplines focus on maintaining operational continuity by reducing exposure to risks that could disrupt the business.

Q: What’s one big mistake organizations make in regard to digital sovereignty?

A: Jumping into architectural decisions before agreeing on what sovereignty means for their organization.

Q: What should executives ask first in terms of planning for digital sovereignty?

A: “What problem are we trying to solve?” Everything else follows from that answer.

Darren Thomson is Vice President and Chief Technology Officer, EMEA, at Commvault.

For years, cyber resilience has been defined by technology – security controls, sophisticated detection capabilities, and increasingly robust backup strategies designed to prevent attacks or recover more quickly. Those investments remain essential, but they are no longer enough. 

AI has fundamentally changed the nature of cyberattacks, which now move at a speed that challenges even mature organizations. As the window between compromise and business disruption continues to shrink, resilience is becoming less about preventing every attack and more about keeping the enterprise running when prevention inevitably falls short. 

That shift is at the heart of IDC’s new report, Resilience Operations: The Discipline that Makes Readiness Provable. Based on a survey of more than 500 North American organizations, the report argues that resilience is evolving into a cross-functional operating discipline that connects business priorities with cybersecurity, ITOps, and disaster recovery. More importantly, it reveals several gaps that suggest many organizations are still preparing for a threat landscape that no longer exists. 

Here are the insights that stood out. 

Recovery should begin with business outcomes – not technical ones.

Historically, recovery planning has focused on restoring infrastructure as quickly as possible, with success judged by recovery time objectives, backup completion rates, and application availability. While those measures remain valuable, they don’t necessarily answer the question executives care about most: When can we get the business back online? 

IDC argues that resilience should be anchored to business outcomes rather than technical milestones – restoring the capabilities that allow the organization to serve customers, generate revenue, and meet its obligations. That may sound like semantics, but it changes how recovery priorities are established. Technology becomes the means to an end rather than the end itself. 

Most organizations still haven’t defined what matters most.

Nearly 6 in 10 organizations have not fully defined their minimum viable business (MVB) – the smallest set of functions, systems, processes, and data required to continue operating after a disruption. 

Without a shared understanding of what the business truly depends on, every movement during recovery becomes reactive. By defining your MVB before a crisis, you’ll enable faster decisions, better coordination during recovery, and ultimately a more resilient organization. 

Automation is becoming the dividing line between resilience and recovery debt.

While attackers increasingly automate reconnaissance, exploitation, and lateral movement, many organizations still rely on manual recovery processes. 

That imbalance is becoming increasingly difficult to ignore. AI is compressing attack timelines, but recovery timelines have not kept pace. Organizations that fail to automate these recovery tasks may find themselves spending days assembling and executing plans while the damage has already been done. 

Automated recovery orchestration, clean recovery point identification, and coordinated validation are becoming foundational capabilities for recovering at the speed modern attacks demand. 

Technology isn’t the biggest resilience challenge – organizational alignment is.

Security teams focus on containment, infrastructure teams focus on restoration, business leaders focus on customer impact, and compliance teams focus on regulatory obligations. None of these priorities are inherently wrong, but when they evolve independently, organizations enter a crisis without a shared operating model. 

Enter ResOps. Rather than positioning resilience as an IT responsibility, the report frames it as a discipline that deliberately brings together business, security, infrastructure, and recovery planning. The message is clear: Resilience depends less on individual tools than on creating shared priorities before an incident forces you to make difficult decisions. 

Testing remains one of the strongest indicators of resilience.

IDC found that relatively few organizations conduct frequent tabletop exercises or cyber-range simulations, despite decades of evidence showing that rehearsal consistently improves performance during real incidents. 

Exercises reveal hidden dependencies, expose communication gaps, and allow teams to make decisions without the real consequences. Organizations that repeatedly validate their recovery processes develop a level of confidence beyond planning alone. 

Tomorrow’s resilience challenges are already taking shape.

Ransomware still dominates headlines, but the next resilience challenges have already emerged – from agentic AI and machine identities to post-quantum cryptography. 

These threats remind us that resilience planning can’t focus exclusively on today’s infrastructure. Recovery increasingly involves cloud services, SaaS applications, AI models, machine identities, third-party providers, and distributed digital ecosystems that didn’t exist a decade ago. 

Resilience is becoming measurable.

IDC’s ResOps Maturity Model is invaluable for assessing your organization’s current posture. Rather than treating resilience as something organizations either possess or lack, the framework describes a progression from reactive, siloed operations to mature, adaptive resilience built on governance, automation, and continuous improvement. 

To me, that progression acknowledges an important reality: Resilience is never finished. It’s not about purchasing a platform or completing a project. Organizations become resilient by continually improving how technology, people, and business processes work together under pressure. 

Viewed through that lens, resilience becomes less like insurance and more like operational excellence – a capability that can be assessed, strengthened, and demonstrated over time. 

We’re undergoing a broader shift in how organizations think about resilience.

Resilience conversations are evolving from protecting infrastructure to protecting the business itself. That means recovery planning starts with customers instead of servers, governance becomes as important as technology, and confidence comes from proving capabilities rather than documenting intentions. 

ResOps isn’t really a new framework; rather, it’s a broader recognition that cyber resilience has become an operational discipline. As attacks become faster and more complex, resilience will be measured not by the absence of incidents, but by an organization’s ability to continue serving customers, supporting employees, and maintaining trust despite disruption. 

That’s ultimately what ResOps is designed to prove. 

Rajiv Kottomtharayil is Chief Products Officer at Commvault. 

Key Takeaways

• Trust in the age of AI isn’t disappearing – it’s evolving.
• Organizations need to verify AI continuously rather than trust it by default.
• AI adoption should empower employees, not push them toward shadow AI.
• Zero trust isn’t about distrusting people. It’s about continuously validating identities, devices, and actions.
• Responsible AI adoption requires technology, governance, and people working together.

When we launched Ready. Or Not., we wanted to create a series that made some of today’s biggest AI conversations easier to understand. By pairing comedian Nathan Macintosh with industry experts, we’re exploring everything from agentic AI and cyber resilience to data management – and adding a little humor along the way.

If you caught our first episode on the opportunities and risks of agentic AI, I think you’ll enjoy this one as well. This time, we’re tackling a topic that’s at the center of every AI conversation: trust.

Nathan sits down with Diana Kelley, Chief Information Security Officer at Protect AI, for a conversation about what it means to trust technology when AI can generate convincing fake content, make decisions, and even imitate people. From deepfakes and hallucinations to zero trust and shadow AI, they explore how organizations can embrace AI without losing confidence in their people and systems.

Watch the full episode on Readiverse.

I walked away from this episode feeling more optimistic than I expected. Not because AI is suddenly more trustworthy, but because Diana shows us that trust grows when organizations put the right policies, guardrails, and technology in place. Here are some themes from the conversation that put AI in a new perspective.

Trust and Technology Can Co-Exist

Diana believes trust is possible in the AI era, but it’s going to look different. We’ve always built trust through relationships with people. Now, we’re learning how to extend that trust to systems.

That doesn’t mean trusting technology blindly. It means understanding how AI works, recognizing its limitations, and putting the right safeguards in place so people and technology can work together with confidence.

“Trust has to evolve for the new world.”

– Diana Kelley

What resonated with me was the idea that trust and technology don’t have to be at odds with one another. With the right approach, they can strengthen each other.

We’re Getting Smarter About AI

Deepfakes have become one of the most talked about AI risks, and it’s easy to understand why. AI can now generate convincing voices, images, and videos that make us question what’s real. But Diana pointed out that while AI is getting more sophisticated, people are getting smarter. We’re more likely to question an unexpected phone call, take a closer look at a social media post, or pause at something that doesn’t feel quite right.

Organizations are becoming savvier, too. As AI gets better at impersonation, businesses are investing in new ways to continuously verify identities and validate information. My takeaway is this: Technology will continue to improve, but so will our ability to recognize it and respond responsibly.

“Is today a good day to start a deepfake?”

– Nathan Macintosh

Responsible AI is Good for Business

Diana shared an example that will probably sound familiar to many organizations. An employee she calls “Karen in Finance” starts using AI because it helps her complete a task in minutes instead of hours. Karen isn’t trying to work around company policy – she’s trying to be more productive.

Employees use AI because they see real value in it, and that’s an opportunity for organizations. When employees have access to approved AI tools, supported by clear policies and practical guidance, they can work more efficiently while helping protect company data and systems.

Sneak Peek: Smarter AI Adoption

The goal isn’t to stop employees from using AI. It’s to make sure they’re using it the right way. Diana explains how organizations can encourage AI adoption without creating unnecessary risk.

Zero Trust Matters More Than Ever

“When you understand how things work, then you can start to understand how to manage them.”

– Diana Kelley

Zero trust is one of those concepts that’s much easier to understand with an analogy. Diana has a great one. She describes it as moving through a building. Just because you’ve been allowed through the front door doesn’t mean every other door automatically opens for you. Each time you access a new room, there’s another quick check to confirm you’re supposed to be there.

That’s essentially how zero trust works. Instead of assuming a person or device is trustworthy after a single login, organizations continuously verify identities, devices, and actions as technology becomes more connected. Most of those checks happen quietly behind the scenes.

One of the things I appreciated about Diana’s explanation is that zero trust doesn’t feel like another security buzzword. It feels like a practical way to think about trust in a world where AI and digital identities are becoming part of everyday business.

Trust Is About People

At the end of the day, technology doesn’t create trust – people do. People define the policies, processes, and ethical boundaries that guide how AI is used, while technology helps verify that those guardrails are working as intended. It’s that partnership between people and technology that makes responsible AI possible.

Trust extends beyond our own organizations. Businesses need confidence in the partners they work with, the systems they connect to, and the technologies they adopt. That’s why transparency, shared standards, and continuous verification are becoming just as important as innovation itself. The more AI becomes part of everyday business, the more trust becomes everyone’s responsibility.

Looking Ahead

AI will continue to evolve, and so will the way we interact with it. The organizations that succeed won’t be the ones that trust AI blindly or avoid it altogether. They’ll be the ones that build strong policies, adopt the right technologies, and continuously verify the systems they rely on.

Trust isn’t something we lose as technology advances. It’s something we intentionally build and evolve. That’s exactly the kind of conversation we hope to continue with every episode of Ready. Or Not.

Watch the full episode on Readiverse.

FAQs

Q: What is digital trust?

A: Digital trust is the confidence that people, systems, and organizations are who they claim to be and are acting in expected, secure ways. It combines technology, governance, and verification to help organizations interact safely.

Q: What are deepfakes?

A: Deepfakes are AI-generated images, videos, or audio recordings designed to closely imitate real people. While they have legitimate uses, they can also be used to impersonate individuals or commit fraud.

Q: What is zero trust?

A: Zero trust is a security model based on continuous verification rather than automatic trust. Instead of assuming a user or device is trustworthy after one login, organizations continuously validate identities and actions.

Q: What is shadow AI?

A: Shadow AI refers to employees using AI tools that haven’t been approved or governed by their organization. While often well-intentioned, it can introduce security, privacy, and compliance risks.

Q: Why shouldn’t organizations simply block AI tools?

A: Employees typically adopt AI because it helps them work more efficiently. Rather than banning AI outright, organizations should provide approved tools, establish clear policies, and educate employees on responsible use.

Q: What’s the biggest takeaway from this episode?

A: Trust isn’t disappearing because of AI – it’s evolving. Organizations that combine people, policies, and technology with continuous verification will be better positioned to adopt AI confidently and responsibly.

Katherine Demacopoulos is Senior Director of Global Content Strategy and Programs at Commvault.

Our Chief Products Officer, Rajiv Kottomtharayil, recently wrote about a big shift that is taking place across industries. Frontier AI models are compressing the time between vulnerability discovery and exploitation.  

This shift is prompting organizations everywhere to re-examine their vulnerability management processes. We’re doing the same at Commvault. That’s why, starting August 11, we’re changing the rhythm of how we disclose vulnerabilities.  

What’s Changing

We are raising the bar for security, transparency, and customer trust. On August 11, and on the second Tuesday of each month after that, we’re introducing Patch Tuesdays: a scheduled monthly release where we share security advisories and vulnerability patches.  

Patch Tuesdays are a hallmark of leading technology companies, because they provide customers with a predictable security rhythm.  This matters even more as the pace of vulnerability discovery accelerates. Of course, if there is an urgent vulnerability that must be reported off cycle, we will not hesitate to follow our well-established processes.  

Where You Can Find Up-to-Date Resources  

On the second Tuesday of each month, you’ll find new information pertaining to CVEs on our Security Advisories page. You also can find the official publications at MITRE’s CVE site. 

On the Commvault Security Center, you’ll find our vulnerability management program and other security-by-design thought leadership.   

For compliance certifications, audit reports, and documentation on how Commvault protects customer data, visit the Commvault Trust Center. You can subscribe to updates from the Trust Center at the link in the upper righthand corner of the page. 

Bill O’Connell is Chief  Security Officer at Commvault. 

For decades, technology leaders have been trying to eliminate silos. Entire modernization programs have been built around connecting applications, consolidating platforms, and giving organizations a more complete view of their data.

Those efforts have delivered enormous value, but they also have shaped the way we think about resilience. When something goes wrong, we instinctively look for technical fragmentation. However, we’ve found the greater challenge lies elsewhere.

The most significant silos affecting cyber resilience today aren’t found in databases or applications but in organizational structures. They exist between security and infrastructure teams, between IT and the business, and between the people responsible for responding to an attack and those responsible for keeping the organization operating.

IDC’s latest research on ResOps, Resilience Operations: The Discipline that Makes Readiness Provable, suggests these organizational boundaries have become one of the defining obstacles to effective recovery. That’s a timely observation because cyberattacks have evolved in ways that can make those boundaries increasingly difficult to maintain.

Modern Attacks Don’t Follow Your Org Chart

A modern cyberattack rarely affects a single technology domain. A ransomware incident might begin with compromised identities, spread through cloud infrastructure, encrypt critical workloads, disrupt customer-facing applications, impact third-party services, and trigger regulatory reporting requirements – all within a matter of hours. Every stage involves different teams, different tools, and different priorities.

Yet many organizations still prepare for recovery as though these responsibilities can be managed independently.

Security teams naturally focus on containing threats and preserving evidence. Infrastructure teams prioritize restoring systems and minimizing downtime. Business leaders concentrate on customers, revenue, and operational continuity. Communications teams think about reputation, while legal and compliance teams focus on regulatory obligations.

Each perspective is entirely reasonable. The problem arises when those priorities have never been reconciled before an incident occurs.

In the middle of a crisis, recovery requires decision-making under pressure. Which applications should return first? Which data can safely be restored? How much risk is acceptable before customer services resume? Who has the authority to make those decisions?

Without alignment, organizations often discover that the greatest delays aren’t caused by technology but by uncertainty – the kind that could be mitigated by better preparation.

Resilience Begins with a Shared Definition of What Matters

The report places emphasis on establishing your minimum viable business (MVB). At first glance, it appears to be another recovery planning exercise, but its real value lies in the conversations it forces organizations to have.

Defining an MVB requires business leaders, security teams, infrastructure specialists, and application owners to agree on a deceptively simple question: What absolutely must continue operating if everything else stops?

That discussion changes the nature of resilience planning. Recovery priorities are no longer determined by whichever application owner argues most convincingly during an incident. Instead, they are established in advance, grounded in business outcomes, and supported by technical dependencies that everyone understands.

Perhaps more importantly, MVB creates a common language. Business leaders begin talking about critical capabilities rather than individual systems. Technology teams begin mapping infrastructure to customer outcomes rather than technical architectures. Security teams gain greater clarity about which assets deserve the highest levels of protection during recovery.

That shared understanding is precisely what many organizations have been missing.

Technology Can Automate Recovery – But it Can’t Create Alignment

The report doesn’t argue that organizations need yet another platform. It argues they need a way of working that aligns people, processes, and technology around a single operational objective. This is where ResOps – a cross-functional discipline – proves its mettle.

Technology can help automate recovery, but it cannot resolve disagreements about business priorities. It cannot decide which customer services matter most. And it cannot replace the governance needed to coordinate multiple teams during a high-pressure event.

Those are leadership challenges, and they are best addressed by investing time in answering the difficult questions together, long before an attack forces your hand.

The Strongest Organizations Don’t Eliminate Silos – They Connect Them

Cyberattacks will continue evolving. AI will continue compressing attack timelines. New technologies will introduce new dependencies, and new threats will emerge alongside them. None of that changes the fundamental requirement for resilience.

Organizations don’t recover because individual teams perform brilliantly in isolation, but because those teams already know how to work together.

That may ultimately be the most important insight from IDC’s research. Resilience isn’t simply the product of better technology or more sophisticated security controls. It is the result of shared priorities, clear governance, and a tested operating model that brings the right people together before an incident occurs.

Vidya Shankaran is Field CTO at Commvault.

Key Takeaways

• A CVE is a globally unique identifier for a publicly disclosed software vulnerability, enabling vendors, researchers, and defenders to reference the same consistently.
• An organization’s approach to vulnerability disclosure – including coordinated fixes, researcher engagement, and accurate software inventory – is a strong indicator of overall security maturity.
• Commvault protects its customers with a CVE program of transparency, cadence, and clarity. CVE disclosure says a great deal about the maturity of a security and engineering program.

Why This Matters

Many breaches that reach the boardroom trace back to vulnerability in software. The mechanism the entire industry uses to name and describe those vulnerabilities is the CVE, Common Vulnerabilities and Exposures.

How a vendor, or your own organization, handles CVEs is one of the clearest signals of security maturity.

A company that discloses and credits researchers fairly is usually a company that takes underlying engineering seriously. This blog explains how a CVE is built, who runs the system, and what separates an exemplary disclosure from a poor one.

Beyond the CVE: Why Disclosure Philosophy Matters

Publishing a CVE is table stakes. The differentiators are: transparency of the vulnerability and patch, regular scans and patching, and clear communication.

Commvault treats disclosure as an engineering and security discipline rather than a compliance checkbox: Establish a cadence for code review and remediation, communicate the fix in plain language, and protect our customers. That consistency, more than any single score, is what CVE disclosure says about security maturity.

What a CVE Actually Is

A CVE is not a patch, a score, or a piece of malware. It is a dictionary entry that gives one specific, publicly known vulnerability a permanent, unique name so that everyone can refer to it.

The identifier itself follows a simple, durable format: the letters CVE, the year the ID was assigned, and a sequence number, for example, CVE-2021-44228.

The scale of the program is enormous, and still growing: 48,000 CVEs were published in 2025, on the order of 132 per day, up more than 260% since 2020.

The Anatomy of a Single Record

CVE publications require a consistent set of elements. Reading one is straightforward once you know what each part is for:

• Identifier, the unique CVE-YYYY-NNNNN
• Description, a concise explanation of the vulnerability: what it is and how a threat actor could exploit it.
• Affected products and versions, which software, hardware, or firmware (and which versions) are impacted, and which versions contain the fix.
• Criticality, the underlying category of criticality.
• References, links to the vendor advisory, the patch, and technical write-ups.

The Supporting Cast: CVSS, CWE, EPSS, and KEV

Four companion systems turn a CVE into something a business can prioritize. They are easy to confuse, so the distinction is worth holding onto:

• CVSS (Common Vulnerability Scoring System) answers “How severe is it?” CVSS is the severity rating (1–10, 10 being the most severe) of the flaw, not a measurement of your specific exposure.
• EPSS (Exploit Prediction Scoring System) answers “How likely is this to be exploited soon?” EPSS produces a probability score, from zero to 100 percent, estimating the likelihood that a vulnerability will be exploited in the next 30 days.
• CWE (Common Weakness Enumeration) answers “What kind of mistake caused it?” The CWE classifies the underlying coding weakness.
• KEV (Known Exploited Vulnerabilities) answers “Is it being used against people right now?” The KEV catalog is a curated list of CVEs with confirmed real-world exploitation.

A high CVSS score tells you how serious a vulnerability could be, a high EPSS score tells you how soon it is likely to be exploited, and a listing in the KEV catalog confirms exploitation is already happening. The best vulnerability programs weigh all three.

FAQs

Q: What is a CVE, and why is it important?
A: A Common Vulnerability and Exposure (CVE) is a standardized identifier assigned to a publicly disclosed software vulnerability. It enables everyone – from vendors and researchers to regulators and customers – to refer to the same vulnerability without ambiguity.

Q: What information should a well-formed CVE record contain?
A: A complete CVE record requires a unique identifier, a description of the vulnerability, affected products and versions, the criticality type, and references to vendor advisories or patches. These elements enable organizations to understand their exposure and respond efficiently.

Q: How do CVSS, CWE, EPSS, and KEV differ from a CVE?
A: A CVE identifies a specific vulnerability, while CVSS measures its severity, EPSS estimates the likelihood of near-term exploitation, CWE classifies the underlying coding weakness, and KEV identifies vulnerabilities that are actively exploited in the real world. Together, these frameworks help provide the context needed to prioritize remediation.

Q: What does Commvault look for in its own disclosure practices?
A: Commvault holds its own disclosures to the same standard it expects of others: transparency, cadence and clarity. That is how Commvault protects its customers.

Q: What should business leaders evaluate when assessing vendors’ vulnerability management practices?
A: Leaders should look for coordinated disclosure timelines, comprehensive and accurate CVE records, clear remediation guidance, robust reporting programs, and the ability to quickly determine whether products are affected by newly disclosed vulnerabilities. These characteristics reflect a strong security culture and improve organizational resilience.

Werner Nel is Principal Product Experience Manager at Commvault.

Key Takeaways

• JadePuffer is the name security researchers at Sysdig gave to what they assessed as the first documented ransomware operation driven end-to-end by an autonomous AI agent, not a human working through a toolkit.
• The individual techniques weren’t new. What changed was orchestration speed: The agent chained reconnaissance, credential theft, lateral movement, and destructive encryption, correcting a failed login attempt in 31 seconds.
• The agent generated its own encryption key, then never stored or transmitted it. Paying the ransom would not have restored the data.
• The real damage targeted configuration state and control-plane systems, not just files, which is exactly the layer most recovery plans don’t cover.
• Recovering from an attack like this means proving the business can safely resume operations, not just restoring a backup.

What Happened

In mid-2026, security researchers at Sysdig documented an extortion campaign they believe is the first of its kind: a ransomware operation carried out end-to-end by a large language model agent, with minimal human hands-on-keyboard involvement. They named it JadePuffer.

The entry point was familiar. The attacker exploited CVE-2025-3248, an unauthenticated remote code execution flaw in Langflow, an open source framework for building AI agent workflows, running a version older than 1.3.0. From there, the agent enumerated the host, searched for credentials across cloud providers, AI model vendors, and databases, and quietly dumped the platform’s own backing database.

What happened next is the part worth paying attention to. The agent scanned the internal network, found an exposed object store, and pulled Terraform state and configuration files. It set up a scheduled task to call home every 30 minutes. Then it pivoted to a separate production system running MySQL and Alibaba Nacos, a configuration and service-discovery platform common in microservice architectures.

Once inside, the agent tried to create an administrator account in Nacos. It failed. Thirty-one seconds later, it had diagnosed the failure and succeeded with a different approach. It then used MySQL’s file-handling functions to probe whether it could escalate further, before encrypting more than 1,300 configuration records, dropping the original tables, and leaving a ransom note behind.

The encryption key was generated on the fly, displayed once, and never stored anywhere the attacker could retrieve it again. Whether or not that was intentional, the outcome for the victim is the same: There was no path back through the attacker or a decryption key, ransom paid or not. Recovery would depend on clean backups, rebuild, or validated recovery points.

Why Researchers Are Calling This “Agentic”

None of the individual techniques here are new. Exploiting an unpatched CVE, harvesting credentials, scanning for lateral movement, encrypting data for extortion: Security teams have seen every one of these before. What made Sysdig classify the operator as agentic rather than a conventional attacker is how the steps fit together.

The agent didn’t run a fixed script. It observed results and adjusted. When it expected a JSON response and got XML back, it changed its approach and kept going. When its first attempt to create an admin account failed, it diagnosed the specific failure and tried something different, in under a minute.

Researchers also found comments embedded in the payloads, explaining targets and next steps in simple language, a pattern more consistent with an LLM reasoning through a task than a human copying and pasting a known exploit kit.

Public reporting hasn’t confirmed which model or platform powered the attack. What’s confirmed is the behavior: Something reasoned, acted, hit a wall, and corrected course faster than most human-paced incident response can move.

The Recovery Problem Too Many Frameworks Still Miss

Most ransomware playbooks are built around a specific assumption: something encrypted your files, and the question is whether you can restore a clean backup or need to negotiate a decryption key.

JadePuffer breaks that assumption in two ways. First, there was no decryption key to negotiate for. Second, the damage wasn’t only in the data. It was in the configuration and control-plane layer underneath the data: the service-discovery platform, the secrets it held, the Terraform state describing how the infrastructure fit together, and the credentials scattered across every system the agent touched on the way there.

That’s a harder recovery problem than “restore the database.” A clean file restore into an environment with rotated-but-not-verified credentials, unreviewed configuration drift, and an identity layer nobody has re-audited isn’t really a clean recovery. It’s a fresh copy of the data sitting inside a system that still can’t be trusted.

What This Means for Your Resilience Strategy

JadePuffer is a preview of the question every recovery plan will eventually have to answer: Can you resume operations when an attacker has touched not just your data, but the identity, configuration, and control-plane systems that data depends on?

A few places to start:

Treat configuration and control-plane systems as recovery-critical, not just applications. Service discovery platforms, secrets stores, and infrastructure-as-code state are as business-critical as the databases they configure. If they aren’t in your recovery plan today, that’s the first gap to close.

Build credential hygiene into recovery, not after it. Restoring a workload that reintroduces compromised secrets doesn’t end the incident; it resets the clock on it. This is the same discipline Commvault applies to identity infrastructure today: vulnerability assessment to see exposure before an attacker does, real-time auditing to catch changes as they happen, and rollback to undo unauthorized changes without rebuilding from scratch.

Validate before you restore, not after. A restore point is only useful if you know it’s clean. That’s the logic behind Commvault® Cleanroom™: testing and validating data in an isolated environment before it ever touches production again, rather than finding out after reinfection.

Plan for a control-plane compromise, not just a file-encryption event. A recovery journey map built only for “encrypted files, restore from backup” won’t hold up against an incident like this. The more useful question, and the one at the center of ResOps (resilience operations) as an operating discipline, is what it takes to reach minimum viable operations when the systems underneath your applications are the ones that got hit.

None of this requires treating agentic AI as an unprecedented threat that demands starting from zero. It requires extending the same resilience discipline that already applies to identity and data, down into the configuration and control-plane layer that agentic attacks are now targeting directly.

Learn more about how Commvault approaches identity resilience and clean recovery validation.

FAQs

Q: What is JadePuffer?

A: JadePuffer is the name Sysdig gave to what it assessed as the first documented ransomware campaign driven end-to-end by an autonomous AI agent, rather than a human attacker manually operating a toolkit.

Q: Did the attackers use a specific AI model, like ChatGPT or Claude?

A: Public reporting hasn’t confirmed which model or platform was used. The agent searched for API keys from multiple AI providers, which shows interest in that kind of access, but doesn’t identify what powered the attack itself.

Q: How did the attack start?

A: Through CVE-2025-3248, an unauthenticated remote code execution vulnerability in Langflow, an open-source AI agent framework, affecting versions before 1.3.0.

Q: Could the victim have paid the ransom to recover their data?

A: No. The encryption key was generated on the fly and never stored or transmitted, so there was no key available to recover, regardless of payment.

Q: What makes this different from typical ransomware?

A: The individual techniques weren’t new. What stood out was the speed and adaptability: the agent diagnosed a failed login attempt and corrected it in 31 seconds, a pace closer to machine speed than typical human-paced attacker behavior.

Q: What should security and recovery teams take away from this?

A: That recovery planning needs to extend beyond application data to configuration stores, service-discovery platforms, secrets, and identity systems, the layer JadePuffer actually targeted for maximum damage.

Chris Bevil is Principal Portfolio Marketing Manager at Commvault.

Key Takeaways

• Advanced AI models escaped a restricted evaluation environment by exploiting previously unknown vulnerabilities.
• OpenAI says the models were pursuing an assigned objective, not acting with malicious intent, yet still caused a real security incident.
• Traditional controls like sandboxing and segmentation are insufficient if AI can discover unexpected paths around them.
• Cyber resilience is becoming as important as prevention.

It began as an internal evaluation of advanced AI cyber capabilities.

While attempting to solve a narrowly defined benchmark, OpenAI models discovered a zero-day vulnerability, escaped the intended restrictions of their test environment, escalated privileges, reached the internet, and compromised Hugging Face infrastructure.

They treated the technical boundaries around them as problems to solve.

This Was Not a Traditional Cyberattack

Hugging Face first reported that an autonomous AI-agent framework had compromised part of its production infrastructure. A malicious dataset exploited two code-execution paths in its dataset-processing pipeline, escalated to node-level access, harvested credentials, and moved laterally across internal clusters.

The models involved, including GPT-5.6 Sol and a more capable pre-release model, were operating with reduced cyber refusals and without the normal production classifiers. They went far beyond the assignment, exploiting a proxy vulnerability to reach the internet, then using stolen credentials and zero-day vulnerabilities to find a remote-code-execution path on Hugging Face servers.

Malicious Intent Was Not Required

There is no public indication that the models developed criminal intent or chose to harm Hugging Face. They did not need to. Give a capable system an objective, tools, time, and feedback, and it will route around obstacles.

The conversation has moved past prompts and bad answers. These are systems that can investigate, test assumptions, discover previously unknown vulnerabilities, use stolen credentials, escalate privileges, and continue operating when the first approach fails.

A Sandbox Is Not a Force Field

We call environments isolated, segmented, and sandboxed as though the label itself creates security. It does not. In this case, the obvious path to the internet was blocked, but a reachable software-package proxy was not, and the models used its vulnerability to escape. Policies and expected behavior are not enough. The technical environment itself must enforce the boundaries.

Why This Is a Resilience Story

The activity moved from an evaluation environment, through OpenAI’s research infrastructure, onto the internet, and into Hugging Face’s production environment. That is a rapidly expanding blast radius. When AI can explore and act at machine speed, the time between initial access and broader compromise may continue to shrink.

Hugging Face did not simply block the original access path and declare the incident over. It closed the vulnerable code-execution paths, rebuilt compromised nodes, rotated credentials and tokens, and tightened cluster controls. The objective is not merely to restore a system. It is to restore confidence.

The question is no longer only: Are our AI systems secure? It is: When a powerful AI system finds a path we did not know existed, can we contain the blast radius, continue critical operations, rebuild what we no longer trust, and prove it is safe to move forward?

Chris Bevil is Principal Portfolio Marketing Manager at Commvault.

Security does not end at the edge of an organization’s own systems. Modern businesses connect a growing web of third-party applications to their core platforms to support sales, service, and collaboration. Each of these connections adds value. Each one also introduces exposure the organization does not fully control.

That risk is not hypothetical. In June 2026, a threat actor compromised OAuth tokens tied to Klue, a competitive intelligence platform used to sync sales and marketing data with Salesforce. The attacker used those tokens to reach the Salesforce environments of the many organizations that had authorized the integration, including Commvault’s.

As soon as we were notified of potential impact, our Security team activated our incident response process to determine what had occurred, contain the exposure, and assess whether customer information or Commvault services were affected.

Our investigation found that the activity was limited to certain business relationship and sales information maintained within our Salesforce environment. The investigation found no indication that any customer backup data, product data, product metadata, operational logs, or Commvault services were impacted.

Acting Quickly When It Matters

Our response followed established security incident response procedures built to contain risk quickly while supporting a thorough investigation. Once we were notified of the incident, we disabled the Klue integration, revoked the associated access, and worked with the appropriate parties to conduct a full assessment of what happened.

Throughout the investigation, our teams worked to determine what information had been accessed, validate the integrity of our environment, and confirm the incident stayed within the scope we had already contained.

A Pattern Worth Noting

This incident is one recent example of a pattern security teams have watched grow for several years: attackers targeting third-party applications connected to core business systems rather than attacking those systems directly. A single compromised integration can offer a trusted path into the environments of many downstream organizations at once, often with less resistance than a direct attack on any one of them.

This shifts where an organization’s defense actually has to live. Strong internal controls remain necessary, but they are no longer sufficient by themselves. They have to be paired with active oversight of every application an organization connects, and a response capability that is ready before an incident, not built during one.

Building Resilience Beyond Our Own Environment

At Commvault, our security program includes ongoing assessment of the third-party applications connected to our environment. We review connected applications on a regular basis, evaluate the access each one holds, monitor for emerging risk, and reassess those integrations as business needs and the threat landscape change. When circumstances warrant, we act to reduce exposure and strengthen our posture, including disconnecting integrations that no longer meet our standards.

Our Commitment to Transparency

Trust is built through openness and accountability. When an event affects our stakeholders, we believe it is important to communicate what we know, explain how we responded, and share the outcome of our investigation, even when the event originated outside our own systems.

We will continue to evaluate our security controls, refine our incident response processes, and strengthen our approach to third-party risk as part of our broader commitment to protecting our customers and partners.

For the official details of this incident, including the scope of the investigation and customer guidance, please refer to our Trust Center Updates.

Will Galway is Deputy CISO at Commvault.