Subscribe now

Merlin Namuth is the Chief Information Security Officer at the City and County of Denver, where he leads security for over 50 agencies and departments. His experience spans multiple industries and includes building security programs from the ground up, advancing mature programs, leading incident response, and handling compliance, architecture, and mergers and acquisitions. A regular conference speaker and security startup advisor, he is also an active writer and podcast guest in the security community.

For Namuth, security leadership comes down to risk and trust. His approach includes weighing every tool purchase and budget request against the risk it reduces, cutting work that doesn’t move the program forward, and building relationships across the organization before a crisis hits. In this edition of CISO Tips, Namuth shares practical lessons on budgeting, vendor evaluation, incident response, team culture, and translating technical risk for executives.

Complete this sentence: “Before you buy any new security tool, first...”

Before you buy any new security tool, first understand what risk it will address, how much it will reduce that risk, and if the cost justifies the impact it will have on risk.

What’s one rule you enforce on your team that other teams would find strict?

We are in a position of high trust in the organization, and it is very important for us to have high integrity, adhere to the policies and rules, and help everyone who comes to our team, whether or not their issue falls within something we support and can fix. Trust takes a lot of work to earn and can go away in an instant with a bad decision.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

It is based on the severity of the risk and how reducing this risk will positively or negatively impact the business.

What’s one line that works when asking the board or CFO for a budget?

I explain the risk and how an increased budget will reduce that risk. Conversely, I share how no change in budget will keep the risk the same, and the potential costs to the business if it is exploited.

What should a CISO cut from their program tomorrow with zero regret?

Work the team is doing that doesn’t reduce risk or mature the security program.

What’s your 60-second test for whether a vendor pitch is worth your time?

If the solution solves a current challenge I have and fits in my current roadmap. When the vendor says they can have their solution running and providing value within 15 minutes, I tend to eliminate them from consideration.

What’s one meeting, report, or process you eliminated, and what replaced it?

I canceled weekly status meetings with my team because we had enough informal conversations for me to be informed. Too many meetings is malware.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Getting the right people involved, which should be outlined in the incident response plan.

What’s one question every CISO should ask their team this week?

I usually lead with “How are you?” I want my team to feel valued and appreciated, and to know that everything we do is part of the team. If one person on the team is struggling with something, it is the responsibility of the rest of the team to help out.

What’s a phrase or framing you use to translate a technical risk for executives?

In my current role as CISO for the City and County of Denver, I discuss how something can impact our public safety agencies and our residents.

What’s your best tip for surviving the CISO role in exactly five words?

Build relationships before crisis hits.

More tips from the series:

• CISO Tips: Samuel Keter on Turning Security Controls Into Business Decisions

• CISO Tips: Bryce Austin on Building a Security Program That’s “Secure Enough”

• CISO Tips: Stefano Pasotti on Turning Cybersecurity Into Business Resilience

• CISO Tips: Maurizio Imperadore on Resilience, Identity and Cutting Security Noise

• CISO Tips: Jigar Shah on Buying Fewer Tools, Building More Trust

Subscribe now

Subscribe now

As artificial intelligence becomes more deeply integrated into enterprise workflows, security teams are facing a growing set of challenges around the systems that support those deployments. Upwind is addressing that shift by acquiring AI security startup Aegis and creating a new AI Security Labs operation, as first reported by Axios.

The acquisition brings Aegis founders Omri Limor and Saar Ankonina into Upwind and establishes a dedicated research and engineering initiative within the company. Upwind says the labs will investigate emerging AI security risks while working to turn that research into enterprise-grade security capabilities.

The new operation will build on both Aegis’s technology and Upwind’s existing runtime platform, with work spanning scanning, attack detection and other AI security capabilities.

A Focus on the New AI Attack Surface

AI agents are increasingly capable of interacting with applications, accessing information and executing tasks, while skills and plugins can give those systems additional functionality. Those capabilities also introduce new components and potential security considerations for organizations deploying AI-powered workflows.

Upwind AI Security Labs will focus on researching those risks and developing capabilities designed to identify and address them. The labs will also prioritize secret scanning in transit and at rest, with Upwind pointing to industry findings involving API keys and session tokens that were compromised and harvested at scale for malicious campaigns.

The initiative builds on Aegis’s original focus on security challenges created by AI infrastructure. The startup was founded by Limor and Ankonina, who began their careers together as 8200 alumni working in offensive cybersecurity before later serving in different roles and eventually becoming peers.

After leaving the unit, the two founded Aegis to work on sophisticated AI-generated attacks, including autonomous exploitation pipelines and large-scale credential harvesting. The company later approached Upwind about strategic partnership and investment, and several months of collaboration ultimately resulted in the acquisition.

Combining Two Security Capabilities

For Upwind CEO and Co-Founder Amiram Shachar, bringing Aegis into the company is intended to increase the speed at which the organization can respond to developments in AI security.

“AI security is developing extremely quickly, and by acquiring Aegis and bringing Omri and Saar on board, we are building a team that can move just as quickly,” said Amiram Shachar, CEO and Co-Founder at Upwind. “The Aegis team brings a deep understanding of the challenges around securing agents, skills, and plugins, and by combining that expertise with Upwind’s existing platform, we can move from research to real-world security capabilities much faster.”

The Aegis founders similarly see the acquisition as a way to accelerate their existing work. “We initially built Aegis as a startup to tackle the missing security layer around AI agents, skills and plugins,” said Omri Limor, Co-Founder of Aegis. “After spending several months working together with Upwind, it became clear that joining forces through an acquisition and establishing AI Security Labs inside Upwind would allow us to move much faster and combine our technology with the capabilities Upwind has already built.”

Ankonina added that the integration offers a direct route to scaling the technology. “Integrating our technology directly into Upwind’s platform gives us an immediate path to scale,” added Saar Ankonina, Co-Founder of Aegis. “The establishment of AI Security Labs provides the ideal environment to accelerate research and protect enterprise AI workflows.”

Expanding Beyond the Initial Team

The labs are beginning with 12 developers and researchers from Aegis and Upwind, with plans to significantly increase that number. Upwind expects the group to reach approximately 25 people within three months and potentially grow to 35 as the initiative continues to develop.

The planned growth will expand the company’s research and engineering capacity as it works on emerging AI security challenges. Shachar said the team is intended to become a significant research and engineering capability within Upwind rather than remain a small group attached to the acquisition.

“We built AI Security Labs on the foundation of the Aegis acquisition with the ambition to create a significant research and engineering capability within Upwind,” said Shachar. “We expect the team to grow from 12 people today to 25 and potentially 35 in the coming months, allowing us to expand our research and accelerate the development of new AI security capabilities.”

Speeding Up the Path From Research to Market

A central part of the initiative will be connecting security research with practical product development. Upwind says that as AI capabilities evolve, identifying new attack techniques and translating those findings into usable defenses will become increasingly important.

By bringing Aegis’s technology and team into Upwind, the company says AI Security Labs can shorten the path between identifying emerging risks and developing new security capabilities. The effort is positioned as an extension of Upwind’s existing mission around cloud and AI security.

“As AI transforms both the threat landscape and the speed of modern cyber operations, this is the ideal moment to build, innovate, and lead in cloud and AI security,” added Shachar. “With AI Security Labs, Upwind is reinforcing its mission to protect modern enterprise infrastructure and ensure organizations can safely embrace the next era of AI innovation.”

Subscribe now

Subscribe now

With more than a decade of experience across cloud security, audits, risk management and security governance, Samuel Keter has worked at the intersection of cybersecurity and business operations across banking, fintech and consulting organizations. He has led teams through ISO 27001, PCI DSS, SOC 2 and NIST programs, managed complex cloud and on-premises audits, and advised executive leadership on security risks and controls across multiple regions.

For Keter, effective security leadership is less about accumulating tools and metrics and more about building systems that reduce measurable risk. His approach includes testing what existing technology can already accomplish before buying new products, enforcing security gates in development pipelines, allocating resources according to risk, and translating technical exposure into numbers executives already understand. In this edition of CISO Tips, Keter shares practical lessons on budgeting, incident response, cloud identity, compliance evidence and making security decisions that hold up under scrutiny.

Complete this sentence: “Before you buy any new security tool, first...”

Before you buy any new security tool, first build the simple version with what you already own. We scripted a cloud misconfiguration audit across every project before looking at a posture product. The audit identified most of the issues that the demo had presented. The identified gaps formed the basis for the shortlist and our negotiating position.

What’s one rule you enforce on your team that other teams would find strict?

Nothing merges without a signed commit and a green security gate, and the gate is required verification, not advisory. It blocked a release in its first week, and the team fixed the finding rather than disabling the verification. That decision is the rule. Most teams have the same policy but a pipeline that doesn’t enforce it.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

70, 20, 10. 70% of the budget and headcount is allocated to risk reduction, 20% to proof, and 10% to options. Workload identity to kill static keys retires a register item, so it comes from the 70. Compliance automation that collects control evidence on a schedule reduces no risk but makes SOC 2 and PCI DSS continuous, so it comes from the 20. A month for an engineer to build an alert triage agent might fail, so it comes from the 10. A second dashboard is not being developed because someone prefers the interface, so it remains on hold.

What’s one line that works when asking the board or CFO for a budget?

This expense is not security spending. It is the cost of keeping our license to process payments. Then I put the control cost next to the share of revenue running over card rails, and the conversation becomes about their exposure rather than my budget.

What should a CISO cut from their program tomorrow with zero regret?

Do not use any metric that counts items unless it influences a decision. We dropped total open vulnerabilities from the executive report and replaced them with exploitable findings on internet-facing assets and the median days to close. The total rose the next month because we found more. Nobody asked, because the numbers that mattered fell.

What should a CISO cut from their program tomorrow with zero regret?

I ask how the product authenticates to my cloud. A service account key with an owner role fails the test I hold my engineers to, and the meeting is over. Federated identity, scoped permissions, and an expiring token earn the next twenty minutes.

What’s one meeting, report, or process you eliminated, and what replaced it?

The weekly alert review involves five people reading raw findings displayed on a screen. A monitoring agent now ingests events from source control, applies a rule-based severity floor before the model sees them, and logs every decision to an audit table. It ran in shadow mode for weeks, with the team grading its calls before anything was routed based on its output. The audit table is now our evidence for the monitoring control.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Stopping the pipeline. In a package registry compromise this year, freezing CI and pinning the package took under ten minutes. Working out how it was poisoned took days. Teams do those in the wrong order, and every build in between pulls the compromised version again.

What’s one question every CISO should ask their team this week?

If an auditor asked for evidence of this control at nine tomorrow, what would we be able to provide? Ask about one control each week. The phrase “I would have to pull it together” indicates that while the control is legitimate, the supporting evidence is lacking, which is the basis for the next audit finding.

What’s a phrase or framing you use to translate a technical risk for executives?

Three numbers the board already tracks: customers exposed, money at risk, and hours until we would know. A permissive IAM binding means nothing to them. Every customer in the wallet database, the balance held there, and four days before detection fires gets a decision in the same meeting.

What’s your best tip for surviving the CISO role in exactly five words?

Trust nothing. Log everything. Sleep.

More tips from the series:

• CISO Tips: Bryce Austin on Building a Security Program That’s “Secure Enough”

• CISO Tips: Stefano Pasotti on Turning Cybersecurity Into Business Resilience

• CISO Tips: Maurizio Imperadore on Resilience, Identity and Cutting Security Noise

• CISO Tips: Jigar Shah on Buying Fewer Tools, Building More Trust

• CISO Tips: Andy Curtis on Turning Cybersecurity Into Business Risk Decisions

Subscribe now

Subscribe now

A growing discussion among cybersecurity executives is taking place around a deceptively simple question: what happens if artificial intelligence moves faster on the offensive side than it does on the defensive side?

Asaf Wiener, CEO and co-founder of Mate Security, raised that question in a LinkedIn post that has generated substantial discussion among cybersecurity professionals. His argument challenges the idea that slowing the development of advanced AI automatically reduces risk, pointing instead to the possibility that restrictions could affect defenders more directly than attackers.

The post was prompted by a letter from Anthropic CEO Dario Amodei advocating for “pacing the frontier,” a proposal centered on coordination and responsible development among leading AI companies.

Wiener took a different view.

“Pace the frontier, and you pace exactly one side of this fight, the defense side,” he wrote. “The answer isn’t to slow defenders down. It’s getting trusted, verifiable AI into their hands faster, with the right guardrails in place.”

The response attracted comments from cybersecurity professionals unaffiliated with Mate Security, helping turn what could have been a company executive’s policy reaction into a wider industry discussion.

The Problem With A One-Sided Race

Wiener’s argument rests on an asymmetry in cybersecurity.

AI companies can voluntarily coordinate around safety standards. Attackers generally do not operate under the same constraints.

That creates a potential disconnect between the pace of AI development and the pace at which organizations prepare to defend themselves. If security teams wait for future AI capabilities to arrive before investing in AI-driven defense, they may be responding to a threat that is already evolving.

In the longer analysis accompanying his LinkedIn post, Wiener describes these as two separate frontiers: the frontier of AI capability and the frontier of offensive cyber activity.

The latter does not wait for the former.

“There’s a second frontier the letter never touches: how fast attackers are already moving with the AI that exists today,” Wiener wrote.

Several commenters picked up on that distinction. Omer Karny responded, “Exactly. Thinking that everyone will pace themselves because someone said it- just won’t work…” Noam Bar-Lev similarly wrote, “100%. Slowing things down gives attackers the edge.”

From AI Experiment To Security Infrastructure

The discussion is also part of a larger transition in enterprise cybersecurity.

For years, AI in security was largely associated with detecting anomalies, prioritizing alerts or helping analysts process large quantities of data. The emergence of AI agents introduces a different proposition: systems that can conduct investigations and potentially execute portions of a response process with substantially less human intervention.

That creates a new requirement alongside speed: control.

Wiener argues that security agents should be subject to the same principles increasingly being discussed for frontier AI. They should be verifiable, auditable and accountable for the systems they interact with.

This is where his argument moves beyond simply calling for faster AI adoption. The proposition is not that companies should deploy autonomous systems without restrictions. Instead, organizations should build guardrails that allow AI-driven security operations to move quickly while remaining within defined boundaries.

Why The Post Resonated

The reaction to Wiener’s post reflects the fact that the issue sits at the intersection of two of the industry’s biggest conversations: AI governance and cybersecurity preparedness.

Inbal Argov commented that organizations need to focus on “the mechanisms around the models that make them trusted and operationalized, and hunting down the frontier-powered attackers.” Sharon Rosenman wrote, “Slowing down innovation is not a good idea and will practically not happen. Great insight.”

Other commenters took a more concise approach. Chris Hoard called it “A good read. Thanks,” while Dineshwar Sahni wrote, “…and attackers won’t write 3000+ or 6000+ essays … You got it right mate!”

The variety of responses helps explain why the post has attracted attention beyond Mate Security’s immediate network. Rather than discussing a product launch or corporate milestone, Wiener entered an active debate about the future of AI and cybersecurity—and connected an abstract AI policy question to a concrete concern for security teams.

The takeaway from his argument is not that AI governance is unnecessary. It is that governance and defensive readiness need to advance together. As AI becomes increasingly capable on both sides of the cybersecurity equation, the organizations responsible for protecting networks, applications and data will have to consider how quickly their defenses can operate when the threat itself is moving at machine speed.

Subscribe now

Subscribe now

The cybersecurity industry is entering an unusual period in which the technology being used to attack organizations is advancing at the same time as the technology being used to protect them. Artificial intelligence has the potential to widen or close that gap, depending on how quickly defenders can put increasingly capable systems to work.

OpenAI is attempting to accelerate the defensive side of that equation. In a new open letter titled “A Call to Action on Cyber Defense.” OpenAI President and Co-Founder Greg Brockman is calling on companies, governments and technology providers to coordinate their efforts around AI-powered cyber defense.

Among the first-day signatories are Palo Alto Networks, Mate Security, and ServiceNow, putting the three companies among a select group of market leaders backing the initiative from its launch. The participation is particularly notable for Mate Security, which is part of a relatively small group of companies developing an agentic approach to cyber defense.

A Narrow Window

The premise of OpenAI’s initiative is straightforward: the cybersecurity industry cannot afford to wait until AI-enabled attacks have fully matured before modernizing defensive capabilities.

“We have a limited window to strengthen cyber defenses,” the letter says.

OpenAI predicts that AI-enabled cyber attacks will become more widespread and sophisticated as models continue to improve. The company points to a broad range of potential targets, including hospitals, water treatment plants and the infrastructure that supports the internet.

But the letter is not simply a warning about AI.

OpenAI argues that today’s advances also give defenders an opportunity to address weaknesses that have remained embedded in enterprise and public-sector environments for years.

The Security Debt Problem

Many of the vulnerabilities highlighted in the letter are hardly new. Organizations continue to struggle with unpatched software, weak authentication, excessive permissions, misconfigurations and legacy systems that are difficult to upgrade.

The difference is that AI could change the economics of addressing those problems.

OpenAI argues that cyber-capable AI can bring specialized security capabilities to a larger number of defenders while making core security tasks “faster, cheaper and better.”

That proposition could be particularly important for organizations with small security teams. Instead of expecting a limited number of specialists to manually investigate every alert or vulnerability, AI agents could increasingly take responsibility for portions of the investigative and remediation process.

Why Mate Security Is Significant

This is where Mate Security’s participation becomes particularly relevant.

Mate is building an open foundation for agentic cyber defense, positioning AI agents as active participants in security investigations rather than simply assistants to human analysts.

The company’s Gamebooks technology is designed to provide agents with structured investigation procedures while allowing them to reason, pivot and act as an investigation develops.

That combination addresses a central issue surrounding autonomous security systems. Security teams want AI to operate with enough independence to reduce workload, but they also need predictable processes and organizational controls.

Agentic cyber defense attempts to bridge that gap.

Palo Alto Networks And The Broader Market

Palo Alto Networks represents a different but equally important part of the cybersecurity landscape.

Its participation demonstrates that the move toward AI-enabled defense is not limited to emerging vendors or companies built exclusively around autonomous agents. Established cybersecurity platforms are also becoming part of the transition toward AI-driven security operations.

ServiceNow And The Remediation Gap

ServiceNow’s inclusion extends that picture into the enterprise systems where security work is carried out.

The letter does not stop at detection and investigation. It asks organizations to fix their most dangerous weaknesses, verify that those fixes work and measure progress by tangible outcomes, including how quickly attacks are contained.

Those steps depend on coordination across teams that often sit outside the security function. A confirmed vulnerability still has to be assigned, scheduled, applied and closed out, and that process is frequently where remediation stalls.

The presence of Palo Alto Networks, Mate Security and ServiceNow together therefore offers a snapshot of where the market is heading: established security infrastructure and enterprise workflow platforms are evolving alongside a new generation of AI-native and agentic security technologies.

A Shared Responsibility

OpenAI’s letter also makes clear that the company does not believe the future of cyber defense should be controlled by a single vendor.

“No single company should control the future,” it says, arguing for a collective response involving governments, cybersecurity companies, technology partners and frontier AI companies.

The letter calls for more threat-intelligence sharing, tested playbooks, authorized testing and practical assistance for critical infrastructure organizations.

For the companies, becoming first-day signatories puts them behind that broader industry effort at a pivotal moment.

The cybersecurity market has spent years discussing the potential of artificial intelligence. The latest initiative suggests that the conversation is moving into a more consequential phase: determining how quickly AI can become a practical, scalable and accountable tool for the people defending the world’s most important digital systems.

Subscribe now

Subscribe now

Enterprise cybersecurity teams are increasingly dealing with a problem that is less about whether they have security tools and more about whether those tools can work together.

Internet-facing applications now operate across a growing combination of cloud providers, content delivery networks, web application firewalls and other network services. That expansion has given organizations more ways to build and secure applications, but it has also created fragmented environments that can be difficult to understand and manage consistently.

Huskeys is betting that this growing complexity requires a new layer of security management. The cybersecurity company has raised a $27 million Series A led by Blackstone Innovations Investments, bringing its total funding to $35 million following an $8 million seed round. The funding was first reported by the Wall Street Journal.

The round also included Merlin Ventures, Skinos Ventures, Zscaler Ventures, Okta Ventures, Bright Pixel Capital and SV Angel, as well as individual investors including WAF and CAPTCHA inventor Eran Reshef and executives from organizations including Palo Alto Networks, Cloudflare, Check Point, AWS, Google, Microsoft and Intel.

Security Teams Are Managing an Expanding Edge

The network edge has become a convergence point for applications, customers, revenue and cyber threats. Yet the technologies used to manage that environment are often distributed across multiple vendors and platforms.

Security teams may need to understand configurations and policies across CDNs, WAFs, cloud-native security tools and networking components such as load balancers, VPCs and security groups. Making changes in those environments can introduce a separate risk: disrupting legitimate traffic while attempting to block malicious activity.

That balancing act is becoming more difficult as applications become increasingly dynamic and AI-driven. Security teams must respond to emerging threats while maintaining business continuity and avoiding false positives that could affect customers.

Huskeys is building what it calls a Network Edge Security Management platform, or NESM, to address that challenge.

A Layer Above Existing Security Tools

The company’s approach does not involve replacing the infrastructure organizations already use. Instead, Huskeys’ platform is designed to connect and orchestrate existing technologies across the network edge.

Through its patented Unified Data Model, the company creates a common layer of understanding across different environments, providers and technologies. The goal is to allow security insights, policies and actions to move across platforms while supporting multi-cloud and multi-vendor environments.

The platform includes continuous posture assessment, dynamic policy generation and orchestration. It also provides Virtual Patching, which allows security teams to mitigate vulnerabilities directly at the network edge while a permanent fix is developed, tested and deployed within application code.

Huskeys is also addressing the growing role of autonomous AI agents, which are creating new forms of legitimate traffic that security teams must distinguish from potentially malicious automation.

“We founded Huskeys because security teams are being asked to protect increasingly complex edge environments with legacy tools that were never designed to work together or to address the challenges of the new AI era,” said Itai Gafni, CEO and Co-Founder of Huskeys. “Every business today runs through its network edge - that’s where your customers, your revenue, and your threats all meet, yet for most organizations, that edge works against them instead of for them. As AI transforms both legitimate traffic and cyberattacks, organizations need an intelligence layer that continuously understands what’s happening across the edge and adapts security in real time. Our goal is to make the network finally work for the business, not against it. That’s the category we’re building.”

An Investor Bet on Network Edge Security

Huskeys says its customer base includes TikTok, LEGOLAND, Ro, Blackstone and Hugging Face. The company is already analyzing more than a trillion web requests and thousands of network configurations every day across organizations worldwide.

Blackstone’s investment comes as organizations face increasing pressure to secure infrastructure without creating friction for the applications and services that generate business value.

“The way organizations secure internet-facing applications is fundamentally changing. AI-driven traffic and increasingly fragmented edge environments require a new approach to security management,” said Adam Fletcher, Chief Information Security Officer at Blackstone. “Huskeys has built a platform designed to operate at enterprise scale while advancing a new category for the modern network edge. We believe the company is well positioned to redefine how organizations manage edge security, and we’re excited to support Huskeys as they continue to develop their product in this important category.”

The central question Huskeys is trying to answer is becoming increasingly relevant: as organizations add more security and infrastructure technologies to the network edge, who or what will manage the entire environment as one connected system?

Subscribe now

Subscribe now

Governance has been the quiet gating factor on AI adoption in the security operations center. Security leaders can articulate the upside of agents that reason and act at machine speed. They also carry accountability for what those agents do to production systems. Mate Security‘s launch of Gamebooks, first reported by SiliconANGLE, is aimed squarely at that accountability question.

The Governance Problem, Stated Plainly

Organizations need AI agents to get it right. Mate’s framing of the standard is specific: 90 percent accuracy is not sufficient when the remaining margin can disable a legitimate account, revoke an executive’s access, or shut down a critical production system.

The industry’s response has been to limit AI autonomy, generally by placing a human at every decision point. That preserves control. It also caps the speed of the defense, because an agent waiting for human approval cannot operate at machine speed. Mate cites the recent Hugging Face incident as a demonstration that AI-driven attacks run continuously, in parallel, and adapt as defenders respond.

Mate’s position is that the choice is not autonomy versus control. It is controlled autonomy, which means letting agents reason, pivot, and act while keeping them inside the organization’s methodology, policies, and guardrails.

Encoding Methodology Into Software

A Gamebook is where an organization’s investigative approach becomes something an agent can follow.

Mate Security’s Gamebooks each define what must be investigated, what evidence must be established, which conditions should change the investigation, which actions are permitted, and when an agent must escalate, stop, or request approval. That last element is the governance hook. Escalation points, stop conditions, and approval requirements are properties of the Gamebook rather than judgment calls the agent makes on its own.

Gamebooks define investigative intent rather than a fixed execution path. The agent is told what to accomplish and which boundaries apply. It determines the route from the evidence and the organization’s most current context.

Separation of Powers

The architecture reinforces the governance model through layering.

An orchestrator reads the investigation and composes the appropriate Gamebooks. Gamebooks carry investigative intent, required evidence, and boundaries. Capabilities give agents reusable, vendor-neutral security skills. Agents apply those capabilities dynamically as evidence emerges. The Security Context Graph keeps everything grounded in shared state and current organizational context. Flows form the controlled execution layer that governs how agents interact with specific tools and systems.

Mate makes a point of what this separation achieves for risk owners. Investigative intent stays consistent while execution adapts, and agents never receive unrestricted access to real systems.

Continuity as a Control

Change is a governance risk in its own right. Organizations replace security tools. They acquire companies with different security stacks. Vendors introduce new alert types. Experienced analysts leave.

Under a traditional playbook model, each of those events means rebuilding workflows, and every rebuild is an opportunity for drift away from approved procedure. With Gamebooks, investigative intent remains intact while execution adapts. The same Gamebook continues to operate through a tool change or an acquisition. When an analyst leaves, the Security Context Graph preserves previous decisions along with the reasoning and context behind them. The world changes. The investigation methodology does not have to be rebuilt.

Ownership of the Method

Gamebooks are extensible and customizable, which matters for organizations that treat their investigative methodology as proprietary. Teams can adapt agentic investigations to their own processes, tools, and institutional knowledge without taking on the complexity of building, testing, and operating agentic systems.

Existing playbooks can be translated into investigative intent. Mate’s expert-designed Gamebooks can be extended with organization-specific requirements. Proprietary tools and data can be connected. New investigation procedures can be written in natural language.

Mate owns the underlying agent engineering, evaluations, testing, and execution. As models, tools, and environments change, Mate continuously validates and evolves the system while customers retain their investigation logic and customizations. The division is clear. Organizations define how they investigate. Mate ensures the agents execute it reliably. Customers build with Mate rather than around it.

An Audit Trail That Improves the System

Gamebooks operate inside Mate’s Continuous Detection / Continuous Response loop, where detection, investigation, and response function as one continuous process.

Every investigation adds evidence, relationships, outcomes, and reasoning to the Security Context Graph. That record does double duty. It preserves the basis for decisions, and it feeds improvement, since useful investigation patterns can strengthen capabilities, update Gamebooks, or become new detections. Noisy detections can be tuned based on actual investigation results.

The Direction of Travel

“AI is changing the speed and scale of both attack and defense, but security teams cannot trade control for speed,” said Oren Saban, Co-Founder and Chief Product Officer at Mate. “The shift to agentic investigations requires a different architecture, one that gives AI the freedom to reason and adapt while keeping it grounded in how each organization actually investigates. Gamebooks give agents that structure, so organizations can move toward autonomous security operations without giving up trust.”

Gamebooks join the Security Context Graph and CD/CR as Mate’s architecture for agentic security operations, moving investigations from scripted automation toward trusted agentic work. Gamebooks are generally available as part of the Mate platform, and the company will showcase them at CrowdStrike Fal.Con 2026.

Subscribe now

Subscribe now

Cybersecurity leaders are constantly asked to do more: deploy new tools, close more vulnerabilities, produce more dashboards, and justify larger budgets. But for Bryce Austin, CEO of TCE Strategy and a practicing fractional CISO, effective security starts with a simpler question: What problem are we actually trying to solve? Austin argues that security teams should be deliberate about what they buy, how they allocate resources, and whether a technology investment genuinely improves the organization’s security posture.

Austin brings experience advising companies ranging from 50 employees to members of the S&P 500, along with his perspective as the author of Secure Enough? 20 Questions on Cybersecurity for Business Owners and Executives. His approach puts people and decision-making ahead of technology, from assigning a human owner to every security tool to eliminating dashboards that don’t lead to action. In this edition of CISO Tips, Austin shares practical advice on cutting shelfware, communicating risk to executives, preserving evidence during incidents, and making sure security teams focus on the risks that actually matter.

Complete this sentence: “Before you buy any new security tool, first...”

…define the specific problem you are trying to solve. You buy a sports car to have an exciting driving experience, not haul a large trailer. Make sure everyone agrees on the problem before anyone starts shopping for solutions.

What’s one rule you enforce on your team that other teams would find strict?

Do not move the goalposts on a security project. I require my teams to manage project deadlines and to proactively reach out if something is going to get in the way of a deadline. For example, when decommissioning an insecure system, standing up the new system to replace it makes the cybersecurity issue WORSE while both systems are running. It is not until the old system is completely gone that you have done any good to the cybersecurity posture of the organization.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

My ratio is 1:1: every cybersecurity tool needs a human owner. If I can’t identify someone with the time and expertise to properly manage a product before we buy it, I don’t want it. I also look hard at whether a process or procedure change can solve the same problem. New tools need additional resources to manage and maintain, and sometimes introduce new vulnerability risk (read: SolarWinds Orion in 2020) or operational risk (read: CrowdStrike in July 2024).

What’s one line that works when asking the board or CFO for a budget?

Cybersecurity isn’t perfect. We need to be Secure Enough for us. Cybersecurity issue XYZ is not one that I can make a credible argument that we are Secure Enough. Either we consciously accept this risk as a leadership team, or we find the funding to fix it.

What should a CISO cut from their program tomorrow with zero regret?

Shelfware. Kill it. If you bought a software package or service and it isn’t working out because your team doesn’t have the time or expertise to effectively utilize it, cut it ASAP.

What’s your 60-second test for whether a vendor pitch is worth your time?

I ask, “What business problem do you solve that no one else solves, or that you solve better for a given price?” If they can’t give me a 60-second answer that makes sense, I’m out.

What’s one meeting, report, or process you eliminated, and what replaced it?

Security dashboards that don’t help me make good decisions are just wall art. I eliminate them entirely, or make revisions so that reasonable action can be taken because of the information they contain. 2000 “critical” vulnerabilities on the monthly patching report are not actionable. Thirty “actively exploited by ransomware gangs” vulnerabilities on the same report are very actionable.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

They forget to preserve evidence. Take screenshots. Record what you are seeing. Disconnect computers from the network but don’t reflexively reboot or power them off, as you may destroy valuable evidence in active memory. If you can’t otherwise contain an actively spreading attack, then containment takes priority. Preserving the active memory of an infected computer often leads to meaningful clues as to what is going on.

What’s one question every CISO should ask their team this week?

What is getting in your way that I can help you with?

What’s a phrase or framing you use to translate a technical risk for executives?

I’ve used this one a lot: Most car tires want around 35 psi of air in them. Having a car tire that is 3 psi low on air is not best practice, but it is not an emergency. A car tire with only 3 psi of air is a life safety issue when traveling 70 mph on the highway. A big part of my job is helping executives understand whether the cybersecurity issue in front of us is the former or the latter.

What’s your best tip for surviving the CISO role in exactly five words?

People come first. Not technology.

More tips from the series:

• CISO Tips: Stefano Pasotti on Turning Cybersecurity Into Business Resilience

• CISO Tips: Maurizio Imperadore on Resilience, Identity and Cutting Security Noise

• CISO Tips: Jigar Shah on Buying Fewer Tools, Building More Trust

• CISO Tips: Andy Curtis on Turning Cybersecurity Into Business Risk Decisions

• CISO Tips: Carlos García Batista on Turning Cybersecurity Into Operational Resilience

Subscribe now

Subscribe now

Stefano Pasotti, CISO and ICT Manager at DN Automotive Italy, brings a pragmatic perspective to cybersecurity shaped by years of experience across software development, IT leadership, manufacturing, and logistics. In his role, he oversees cybersecurity, infrastructure, and digitalization initiatives across European operations, where technologies ranging from WMS and production planning to EDI and IoT must work securely and reliably.

For Pasotti, effective security is ultimately about making better business decisions. His approach emphasizes measurable risk reduction over flashy tools, practical incident readiness over compliance theater, and clear communication that translates technical risk into business consequences such as production downtime. In this edition of CISO Tips, he shares his principles for evaluating security investments, preparing teams for incidents, working with vendors, and leading security programs with discipline and reflection.

Complete this sentence: “Before you buy any new security tool, first...”

...I ask myself how much it actually reduces our risk percentage, how much it really makes us safer. Is it a necessary move, or just a ‘cool tool’?

What’s one rule you enforce on your team that other teams would find strict?

Document everything. An experience that isn’t written down is an experience lost.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

Training before tools, always. It only takes one wrong click to waste a thousand technology solutions.

What’s one line that works when asking the board or CFO for a budget?

I put risk on the table, not the tool. How much risk is the company willing to take? How much downtime can we afford, and how likely is it to actually happen?

What should a CISO cut from their program tomorrow with zero regret?

Some certifications that only exist for the plaque on the wall. If they change nothing in practice, they’re just time spent — not security.

What’s your 60-second test for whether a vendor pitch is worth your time?

“If they throw around technical jargon at random, or bombard me with overly detailed questions that make no sense at this stage, I know right away they haven’t listened. Same if they show no interest in understanding who we are and what we do before pitching us something: they’re not selling a solution, they’re selling a script.”

What’s one meeting, report, or process you eliminated, and what replaced it?

I rarely eliminate; I prefer to rebuild. The latest case: incident response policies and runbooks that only existed on paper — I rewrote them to be truly operational, not just a compliance exercise.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Stopping to think. Speed is critical, so the temptation is to act immediately — but acting without a moment’s reflection can cause more damage than the incident itself.

What’s one question every CISO should ask their team this week?

If it happened right now, would we actually know what to do, or would we be improvising?”

What’s a phrase or framing you use to translate a technical risk for executives?

I translate everything into production downtime. Once the risk is clear to everyone, then we talk solutions.

What’s your best tip for surviving the CISO role in exactly five words?

Stop, reflect, then take action.

Subscribe now

Subscribe now

Ask a security team to name the least governed system in the enterprise and few will say “the developer laptop.” They should. It changes daily. Extensions, packages, plugins, and AI tooling get assembled on the fly, rarely pass through review, and remain largely invisible to endpoint detection. Bloom Security‘s latest research turns that abstraction into a measurable exposure across roughly half a million downloads and more than 750 extension packs.

The vulnerability is called Extension Resurrection, and it affected both Open VSX and the Visual Studio Code Marketplace. What makes it worth a board-level conversation is not the exploit chain. It is the trust model the exploit chain borrows.

One Install Decision, Ten Unreviewed Consequences

When a developer installs an extension pack, they are not installing one tool. They are accepting a curated list of dependencies, every one of them granted deep access to the filesystem, running processes, and the network.

The pack was reviewed. Its contents were not. Bloom Security identifies that gap between what a user trusts and what actually gets installed as precisely where the attack lives.

Extension packs therefore behave as a risk multiplier. A single approval quietly expands the attack surface by five, ten, or more components that nobody explicitly evaluated. The research is unambiguous about the required posture change: treat extension packs within the same threat model as direct extension installs, and review the bundle manifest rather than the pack name.

Volume Is Working Against Defenders

Scale deserves attention here. In the first six months of 2026, the VS Code Marketplace nearly doubled in size. Between the two marketplaces, roughly 1,400 new extensions ship every single day. AI tooling has let teams move faster than before, and the output is an explosion of new software landing continuously.

Every developer runs at least one extension outside the defaults of their chosen IDE. That baseline was never the interesting part. The interesting part is that the catalog defenders would need to vet is growing faster than any manual review process can absorb.

What the Attack Actually Required

The technical prerequisites were modest, which is the point.

Both marketplaces permitted packs to reference extensions that did not exist. Bloom Security calls those dangling references Shadow Dependencies, and they arise either when a pack is mirrored to Open VSX without one of its bundled components, or when an extension referenced by a live pack is deleted.

Extensions are identified by publisher or namespace paired with an extension ID, so hijacking one means claiming the original publisher or namespace rather than just an available name. Both platforms allowed open registration of those names, including names that published software actively referenced.

Bloom Security’s scan quantified the field. Open VSX: 94 of 321 packs carried a shadow dependency with an unregistered namespace. VS Code Marketplace: 677 of 4,179 packs carried a shadow dependency, 60 of them under an unregistered publisher. Two of those were used for a live proof: prettify-json under mohsen1 on Open VSX, and control-snippets under svipas on the VS Code Marketplace.

Open VSX initially rejected an exact version match because it already held a ghost record from a mirrored manifest. Incrementing the version resolved that instantly, since packs reference bundled extensions by ID without pinning versions.

The Part That Should Worry Risk Owners

Installation was never the only vector. Auto-update configuration for bundled extensions is inherited from the pack, and the default is enabled. Anyone who installed an affected pack in the past, under default settings, could receive attacker-controlled code on a routine update.

Extensions run with Node.js host access. They read and write files, spawn child processes, and reach the network. Bloom Security’s assessment is that an extension is not sandboxed in any meaningful sense with respect to code execution, so a malicious install is functionally remote code execution on the machine.

That machine belongs to a software developer. Source repositories, cloud credentials, deployment pipelines, internal tooling. Applying a deliberately conservative estimate that half of the affected downloads had auto-update on, the research arrives at roughly a quarter of a million compromised developer endpoints within a day.

The Control Set Being Recommended

Bloom Security lists three capabilities security teams need, and none of them are novel. The difficulty is that most organizations lack all three for this surface.

The first is inventory of installed extensions and packs across the organization. The second is visibility into IDE configuration, specifically whether auto-update is enabled and for which extensions, plus whether policy limits installs to a pre-approved list. The third is extension scanning that audits capabilities, security posture, and risk for each installed extension, treated as a continuous process covering every new version rather than a one-time exercise.

For developers, the guidance is narrower. Auto-updated extension packs behave like auto-updates for every extension they bundle. Install once does not mean static forever. Periodically review what the IDE has actually installed, not just what was chosen.

Vendor Response as a Governance Signal

Bloom Security reported to the Eclipse Foundation on February 5, 2026, and to Microsoft via MSRC on February 17, 2026.

Eclipse assigned all at-risk namespaces to the open-vsx account within hours, then implemented a pre-publication check now blocking packs with non-existent bundled extensions and extensions with non-existent dependencies. Triage also surfaced that extension dependencies were vulnerable to the same technique. Bloom Security describes the experience as very positive and points to Open VSX as a model for marketplace response.

Microsoft’s path was longer. MSRC’s first assessment was Moderate severity on the basis that the Visual Studio Marketplace already had publisher resurrection prevention in place. Bloom Security disputed that with video evidence and additional examples of re-registering removed publishers, and the case was reopened. Engineering subsequently confirmed a partial fix from October and stated that prevention had covered admin actions since October and user actions only as of that month. The two stages landed in October 2025 and June 2026 respectively, documented at github.com/microsoft/vsmarketplace/discussions/1708. Microsoft acknowledged the completion arrived after the report. The eight-month interval between stages left real exposure for user-action resurrection, which Bloom Security demonstrated.

The broader lesson does not stop at extensions. The endpoint attack surface expands constantly through installs, updates, configuration drift, and AI tools pulling in fresh dependencies. Bloom Security’s argument is that everything running there needs to be continuously known, vetted, and governed as an ongoing process rather than a periodic audit. Organizations without that visibility, the research concludes, sit a few clicks away from an incident.

Subscribe now

Subscribe now

Cybersecurity leadership is rarely about having the most tools or the most elaborate security program. For Jörg Scheiblhofer, Chief Information Security Officer at ORF, effective security starts with understanding the organization’s requirements, processes, and actual risk before deciding which technologies or controls are needed. His approach emphasizes analytical thinking, consistency, and a clear understanding of the potential impact of security decisions.

In this edition of CISO Tips, Scheiblhofer shares his perspective on making better decisions under pressure, communicating cyber risk to executives through relatable analogies, and avoiding assumptions during critical incidents. From assessing the real situation in the first minutes of an attack to tailoring risk discussions for the board, his advice reflects a practical philosophy: strong cybersecurity requires sound analysis, clear communication, and a human approach.

Complete this sentence: “Before you buy any new security tool, first…”

…you have to think about process and your requirements “

What’s one rule you enforce on your team that other teams would find strict?

There are no exceptions on suspicion without an analytical basis and certainly no general exceptions.

What’s one line that works when asking the board or CFO for a budget?

It is not a single sentence; rather, it is a presentation, tailored to the target audience, of the risks that exist or may arise if measures are not implemented.

What’s your 60-second test for whether a vendor pitch is worth your time?

Has he dealt with his potential customer?

What’s one meeting, report, or process you eliminated, and what replaced it? -

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Accurately assessing the actual situation. In the heat of the moment, this is often overlooked. What’s one question every CISO should ask their team this week?

What’s a phrase or framing you use to translate a technical risk for executives?

I like to use the creation of analogies from everyday life. In a way, a language in pictures, so that management can imagine something better.

What’s your best tip for surviving the CISO role in exactly five words?

1.) remain consistent 2.) adopt an analytical approach 3.) tailor communication to the target audience 4.) assess the risk and potential damage 5.) remain human

More tips from the series:

• CISO Tips: Maurizio Imperadore on Resilience, Identity and Cutting Security Noise

• CISO Tips: Jigar Shah on Buying Fewer Tools, Building More Trust

• CISO Tips: Andy Curtis on Turning Cybersecurity Into Business Risk Decisions

• CISO Tips: Carlos García Batista on Turning Cybersecurity Into Operational Resilience

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

Subscribe now

Subscribe now

Cybersecurity companies often reach an inflection point when technology validation gives way to the harder task of building a repeatable commercial engine. For Reclaim Security, that stage is arriving as the company seeks to expand adoption of its approach to automated exposure remediation.

The company has appointed Stephen Wadsworth as Vice President of Sales, giving the veteran cybersecurity sales executive responsibility for Reclaim’s U.S. go-to-market operation. Based in Boston, Wadsworth brings nearly two decades of experience building sales organizations at security companies, including several that were later acquired.

His career includes an early sales leadership role at Luminate Security, which was acquired by Symantec, and most recently leading sales at Entitle through its acquisition by BeyondTrust. He has also held leadership positions at Threat Stack, Banyan Security and Cyolo.

For Reclaim, the move comes at a time when the company is seeking to capitalize on enterprise demand for technologies that can do more than identify security problems.

The Remediation Gap

The security industry has become increasingly effective at finding exposures. The resulting challenge is that security teams can be left with large inventories of issues requiring attention, even as the tools generating those findings continue to improve.

Reclaim has built its platform around addressing that gap. Its AI Security Engineer continuously discovers exposures across endpoint, email, identity, browser and cloud environments, then plans business-aware fixes and executes them.

The company describes its approach as preemptive exposure remediation, with the technology designed to operate across an organization’s existing security stack. Instead of adding another dashboard, Reclaim aims to make the security tools enterprises already own more effective by helping turn findings into implemented fixes.

Wadsworth sees that distinction as increasingly important to security leaders.

“I’ve spent my career skating to where the puck is going,” said Wadsworth. “CISOs don’t need more security tools, they need more value from what they already pay for. Every CISO I’ve spoken to in the last 6–12 months is tired of being told they have more problems to fix. The market is hungry for outcomes. As adversaries increasingly abuse frontier models at scale, continuous, real-time prevention needs to be the focus — and Reclaim is built to turn findings into implemented fixes without disruption.”

Why Wadsworth’s Background Matters

The new sales chief arrives with a résumé closely tied to emerging cybersecurity companies moving toward larger strategic outcomes.

At Luminate Security, Wadsworth was an early sales leader before the company was acquired by Symantec. At Entitle, he most recently led sales before its acquisition by BeyondTrust. His experience also spans Threat Stack, Banyan Security and Cyolo.

That background is relevant to Reclaim as it builds its U.S. revenue operation. The company is not simply adding a sales executive to an established business; it is looking to scale commercial momentum around a category it believes is becoming increasingly important to enterprise security teams.

“Stephen has built the sales organizations behind some of the most consequential security companies of the last decade,” said Barak Klinghofer, co-founder and CEO of Reclaim Security. “The industry has spent ten years getting better at finding and prioritizing exposures and barely moved on fixing them. Visibility without remediation is noise. With Stephen leading sales, we’re scaling the team that fixes what everyone else only finds.”

Reclaim’s Next Growth Phase

The appointment follows a period of funding and customer momentum for Reclaim. In March 2026, the company announced a $20 million Series A led by Acrew Capital, with participation from QP Ventures and Ibex Investors, bringing its total funding to $26 million.

Reclaim has also published customer results involving Telit Cinterion, Pine Gate Renewables, Competitive Power Ventures and Aqua Security, among others. The company says its customers use the platform to turn lists of findings into implemented fixes, typically demonstrating value within a 10-day proof of value.

That customer proposition sits at the center of Reclaim’s growth strategy. Rather than asking enterprises to add another layer of security visibility, the company is positioning remediation as the outcome that matters.

Wadsworth’s appointment gives Reclaim an executive whose previous experience includes building sales organizations during pivotal moments for security companies. His immediate task will be to translate that experience into growth for a company betting that the next evolution of exposure management will be measured less by what security teams discover and more by what they successfully eliminate.

Subscribe now

Subscribe now

Maurizio Imperadore, Head of the Cybersecurity Team at Connect S.p.A., brings a network engineering background to the CISO role, with experience spanning telecommunications, network design, Cisco and HP systems, and Session Initiation Protocol (SIP). His approach to cybersecurity is grounded in operational resilience: making the most of existing security investments, maintaining strong identity controls, and ensuring security decisions are tied to business continuity.

In this edition of CISO Tips, Imperadore shares practical lessons on where security teams should focus their time and resources. From enforcing zero exceptions on MFA to replacing lengthy risk reports with a single-page executive dashboard, his advice centers on reducing noise, communicating risk in financial terms, and building a security program that protects the operations the business depends on most.

Before you buy any new security tool, first…

Ensure you are fully utilizing the native security capabilities of your existing stack.

What’s one rule you enforce on your team that other teams would find strict?

Zero exceptions on MFA and identity verification, even for emergency admin actions.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

The 80/20 rule: 80% on core operational resilience and visibility, 20% on new security innovation.

What’s one line that works when asking the board or CFO for a budget?

“This isn’t an operational expense; it’s the cost of keeping our core revenue streams online.”

What should a CISO cut from their program tomorrow with zero regret?

Outdated annual compliance training that tick boxes without changing user behavior.

What’s your 60-second test for whether a vendor pitch is worth your time?

If they can’t clearly articulate the specific problem they solve without using buzzwords in the first minute.

What’s one meeting, report, or process you eliminated, and what replaced it?

Eliminated lengthy monthly risk slide decks and replaced them with a dynamic single-page executive dashboard.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Pausing to establish clear incident roles and dedicated communication channels before touching systems.

What’s one question every CISO should ask their team this week?

“Which alert or process is generating the most noise and wasting your time?”

What’s a phrase or framing you use to translate a technical risk for executives?

Translating technical vulnerabilities directly into financial downtime: “If X fails, core operations stop for Y hours at a cost of $Z.”

What’s your best tip for surviving the CISO role in exactly five words?

Prioritize relentlessly, delegate, rest daily.

More tips from the series:

• CISO Tips: Jigar Shah on Buying Fewer Tools, Building More Trust

• CISO Tips: Andy Curtis on Turning Cybersecurity Into Business Risk Decisions

• CISO Tips: Carlos García Batista on Turning Cybersecurity Into Operational Resilience

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

Subscribe now

Subscribe now

For many security leaders, the biggest challenge isn’t keeping up with the latest threats; it’s ensuring cybersecurity remains aligned with business priorities. Jigar Shah, Chief Information Security Officer at Medusind, believes the most effective CISOs are those who focus less on accumulating security technologies and more on solving real business problems. Drawing on more than two decades of leadership across healthcare, financial services, banking, retail, and consulting, Shah has built his career around connecting cybersecurity, technology, business strategy, and governance.

In this edition of CISO Tips, Shah shares the principles that shape his leadership approach, from evaluating vendors based on business outcomes rather than product features to eliminating “security theater” that adds complexity without reducing risk. He also explains why trust, not technology, is the foundation of every successful security program, and why CISOs should spend far more time preventing tomorrow’s incidents than reacting to today’s.

Complete this sentence: “Before you buy any new security tool, first...”

“...understand the business problem you’re trying to solve.”

Technology should never drive strategy. If you can’t explain the business outcome in one sentence, you probably don’t need another security tool.

“Buy fewer tools. Solve more problems.”

What’s one rule you enforce on your team that other teams would find strict?

“Never bring me a security problem without at least one business-focused solution.”

I don’t want my team to be known for just identifying risks. I want them to be known for enabling the business safely.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

I follow a simple rule: 80% enabling the business, 20% fighting fires.

If I’m spending more time reacting than enabling, we’re investing in symptoms instead of resilience. Spend 80% preventing tomorrow’s incidents or issues that can become an incident and 20% responding to today’s.

What’s one line that works when asking the board or CFO for a budget?

I’m not asking you to fund cybersecurity; I’m asking you to protect the business strategy you’ve already approved. That changes the conversation from cost to business enablement.

What should a CISO cut from their program tomorrow with zero regret?

Security theater. Anything that looks impressive but doesn’t measurably reduce risk or improve resilience. Examples include reports nobody reads, meetings without decisions, and controls that create more friction than value.

“If it only checks a box, cut it.”

What’s your 60-second test for whether a vendor pitch is worth your time?

I ask three questions:

1. What business problem do you solve?

2. Can you prove measurable outcomes? Give an example of how you turned things around for your customers?

3. Why are you different from the ten vendors I met this month?

If they answer with features instead of outcomes, the meeting is probably over.

“Features sell products. Outcomes earn meetings.”

What’s one meeting, report, or process you eliminated, and what replaced it?

I eliminated long weekly status meetings. We replaced them with a live dashboard and a 15-minute decision meeting. The goal isn’t to exchange information. The goal is to make decisions and have an action plan with outcomes.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Defining who’s making decisions. Everyone starts investigating. Very few establish clear incident command. Without decision ownership, technical excellence becomes organizational chaos.

What’s one question every CISO should ask their team this week?

“If you were attacking us tomorrow, where would you start?” It changes the conversation from compliance to adversarial thinking.

Alternative: “What are we doing today simply because we’ve always done it?”

What’s a phrase or framing you use to translate a technical risk for executives?

I rarely talk about vulnerabilities. I ask: “What happens to revenue, customers, operations, or reputation if this control fails?” Executives don’t invest in CVEs. They invest in protecting business outcomes. I frame it in business results, risks, and revenue.

What’s your best tip for surviving the CISO role in exactly five words?

“Build trust before a crisis happens.” Because that’s really the essence of the CISO role. Technology changes. Threats evolve. But the ability to build trust with executives, employees, customers, regulators, and your team is what ultimately determines your success.

More tips from the series:

• CISO Tips: Andy Curtis on Turning Cybersecurity Into Business Risk Decisions

• CISO Tips: Carlos García Batista on Turning Cybersecurity Into Operational Resilience

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

• CISO Tips: Paul Blahusch on Business Success Coming First

Subscribe now

Subscribe now

The software supply chain has become one of cybersecurity’s most attractive targets, largely because attackers no longer need to compromise thousands of organizations individually. Instead, infiltrating a single trusted dependency can create a ripple effect across countless development environments. That scenario played out this week when Upwind became the first to publicly report a malicious release of the widely used npm package Keyv, warning developers that the compromise had the potential to impact a massive portion of the JavaScript ecosystem.

The discovery centered on keyv@6.0.0, a malicious version of one of npm’s most heavily used packages. With approximately 154 million weekly downloads, Keyv serves as a core dependency for thousands of JavaScript applications, making any compromise particularly significant. Upwind’s findings prompted immediate guidance for organizations to remove the affected version and investigate whether sensitive credentials had been exposed.

A Malicious Update Hidden Inside a Trusted Package

According to Upwind, the compromised release introduced a previously unseen preinstall hook that executed automatically during installation. Rather than changing the package’s expected functionality, the attackers inserted an obfuscated loader designed to run before developers ever began using the library.

The loader downloaded the Bun runtime from GitHub Releases before launching a bundled payload capable of harvesting credentials from developer workstations and CI/CD environments. Among the targeted secrets were AWS credentials, GitHub tokens, npm authentication tokens, and HashiCorp Vault credentials, giving attackers a potential pathway into both development infrastructure and cloud environments.

“What makes this incident particularly significant is the package’s reach,” Upwind wrote in its public disclosure. “With approximately 154 million weekly downloads, keyv is a foundational dependency used across thousands of JavaScript projects, dramatically increasing the potential blast radius of the compromise.”

That reach transformed what could have been an isolated package compromise into an incident with ecosystem-wide implications.

The Attack Expanded Beyond Keyv

As researchers continued analyzing the incident, evidence emerged that the campaign had spread beyond the original Keyv release. Multiple malicious package versions were identified across the npm ecosystem, suggesting that stolen publishing credentials enabled attackers to distribute poisoned releases through additional packages.

Because package versions and “latest” tags changed rapidly as maintainers responded, security experts advised organizations to inspect their resolved dependency versions, lockfiles, and software bills of materials rather than relying solely on package registry listings.

The malware reportedly went well beyond credential theft. Analysis indicated it could collect authentication tokens, cloud credentials, private keys, and other sensitive information from developer machines and CI/CD runners. Some reports also described functionality capable of republishing compromised packages using stolen npm publishing access, increasing the possibility of automated propagation throughout the ecosystem.

Although the total number of affected packages continued evolving throughout the response, the campaign demonstrated how quickly attackers can leverage trusted software distribution channels once publisher credentials are compromised.

Trust Alone Is No Longer a Security Strategy

One of the more concerning aspects of the incident is that the compromised package reportedly passed through legitimate software release workflows.

Modern software supply chain protections, including provenance and build attestations, can verify how software is built, but they cannot always determine whether malicious code entered the development pipeline before those trusted processes began. As a result, organizations increasingly need visibility into dependency behavior—not just whether software was signed or built correctly.

The incident also reflects a broader shift in attacker strategy. Instead of focusing exclusively on exploiting deployed applications, threat actors are increasingly targeting developer tools, package managers, and build environments where a single successful compromise can reach thousands of downstream users.

A Reminder That Popular Packages Are Valuable Targets

For organizations using Keyv, Upwind urged immediate action: remove keyv@6.0.0, pin dependencies to a verified clean version, rotate credentials if the malicious release was installed, and review CI/CD pipelines, lockfiles, and SBOMs for exposure.

“This incident is another reminder that highly trusted, high-volume dependencies remain prime targets for supply-chain attackers-and that a single malicious release can have ecosystem-wide consequences,” Upwind said.

The discovery serves as another reminder that software supply chain security extends beyond vulnerability management. Even trusted, widely adopted open-source components can become attack vectors when release pipelines or publisher credentials are compromised. By identifying the malicious Keyv release early, Upwind’s disclosure highlighted both the speed at which these campaigns can unfold and the importance of continuously monitoring the behavior of software dependencies, not just the software itself.

Subscribe now

Subscribe now

Andy Curtis is an experienced cybersecurity leader and CISO with a background in information security implementation, architecture, and strategic security programs across government, finance, and enterprise environments. As CISO at Gadget Access, he has worked across frameworks including ISO 27001, NIST, and Essential Eight, helping organizations strengthen their security posture while aligning cyber initiatives with broader business priorities. His approach combines hands-on technical expertise with a strong understanding of risk, governance, compliance, and the realities of operating security programs at scale.

In this edition of CISO Tips, Curtis shares a practical perspective on making cybersecurity more effective by connecting technical decisions to measurable business outcomes. From avoiding unnecessary security-tool sprawl and translating vulnerabilities into executive-level risk, to testing incident response plans and proving that backups can actually support recovery, his advice centers on one core principle: security teams should focus less on collecting tools and metrics and more on reducing material risk. For Curtis, that means learning to communicate in the language of business, making informed trade-offs, and ensuring that cybersecurity decisions ultimately support the organization’s ability to operate and recover.

Complete this sentence: “Before you buy any new security tool, first...”

...prove it will reduce a material risk—and prove you can operate it.

The license fee is only the admission price. The real cost includes implementation, integration, data ingestion, training, tuning, support, additional infrastructure, operational headcount and the time required to investigate whatever the new dashboard turns red.

I am a supporter of best-of-breed technology when an organization can afford best-of-breed integration and operations. Otherwise, you can end up with several excellent products collaborating mainly through their invoices.

Sometimes a well-integrated platform delivers a better overall outcome than a collection of individually superior tools with gaps between them. Equally, consolidating everything onto one platform simply because the vendor has an attractive bundle can introduce lock-in and concentration risk. The right answer depends on coverage, interoperability, operational maturity and the risk being treated—not which logo appears highest on an analyst diagram.

A vendor-sponsored 2025 survey of 1,000 executives found that participating organizations were using an average of 83 security solutions from 29 vendors. That does not prove platforms are always better, but it does confirm that integration overhead is not something CISOs have collectively imagined after too much coffee.

The CISO’s job is not to assemble the most impressive security-tool collection. It is to achieve the greatest sustainable reduction in risk for the money available.

What’s one rule you enforce on your team that other teams would find strict?

Everyone in the security team must be able to explain their work in business, executive, and risk language.

I do not expect every analyst or engineer to become a miniature CFO. I do expect them to understand the business service they are protecting, the risk scenario they are changing, the consequence of doing nothing, and the decision required from management.

“We have 4,700 vulnerabilities” is information.

“Three internet-facing vulnerabilities create a credible path into the customer payments environment, and the remediation owner needs an approved outage before Friday” is decision support.

A technical finding without business context is unfinished work.

This is not about dumbing down the technical truth. It is about expressing that truth in the operating language of the audience. Executives generally think in terms of objectives, exposure, obligations, trade-offs, money, customers and accountability. Security professionals should be able to move between those concepts and the technical detail without losing accuracy in either direction.

Current ASD guidance explicitly treats business acumen, communication and relationship-building as core CISO capabilities, and expects cyber reporting to translate security issues into operational, financial and legal risk. I apply that expectation across the team rather than reserving it for whoever attends the board meeting.

CVSS 9.8 may be technically correct. It is rarely a complete executive sentence.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

My starting ratio is 50:50.

Roughly half of the program should be driven top-down by material business risks: critical services, crown-jewel data, regulatory obligations, credible threat scenarios and the consequences the organization genuinely cannot tolerate.

The other half should be driven bottom-up by operational reality: unsupported systems, excessive privileges, weak configurations, failing backups, poor asset visibility, incomplete logging and all the low-hanging fruit that has somehow remained on the tree for six budget cycles.

The top-down half prevents the security team from becoming extremely efficient at fixing the wrong things. The bottom-up half prevents the enterprise risk register from becoming a beautifully formatted description of controls that do not actually work.

NIST CSF 2.0 reinforces this linkage: practitioners implement and measure risk treatment activities, while executives integrate cyber risk information with the organization’s wider enterprise risk decisions. Both views are necessary because neither strategy nor telemetry is sufficient by itself.

I use industry spending benchmarks and breach-cost studies as reasonableness checks, not as allocation formulas. “Our peers spend 12 percent” does not tell me whether our identity architecture is sound, whether our backups restore or whether half the estate is running on something last patched during the Howard government.

The ratio is a compass, not a religion. It should move as risks, maturity and business priorities change. Incidents, in particular, have very little respect for resource-allocation models.

What’s one line that works when asking the board or CFO for a budget?

“It is cheaper than one material breach every five years.”

That line gets attention. It does not, by itself, earn approval.

The next slide needs to contain the arithmetic: the credible scenario, the business services affected, the potential outage, the likely response and recovery cost, the customer and regulatory consequences, and how much the proposed investment will reduce either the likelihood or the impact.

The argument should not be, “Cyber incidents are expensive, therefore approve everything in my spreadsheet.” It should be, “Here is a plausible loss scenario, here are the available treatment options, here is what each option costs, and here is the residual exposure under each choice.”

IBM’s 2025 study reported a global average breach cost of US$4.4 million across the organizations studied. That is useful context, but a generic worldwide average is not a substitute for understanding your own economics. A CFO should see the potential interruption to your services, your revenue, your customers and your obligations—not an impressive-looking number borrowed from somebody else’s breach.

Fear may secure a meeting. Credible options, quantified assumptions and transparent trade-offs secure a budget.

What should a CISO cut from their program tomorrow with zero regret?

Raw technical reporting to executives who cannot reasonably act on it.

I would immediately cut the 40-page reports filled with vulnerability counts, firewall events, malware detections, phishing statistics, and screenshots from security products. That information may be valuable to security operators, engineers and control owners. It is usually not useful in its raw form to a board or executive committee.

Executive reporting should answer a smaller set of harder questions:

What important business service is exposed? What is the credible scenario? Is the exposure increasing or decreasing? Are the relevant controls working? Who owns the treatment? What decision or intervention is required, and by when?

The underlying technical evidence should still exist. It should simply be presented at the level where someone can use it.

AICD guidance recommends that board reporting go beyond isolated technical measures and traffic lights to include risk outcomes, relevant threats and trend information. ASD guidance similarly expects reporting to be structured around business functions and to cover risk profiles, key systems, uplift activity, incidents and expected returns on security investment.

A board pack is not a SIEM export wearing a tie.

What’s your 60-second test for whether a vendor pitch is worth your time?

I ask one question:

“In one minute, explain the problem you believe we have, the measurable outcome you will improve, and what we can stop doing if your product works.”

A good vendor will have asked enough questions to understand the environment, the existing controls, the operating model, the constraints and the outcome we are trying to achieve.

They will also be able to discuss implementation effort, dependencies, staffing requirements, data quality, integration limitations and where their product is not the answer.

A weak vendor will respond with the company origin story, three analyst quotations, the phrase “single pane of glass” and an urgent announcement that artificial intelligence has changed everything since Tuesday.

I am also interested in whether the proposed solution replaces or simplifies anything. Adding one more console, agent, data lake, workflow and set of alerts is not necessarily an improvement simply because the demonstration contains a colorful attack graph.

Current ASD procurement guidance emphasizes supplier transparency, security track record, lifecycle considerations and clear allocation of responsibilities between customer and supplier. Those are much better indicators of a sustainable relationship than the smoothness of the demonstration environment.

Any vendor can demonstrate a dashboard. The grown-up conversation is about the operating model.

What’s one meeting, report, or process you eliminated, and what replaced it?

I eliminated the vulnerability meeting that consisted of security reading scanner results aloud to people who were quietly reconsidering their career choices.

It was an activity meeting rather than a risk meeting. We could spend an hour discussing thousands of findings without answering the most important question: which weaknesses create a credible path to material business impact?

I replaced it with an application and business-service risk review.

Instead of beginning with vulnerability volume, we begin with business criticality, internet exposure, sensitive data, identity and privilege pathways, known exploitation, exploit probability, compensating controls, remediation ownership, and trend. The scanner results still provide evidence, but they no longer dictate the agenda.

This matters because no single technical score represents organizational risk. FIRST’s EPSS estimates the probability that a vulnerability will be exploited, but explicitly warns that it is not a complete risk score. Asset purpose, value, accessibility, controls and potential impact must still be considered.

We use RAG reporting because it gives executives a rapid view of hotspots and creates some healthy competition between teams. But RAG is navigation, not analysis. Green is not a control, and red is not a diagnosis. A red customer-payment platform and a red internal test server are not equivalent merely because PowerPoint has assigned them the same shade.

The new discussion is not, “Who has the most vulnerabilities?”

It is, “Which application is most likely to hurt us, who owns the response, and is the exposure moving in the right direction?”

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Activating the business response, rather than only the technical response.

Technical teams quite reasonably begin containing the threat, collecting evidence and working out what happened. But a significant incident also needs an incident commander, a decision log, a reliable communications channel and early engagement from the people responsible for legal, communications, business continuity, critical services and executive decisions.

Someone should also be given explicit responsibility for protecting and validating the recovery path. That does not mean immediately restoring systems or connecting backup infrastructure to a potentially compromised environment. It means establishing whether the backups are isolated, current and likely to be usable; whether the associated credentials may be compromised; and whether there is a clean recovery path available when it is needed.

Backups are frequently treated as a magic incantation: somebody says, “We have backups,” and everyone feels better. The useful question is whether we can restore the right services, from trustworthy data, within a timeframe the business can survive.

ASD guidance emphasizes enacting the incident response plan once an incident is identified, while its continuity guidance highlights the need to maintain communications and critical business functions when normal systems are unavailable.

The SOC can contain malware. It cannot, by itself, authorize customer communications, decide whether payroll outranks email for recovery, or explain the situation to the regulator.

What’s one question every CISO should ask their team this week?

“When did we last prove, in practice, that our incident response and business continuity plans work together?”

Not when were they last reviewed.

Not when did somebody update the document footer.

When were they last road-tested under realistic conditions, involving the people, suppliers and decision-makers who would actually be required during an incident?

A meaningful exercise should test decision authority, escalation paths, out-of-band communications, executive availability, legal and regulatory thresholds, supplier contacts, manual business workarounds, backup restoration, service-recovery priorities and the assumptions behind recovery time and recovery point objectives.

It should also expose awkward practical details. Are the emergency contact details stored somewhere accessible when email is down? Can the crisis team collaborate without using the potentially compromised corporate environment? Does the person named as incident commander still work here? Can the backup be restored, or has the organization merely been paying to store it very carefully?

Current ASD guidance requires incident management policies and associated response plans to be exercised at least annually, and separately expects boards or executive committees to participate in planning and exercises for major cyber incidents. For a critical or rapidly changing environment, annual testing should be treated as a floor rather than an aspiration.

A tabletop exercise that ends with everyone congratulating themselves is often just a meeting with a plot.

What’s a phrase or framing you use to translate a technical risk for executives?

I use a structure like this:

“This creates a credible pathway to [critical service] being unavailable or compromised for [period], affecting [customers, operations or data], with a plausible financial impact of [$X–$Y]. We can reduce the likelihood or duration through [action] at a cost of [$Z]. The decision required is [choice].”

That framing translates the technical condition without hiding it. It connects the weakness to a business promise, explains the plausible scenario, acknowledges uncertainty, quantifies the potential consequence and makes the decision explicit.

I also try to make “reputational damage” less abstract. Reputation is not a mysterious cloud that descends after an incident. It can appear as customer attrition, reduced conversion, lost bids, delayed sales, increased support demand, regulatory scrutiny, partner concern or prolonged executive distraction. Where possible, I connect reputation to those observable commercial and operational effects.

The use of ranges is important. Cyber quantification should improve decision-making, not manufacture false precision. Saying the impact is plausibly between $3 million and $8 million, based on stated assumptions, is often more credible than claiming the answer is exactly $5,421,763 because a spreadsheet contains several decimal places.

Both ASD and NIST expect cyber risk information to support broader organizational risk and investment decisions rather than remain isolated in specialist terminology.

Executives do not need a guided tour of the CVE. They need to know which promise to customers it could break.

What’s your best tip for surviving the CISO role in exactly five words?

Learn to talk executive risk.

More tips from the series:

• CISO Tips: Carlos García Batista on Turning Cybersecurity Into Operational Resilience

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

• CISO Tips: Paul Blahusch on Business Success Coming First

• CISO Tips: Diyar Akhmedov on Prioritizing Risk Over Hype

Subscribe now

Subscribe now

For Carlos García Batista, cybersecurity is ultimately about protecting the continuity of essential services. As CISO and Information Security Officer for the Directorate General of Emergencies within the Gobierno de Canarias, he operates at the intersection of critical infrastructure protection, emergency response, operational resilience, and regulatory compliance. His responsibilities include coordinating cybersecurity across technical and operational environments, working with authorities on incident management, and helping ensure that essential services remain secure and available when they are needed most.

That perspective shapes a pragmatic approach to security leadership, one grounded in ownership, accountability, and resilience rather than simply accumulating more tools and controls. From questioning whether a security investment actually reduces operational risk to establishing clear command structures during incidents, García Batista emphasizes the importance of turning cybersecurity into actionable decisions. In this edition of CISO Tips, he shares practical guidance on everything from evaluating vendors and securing privileged access to communicating risk with executives and knowing which security activities are no longer worth the effort.

Complete this sentence: “Before you buy any new security tool, first...”

Before you buy any new security tool, first define the operational risk you are trying to reduce, who will own the tool, who will operate it, and what decision it will help you make.

A tool without ownership becomes another unmanaged asset.

What’s one rule you enforce on your team that other teams would find strict?

No privileged access without a clear purpose, a named owner, traceability, and a review date.

Access should never be granted just because “it may be useful someday.” In security, convenience without control becomes risk very quickly.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

I try to keep a practical balance between prevention, detection, response, and resilience.

If most of the effort goes only into buying preventive controls, the organization may look protected but still be unable to detect, respond, or recover properly. For critical services, resilience deserves budget, time, and executive attention.

What’s one line that works when asking the board or CFO for a budget?

“This is not only a cybersecurity investment; it is an operational continuity investment.”

That framing usually works because it connects security to service availability, institutional responsibility, and business or public-service impact.

What should a CISO cut from their program tomorrow with zero regret?

Security activities that generate reports but do not generate decisions.

If a report, meeting, metric, or control does not help reduce risk, improve visibility, assign responsibility, or support a decision, it should be simplified, automated, merged, or removed.

What’s your 60-second test for whether a vendor pitch is worth your time?

I ask three questions:

What specific risk does this reduce?

How will it integrate with what we already have?

Who in my team will operate it on a bad day?

If the answer is vague, the pitch is not mature enough.

What’s one meeting, report, or process you eliminated, and what replaced it?

I try to eliminate meetings that only exist to exchange information that could have been documented beforehand.

They should be replaced by short, evidence-based operational reviews: what changed, what risk increased, what decision is needed, who owns the next action, and by when.

Security governance should create clarity, not ceremony.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

They often skip defining the incident commander and the decision-making channel.

Many teams start investigating immediately, but without clear coordination, roles, and communication discipline. In an incident, technical work matters, but command structure matters just as much.

What’s one question every CISO should ask their team this week?

“What are we currently accepting as normal that is actually a risk?”

That question usually reveals technical debt, informal exceptions, undocumented dependencies, weak ownership, or processes that only work because one person knows how to keep them alive.

What’s a phrase or framing you use to translate a technical risk for executives?

I translate technical risk into operational consequence.

Instead of saying, “We have a vulnerability in this system,” I prefer to say, “If this fails or is compromised, this service may be unavailable, this decision may be delayed, or this operational capability may be affected.”

Executives need to understand impact, not just threat language.

What’s your best tip for surviving the CISO role in exactly five words?

Govern calmly, document, prioritize, breathe.

More tips from the series:

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

• CISO Tips: Paul Blahusch on Business Success Coming First

• CISO Tips: Diyar Akhmedov on Prioritizing Risk Over Hype

• CISO Tips: Peter Egyed on Why Consistency and Prioritization Strengthen Cybersecurity

Subscribe now

Subscribe now

The traditional corporate endpoint was built around a simple premise: organizations knew which devices employees used and could largely control the software installed on them. That model is becoming harder to maintain as AI agents, browser extensions, MCP servers and code packages become embedded in daily work.

Bloom Security is launching with the goal of addressing that growing complexity. The Tel Aviv-based company has emerged from stealth with a $20 million seed round led by Glilot Capital Partners, with participation from Ten Eleven Ventures (1011vc), Okta Ventures, and Runtime Ventures. Axios first reported about the company’s launch and funding.

The funding also includes prominent angel investors, including the founders of Dig Security, Demisto, Snyk and Talon. Bloom said its platform is already deployed at dozens of large enterprises across the United States and Europe, giving the startup an early foothold as companies look for ways to manage the security implications of rapid AI adoption.

The New Software Perimeter

The challenge Bloom is targeting goes beyond the traditional definition of endpoint security. Employees are increasingly assembling their own software environments through AI tools, extensions and other applications, while browsers, IDEs and AI agents introduce marketplaces that can expand the number of tools operating on a corporate device.

For security teams, the issue is not necessarily that these tools are malicious. Instead, legitimate software can become a source of risk because of how it is configured, what permissions it receives or how it interacts with other systems and data.

“In the AI era, the employee device is no longer just a managed endpoint,” said Itay Keren, Co-Founder and CEO of Bloom Security. “Every endpoint is now running software no one reviewed, connecting to services no one provisioned.”

Bloom points to a range of potential risks, including AI agents with incorrect configurations, plugins that have excessive data permissions, screen recorders operating on executive devices and code libraries that pull from untrusted sources. These scenarios can create attack paths that traditional endpoint detection and response products may not have been designed to identify or manage.

“As AI adoption accelerated, it became clear that existing endpoint controls were not designed for this new reality,” Keren added. “Security teams need a way to understand, govern, and control modern tools without disrupting how employees work.”

Understanding Risk in Context

Bloom Security’s platform is designed to give organizations a broad inventory of what is running across their endpoints, including software, tools, extensions and code. It also examines how those components interact with data and systems and analyzes supply-chain risk, configurations and permissions.

The company is taking a contextual approach to determining exposure. Its premise is that the risk associated with a particular application can vary significantly depending on the employee using it and the environment in which it operates.

“The same tool can be completely acceptable on one endpoint and high-risk on another,” said Ofir Balassiano, Co-Founder and Chief Product Officer at Bloom Security. “Risk depends on context: the user’s role, their access to sensitive data, the other tools operating on that endpoint, their configurations, and how everything interacts. Bloom Security was designed to evaluate that context in real time.”

The platform is also designed to let security teams take action based on those assessments. Bloom says organizations can block risky installations before they reach employee devices, enforce secure configurations and remediate risks without manual approval workflows.

That combination of visibility and enforcement is central to the company’s positioning as it targets large enterprises navigating AI adoption at scale.

Building From Enterprise Security Experience

Bloom’s leadership team has backgrounds at several established cybersecurity companies. CEO Itay Keren previously held engineering and sales engineering leadership roles at Palo Alto Networks, Dig Security and Demisto. Chief Product Officer Ofir Balassiano led the Cortex Cloud Posture Security research group at Palo Alto Networks and previously worked at Dig Security and XM Cyber.

Chief Technology Officer Itay Frishman built AISPM and DSPM solutions at Palo Alto Networks and Dig Security, alongside earlier cybersecurity research and development experience. Bloom currently has 30 employees, many of whom previously worked together at Dig Security.

“While this is technically our first company as founders, our team has built and integrated category-defining products before,” said Itay Frishman, Co-Founder and CTO. “We understand how enterprise security environments operate, and we built Bloom Security specifically for the reality of how endpoints are used today.”

Bloom’s investors see the changing endpoint as an emerging category in enterprise security. Kobi Samboursky, Founder and Managing Partner at Glilot Capital, said the company’s early traction reflects the urgency of the problem.

“AI has changed the enterprise endpoint in ways the security industry is still catching up to. Agents, MCP servers, browser extensions, and code packages now run on every employee’s machine, entirely outside the reach of traditional controls,” said Kobi Samboursky, Founder and Managing Partner at Glilot Capital. “Bloom identified this gap before the market did, and the business traction we’ve seen in their first months is unprecedented for a company at this stage. A team this experienced with a problem this urgent and momentum this strong is what category-defining companies look like from day one.

With $20 million in seed funding and deployments at dozens of large enterprises, Bloom is now focused on a security perimeter that is changing alongside the workplace itself. Its bet is that protecting the AI-native endpoint will require organizations to understand not only what is running on employee devices, but also the context in which that software operates and the access it has to corporate resources.

Subscribe now

Subscribe now

Black Hat USA 2026 takes place August 1 through 6 at the Mandalay Bay Convention Center in Las Vegas, with expert trainings, summits, and main conference briefings covering the technologies and challenges shaping modern cybersecurity. Organizations are contending with AI-driven threats, expanding attack surfaces, cloud complexity, and growing volumes of security data. Vendors are answering with new approaches to detection, response, exposure management, and resilience. What follows is a company-by-company reference to 12 firms worth attention, drawn from the CISO Whisperer watch list.

Upwind

Cloud and AI security handled from the runtime layer. Upwind connects cloud inventory, posture, network topology, applications, and identities, then blends real-time and agentless signals to produce a live view of infrastructure, networks, APIs, and data flows. Faster threat response is the outcome it sells. Placed in the Super Tier.

Cloudflare

A global network for building, securing, and scaling applications, AI agents, and workforces without managing the infrastructure underneath. Cloudflare pushes security, connectivity, and code execution toward users and data. The network spans more than 335 cities and reaches 95% of the world’s population within 50 milliseconds. The company says its network powers 42% of the Fortune 500, which reflects its broad role in the modern internet ecosystem. Super Tier.

Illumio

Breach containment across hybrid and multi-cloud environments. Illumio combines Zero Trust principles, AI-powered insights, and segmentation to detect threats, restrict lateral movement, and contain attacks before they spread. Super Tier.

Arctic Wolf

The Aurora Superintelligence Platform, positioned as a foundation for more automated security operations. Arctic Wolf uses AI agents to help organizations operate at machine speed. Built-in trust controls and human oversight provide validation, governance, and the expertise needed to manage complex security decisions. Super Tier.

Cohesity

Data protection and cyber resilience on one platform. The Cohesity Data Cloud brings data protection, security, recovery, and AI readiness together for hybrid cloud and SaaS workloads, strengthening threat detection, automating cyber recovery, reducing compliance risk, and making enterprise data more useful for AI initiatives. Super Tier.

Veracode

Application risk management across the software development lifecycle. Veracode pairs visibility across code, dependencies, containers, and runtime signals with remediation guidance and AI-driven fixes. The aim is reduced security debt at maintained development speed. Featured Tier.

ThreatLocker

Zero Trust enforcement built on a deny-by-default model. ThreatLocker permits only authorized applications, scripts, and processes to run across endpoints, cloud, and networks. Granular control is applied to prevent ransomware, reduce privilege abuse, limit lateral movement, and make data exfiltration more difficult. Featured Tier.

SafeBreach

Adversarial exposure validation for teams that want proof rather than assumption. SafeBreach tests whether defenses can withstand real-world attack techniques. The SafeBreach Helm platform combines exposure validation, AI orchestration, and existing security technologies to support continuous threat exposure management and measurable risk reduction. Featured Tier.

Mate Security

An agentic SOC designed for the speed and scale of modern threats. Mate Security uses a security context graph to give AI agents a tailored understanding of an organization’s environment, enabling support for detection building, triage, investigations, response, and threat hunting in a continuous cycle. Emerging Tier.

Daylight Security

Managed Agentic Security Services, or MASS, combining AI agents with experienced security professionals. Daylight Security covers managed detection and response, threat hunting, and phishing investigation and response. Its experts help customize detections, build integrations, and improve the context powering its AI systems. Emerging Tier.

Reclaim Security

An AI Security Engineer built to close the distance between identifying exposures and fixing them. Reclaim Security analyzes findings across security tools, understands business context, creates remediation strategies, and can deploy fixes through automated or approval-based workflows. Emerging Tier.

Zero Networks

Automated, identity-driven microsegmentation aimed at containing attacks and limiting lateral movement. Zero Networks applies segmentation to networks, identities, AI agents, and non-human accounts while helping organizations govern AI identities and restrict unauthorized activity. Emerging Tier.

Reading the Roster

Twelve entries, five in the Super Tier, three Featured, four Emerging. Read as a set, the list shows how far the industry has moved toward automation in the space of a single conference cycle. Four of the twelve describe AI agents as part of the product rather than as a roadmap item. Three extend their coverage to non-human identities. Black Hat USA 2026 arrives as AI reshapes both cybersecurity defense and the threat landscape, and the gathering of security leaders, researchers, practitioners, and vendors in Las Vegas will offer a view of how the industry is preparing for machine-speed attacks, autonomous systems, and increasingly complex digital environments.

Subscribe now

Subscribe now

In cybersecurity, effective leadership requires more than deploying the right tools or responding quickly to incidents. It requires a mindset built around continuous learning, attacker thinking, and the ability to translate technical risk into business impact. Sergey Tairyan, Chief Information Security Officer at the Technology Management Center of Yerevan City and founder of OmniSec and Oky.ai, brings more than 15 years of experience building and transforming security programs across industries. His expertise spans security operations, SOC leadership, SIEM and DLP, IAM and PAM, endpoint protection, incident response, and emerging areas such as steganography and post-quantum cryptography.

Known for combining hands-on ethical hacking with long-term security strategy, Sergey approaches cybersecurity with a focus on reducing real-world risk while keeping organizations resilient and operational. His advice reflects that philosophy, from researching a vendor before buying its tools and measuring security decisions in business numbers to prioritizing daily learning and clear leadership during a crisis. In this edition of CISO Tips, Sergey shares the principles, habits, and practical approaches that shape how he thinks about security leadership in an increasingly complex threat landscape.

Complete this sentence: “Before you buy any new security tool, first...”

Before you buy any new security tool, first do OSINT on the company behind it.

What’s one rule you enforce on your team that other teams would find strict?

Two non-negotiable rules:

• All team members must maintain 24/7/365 availability, including weekends, holidays, vacations, and days off.

• Every team member spends one hour daily on learning and research.

In cybersecurity, threats don’t rest and neither does learning.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

65% prevention, 15% detection and response, 20% innovation and research.

AI has shifted the balance toward innovation, but the ratio should continuously adapt to business risk, technology, and the evolving threat landscape.

What’s one line that works when asking the board or CFO for a budget?

The board and CFO understand numbers, not technical details. So, I don’t ask for a security budget; I present a business risk calculation, showing the potential financial impact of an incident, its likelihood, and the cost of reducing that risk.

What should a CISO cut from their program tomorrow with zero regret?

With AI and mature open-source solutions, many enterprise security tools (such as SIEM, security scanners, and password managers) can now be deployed faster, customized, and operated at a fraction of the cost.

What’s your 60-second test for whether a vendor pitch is worth your time?

I present the vendor with 2-3 real security challenges and watch how they respond.

I’m looking for honesty, technical depth, and a problem-solving mindset - not marketing. If they ask the right questions and acknowledge limitations, they’ve earned more of my time.

What’s one meeting, report, or process you eliminated, and what replaced it?

I eliminated meetings focused on what we did and replaced them with discussions on what we learned.

Instead of status updates, we focus on new threats, lessons learned, and opportunities to improve our security posture.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Teams often skip establishing clear leadership.

In a major cyber incident, the CISO becomes the incident commander, directing the CIO, CTO, and other teams to coordinate the response.

What’s one question every CISO should ask their team this week?

What else can we automate to improve our resilience?

What’s a phrase or framing you use to translate a technical risk for executives?

Let’s talk in numbers.

What’s your best tip for surviving the CISO role in exactly five words?

- Learn. Test. Hack. Repeat.

More tips from the series:

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

• CISO Tips: Paul Blahusch on Business Success Coming First

• CISO Tips: Diyar Akhmedov on Prioritizing Risk Over Hype

• CISO Tips: Peter Egyed on Why Consistency and Prioritization Strengthen Cybersecurity

• CISO Tips: Nikolas Oelkrug-Alders on Why Strong Security Starts With the Fundamentals

Subscribe now