Security Researchers: Digital Fighters Series
Island: “AI made it cheap to produce an answer and expensive to trust one”
Idan Revivo, Head of Security Research at Island, explains why human researchers must evolve into research engineers as part of CTech’s Security Researchers series.
“What worries me is a generation of researchers who can prompt a model but never learned to reverse engineer software,” warns Idan Revivo, Head of Security Research at cyber firm, Island. Revivo’s concern comes from his prediction of the future of security research alongside AI, in which he sees “the role moving toward something closer to a research engineer: building the system that does the analysis and having the expertise to check it.” Ultimately, he offers, “AI made it cheap to produce an answer and expensive to trust one.”
Within Israel’s cyber companies are small, highly specialized teams trained to think like attackers, find vulnerabilities and stay ahead of a threat landscape increasingly accelerated by AI. In this series, we meet the individuals and teams who make up this frontline of cyber: the digital fighters.
“A security product is only as current as its understanding of the attacker,” Revivo continues. At Island, he works alongside a senior team of six researchers with complementary specialties. "I describe the team as the compass,” he says. “We do not steer the ship and we do not build it. We tell the rest of the company which way north actually is."
You can read the entire interview below.
ID Card
Company name: Island
Founders: Mike Fey and Dan Amiga
Year of founding: 2020
Current number of employees: 300
Company Description:
Island provides a single environment for enterprise work where organizations govern people and AI agents as they work across devices, browsers, applications, networks, and data. When security and IT are built into the work environment rather than bolted on, the organization keeps full control over its data, and users just log in and work.
About Island's Security Research Team:
We're a growing team of six researchers, all senior, with complementary specialties across malware, web security, phishing, vulnerability research and the AI supply chain. Each person has depth in one area, but any of them can still pick up an investigation and take it wherever it goes.
We also build our own tools and infrastructure. The people investigating threats write the software that helps us analyze large collections of code, extensions and other tools. There's no separate platform team doing that for us. We sit inside the product organization, so our findings feed directly into what Island builds.
What is your background in cyber, and what led you to specialize in security research?
I've been in security research for about twelve years, starting at Check Point working on mobile malware and vulnerabilities. One project that shaped my career was CuckooDroid, an open-source framework for analyzing Android malware that combined code inspection with running applications in a controlled environment.
Presenting that work at Black Hat helped launch my career, but what stayed with me was what happened after we released it: security companies and academic researchers picked it up, used it and extended it. A tool we had built for our own needs became a research instrument for others. That's the outcome I've been chasing ever since.
From Check Point I went to Trusteer, part of IBM, where I led mobile research into threats including malware targeting banking customers. At Aqua Security, I led Team Nautilus and became VP of Cyber Security Research, and now I lead security research at Island.
At Aqua, my team built and open-sourced Tracee, a tool for observing software behavior while it runs, and published research including HeadCrab and perfctl. I also hold two granted U.S. patents on sandboxing untrusted containers and scoring their behavior.
Across those roles, I've kept coming back to the same instinct: building the system that analyzes ten thousand samples. That's what I enjoy most, and every role since has pointed that instinct at a new surface.
What does your security research team look like in action?
Any analysis a researcher does twice by hand should have been automated the first time. The measure of a good week is how much cheaper we made the next hundred investigations.
We choose topics through a combination of external signals and researcher intuition. We watch where attacker activity is moving, but we also give people room to investigate a corner of the ecosystem that simply feels wrong. If you only chase external signals, you're always second.
Our platform combines static analysis, data flow tracing, instrumented sandboxing, graph analysis, and AI-assisted triage. Reading the code tells us what is there, running it tells us what happens, and looking across the population tells us when one artifact is part of a pattern. We apply this to browser extensions, development tools, and MCP servers.
Software supply chains particularly interest us because legitimate and malicious tools can have similar capabilities. Detecting a dangerous capability is the easy part. The hard part is intent. A backup tool needs to send data out; a file manager needs to read files. We ask whether those capabilities fit the stated purpose, whether the behavior is visible to the user, and whether anything has been concealed.
In many of the artifacts we investigate, code is fetched at runtime from a server the author controls, so reviewing the installed package alone cannot tell us everything it will do. We need to understand what it can be instructed to do after installation.
How does the research team influence your company at large?
A security product is only as current as its understanding of the attacker. Product decisions encode assumptions about how people are being attacked, and those assumptions decay. We help keep the company's understanding of the threat landscape current. When someone needs to know whether a threat is real, how it works or whether a product capability would stop it, they come to us.
Our findings become detection logic that helps protect customers. Sometimes they become a feature: when the behavior we would need to detect has not happened yet, the response is to remove the route an attacker could use. When a finding does not fit the current product, it can change what we build next.
Being inside the product organization makes this practical. What we discover can change priorities and what teams build next. I describe the team as the compass. We do not steer the ship and we do not build it. We tell the rest of the company which way north actually is.
What has been your team’s most significant security discovery to date?
I'd point to BadBlocker, our investigation into the browser extension Adblock for YouTube. It came out of routine hunting. At the time of our research, it had more than 11 million installs, a 4.4-star rating, and had been in the store since 2014. Those reputation signals suggested trust, but its permissions and architecture warranted a closer look.
It was meant to block ads on YouTube, yet it requested access to every website, including banking pages and work applications. That mismatch started the investigation. We found a dormant path for its server to supply code that could run inside those pages with the page's privileges.
We tested this using a mock server. In that controlled demonstration, the extension ran code inside a logged-in Salesforce page, read account data visible to the user, and sent it to our test server.
While we did not observe the malicious payload being delivered to users at the time, we had demonstrated a capability that could be activated remotely without a new extension version or another store review.
We also traced the extension's history. It changed ownership around 2018, and related extensions tied to the same developer had already been removed from the Chrome Web Store for malware. Years of accumulated trust had outlasted major changes to the software.
An extension could do the job people installed it for while also containing a route to abuse. Its reputation alone didn't answer the security question. For me, that's the value of looking beyond attacks already under way: identifying a dangerous capability before we observe it being used.
Who or what is your 'Moby Dick'?
The next xz-style backdoor. An attacker gained trust inside a widely used compression project and planted a backdoor that reached into the SSH service used to access servers remotely. The investigation began when an engineer noticed unusual slowdowns and errors. That is what makes it my white whale: a dependency people trusted had become a route into their systems, and discovery depended on someone pursuing an unexpected clue.
What interests me is how much of the operation can look legitimate. The contributor has access, the software has a useful purpose, and the malicious intent is hidden in how the pieces come together. Depending on chance discovery is not a detection strategy. I want us to find the next one with tooling rather than luck.
I worry about that pattern in the AI supply chain. MCP servers, agent skills and plugins are being adopted quickly, often in ecosystems with limited history to help establish trust. My white whale is the malicious dependency that has earned its place in the workflow and is hiding behind that legitimacy.
How would you characterize the competition between research teams today?
I don't spend much time thinking about which research team is ahead. The competition that matters to me is with the attacker, and speed is a big part of it: how long does a new technique remain useful before defenders can recognize it?
Attackers can develop methods privately and reveal them only when they deploy them. They also have access to AI and automation, which can make it cheaper to develop variants and pursue more targets. Research teams need to shorten the time between understanding a technique and being able to recognize it at scale.
That challenge is shared across companies and countries. I'd rather judge our progress by whether we're closing that gap than by how many reports or samples any one team produces. Collectively, I don't think we're closing it yet. That's the problem worth competing on.
What is your take on the future of the human security researcher?
AI gives security researchers an enormous increase in reach and speed. We can analyze more code, investigate more leads and build research tools faster. It is also expanding the attack surface, and attackers have the same tools to find vulnerabilities, develop attacks and automate their work.
Human attention used to act as an accidental limit on attackers. Getting access was one thing; exploring the environment, finding credentials, moving between systems and stealing data still took work. Automating that work makes it practical to pursue many more footholds in parallel. Being too small to be worth someone's time becomes a much weaker protection.
For the human researcher, I see the role moving toward something closer to a research engineer: building the system that does the analysis and having the expertise to check it. The researcher needs to understand why a finding matters and turn that understanding into something the system can use. Expertise is the raw material for better automation.
What worries me is a generation of researchers who can prompt a model but never learned to reverse engineer software. When the model is confidently wrong, someone needs the skills to inspect the code and challenge it. We have to preserve the training that builds that judgment.
AI made it cheap to produce an answer and expensive to trust one.
