Security Researchers: Digital Fighters Series
Echo: In security research, “when it works, nothing happens”
Mor Weinberger, Security Researcher at Echo, explains why the most critical vulnerabilities sit in the seams of different digital ecosystems, as part of CTech’s Security Researchers series.
“As a teenager I loved playing computer games, and mostly, I loved winning them," says Mor Weinberger, who leads architecture and research at cybersecurity company Echo. "If you understood a system well enough, you could make it behave in ways its creator never intended. That instinct never went away." Before Echo, Weinberger previously led threat detection engines at Microsoft and served as a founding staff engineer at Argon Security (later acquired by Aqua Security). Today, his milestones include discovering over 250 million artifacts exposed via misconfigured registries, co-authoring the CIS software-supply-chain security benchmark, and speaking at major global stages like Black Hat and KubeCon.
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.
Weinberger describes the security research team at Echo as a small, senior "superstars" team rather than a large "soccer team". As a CNA, one of the few companies in the world officially allocating CVE IDs, the group holds a unique level of authority in the industry. Ultimately, when it comes to the unique characteristics of the security research field, "it's a strange thing to be measured on, because when it works, nothing happens," Weinberger reflects. "But that's the version of the job I want: not being fast at responding to the attack, but being early enough that it never gets built."
You can read the entire interview below.
ID Card
Company name: Echo
Founders: Eilon Elhadad and Eylam Milner
Year of founding: 2025
Current number of employees: 50
Company Description:
Echo is creating the trusted source for agentic-ready software. Rather than scanning for vulnerabilities after they've entered an environment, Echo replaces the supply chain itself, providing continuously vetted, hardened, and maintained versions of open-source containers, libraries, VMs, and sandboxes.
About Echo’s Security Research Team:
It’s a small, senior “superstars” team rather than a large “soccer team”. Everyone graduated from top technological units: 8200, 81 or 49. Working closely with product and engineering, our researchers' work is threefold:
Research that improves Echo's product i.e. investigating the latest attacks, analyzing them, and turning that into a safer offering for our end users.
Positioning Echo as a leader in the domain by finding interesting things no one else found before and explaining them to the world through blog posts, meetups, and live talks at conventions like RSA and Black Hat.
Owning our AI research agents. Echo agents act as security researchers, triaging every new weakness and authoring a fix, and our researchers hold them to the highest standard by building the tools and skills that push their autonomy further.
Echo is also a CNA, one of the few companies in the world officially allocating CVE IDs. Our researchers own that effort too, working with open source maintainers and researchers at other companies to improve the state of security for OSS. Our recent work was with the Cyera research team on a CVE in the AI OSS project, Ollama.
What is your background in cyber, and what led you to specialize in security research?
As a teenager I loved playing computer games, and mostly, I loved winning them. That's what gave me the motivation to understand what was happening under the hood, and to figure out that if you understood a system well enough, you could make it behave in ways its creator never intended. That instinct never went away.
I served as an engineer and later led a team at a technology unit and was awarded outstanding soldier by the Major General. It had a security angle, but the more valuable part was breadth: how systems actually work underneath, and how defensive measures get applied in practice. I then did a BSc in Computer Science.
Shortly after, I got the chance to help build cloud security products at Microsoft in its early days, and that's where the real education happened. I was surrounded by some of the best people in the world on cloud threats, and worked both sides of it – engineering the detection pipeline that handled hundreds of millions of events a day, and writing the detections themselves. The attack surface kept moving underneath us (VMs, Containers, Serverless Functions) so it never got repetitive. The annual red team versus blue team exercise was a highlight: a week-long war game where each side genuinely tries to break the other. There's no faster way to learn what your detections are actually worth.
After my time at Microsoft, I joined Argon, the previous company of Echo founders Eilon Elhadad and Eylam Milner. I believed in the founders and the opportunity. Argon was later acquired by Aqua Security, and that's where supply chain security became my focus. Leading the Innovation Lab, we uncovered a series of supply chain flaws with the research team – work that exposed critical risks in Fortune 100 companies and got real attention from the community. It's also where I started speaking publicly about research, which has been a big part of the job ever since. I came to Echo to work with the same founder again, on a bigger problem and a bigger opportunity.
What does your security research team look like in action?
We're a small, quality team and everyone here has a domain they've gone genuinely deep on. For example, one owns the container and image layer, the second lives in Kubernetes and the orchestration surface, a third is doing low-level operating system and kernel work. And everybody touches on the OSS ecosystem and dependency side.
However, the payoff comes because people cross over. Most of what we find now sits in the seams, where a flaw in one ecosystem only becomes serious because of how a different layer consumes it.
Our starting point is threat modeling the components we already depend on – the open-source pieces everyone in this ecosystem trusts implicitly because they're infrastructure. We look for places where a single flaw has a broad blast radius, and where we're positioned to actually improve the project rather than just report at it.
We also have a source of leads most research teams don't. Patch review runs continuously across a large surface of upstream projects – that's the engine's job, not something we do manually. What the team sees is what the AI layer surfaces out of it: the small number of things that warrant a human look. When something gets flagged in a component we already know well, that's usually the signal to go deep and broad rather than just handle the patch and move on.
How does the research team influence your company at large?
The research team sits under Eylam, our CTO, and it's involved in a lot more than publishing findings. Its real job internally is to keep us building against how the ecosystem actually breaks, not how we assume it breaks.
That shows up most in product design. When we're building new protection against supply chain attacks, research is in the room early, raising the risks and gaps before the architecture is locked rather than after. Part of that is education: making sure engineering understands the real attack paths and not the theoretical ones. Part of it is prioritization – there's always more to defend than there's capacity for, and research is what tells us where the investment pays off. Which components is everyone actually depending on? Where does one weakness have the widest blast radius? Without that input, you can build very thorough protection against something nobody exploits.
The team is also expected to bring new initiatives, not just answer questions we already have. Attackers are constantly finding new angles on open source upstream, and a lot of what we build starts as a research observation: "This is where they're heading next, and we're not covering it." Some of the things we ship today began exactly that way.
Day to day, it works as a loop rather than a handoff. And being a CNA is part of the picture too. It puts us inside the disclosure process rather than downstream of it, so we see vulnerabilities , and where they get stuck, before they reach any public feed. That's useful operationally, but it's also taught us a lot about how strained the disclosure ecosystem has become, and that's shaped how we see our own role in it.
What has been your team’s most significant security discovery to date?
The Black Hat research, specifically, the work we did together with Microsoft's security research team, presented at the Black Hat 2026 conference.
Open source repositories are critical infrastructure, and GitHub is where a large share of supply chain attacks actually begin, yet almost nobody monitors it. Companies run EDR on their endpoints and monitoring across their cloud, and the platform their code comes from stays a blind spot. Working with Microsoft's researchers, we studied dozens of real supply chain attacks from recent years and built a way to detect this kind of activity as early as possible.
In the course of that research, we discovered a stealthy supply chain technique of our own, one that leaves almost no trace for a defender to find. We reported it directly to GitHub's security team and worked closely with them to make it detectable. That's the part I'm most satisfied with: it's protection that now exists for everyone on the platform, not just for our customers. The response at Black Hat was better than we expected, and the coverage since has been encouraging.
Separately, and less visibly, a lot of what we're proudest of comes from working directly with open source projects. We've sat with maintainers on patches that had been left unaddressed and helped get them resolved. And we've gone to companies running open source projects where we'd found gaps that would have opened the door to a supply chain attack, and helped close them before an attacker found them first. Given how far downstream those projects reach, the blast radius we avoided there was enormous. It just never makes the news, because nothing happened.
Who or what is your 'Moby Dick'?
My Moby Dick isn't a single bug, it's a category. What I keep coming back to are the systems organizations trust without thinking about it. The signing infrastructure, the registries, the platforms where code lives and gets built. Nobody audits these the way they audit their own applications, because they're assumed to be enterprise-ready - treated like any other third-party service you buy from a vendor, with someone else accountable for the security of it. And that assumption is exactly what makes them worth so much to an attacker: one flaw there doesn't affect one company; it reaches everyone downstream at once.
The other half of it is timing. The techniques I find most interesting are the sophisticated ones attackers haven't gotten to yet: quiet enough that nobody would notice them being used, and real enough that it's only a matter of time. These are genuine risks sitting there waiting, and the whole point is to reach them first and close them while we still can. It's a strange thing to be measured on, because when it works, nothing happens. But that's the version of the job I want: not being fast at responding to the attack, but being early enough that it never gets built.
How would you characterize the competition between research teams today?
There's a lot of competition, and in Israel especially there’s an unusual density of strong research teams for a country this size. Most of us know each other, and plenty of people have worked together at some point. That closeness raises the bar for everyone.
Globally, the competition is more about attention than about findings. There's real pressure to brand vulnerabilities, get the logo and the name out, and be first to publish. A lot of that is healthy; it pushes teams to do harder work and to explain it well.
But I think the competition framing misses what actually happens. Our Black Hat research this year was done with Microsoft's research team, and it was better for it. They brought a view of the threat landscape we don't have, we brought our expertise in the supply chain, and neither of us would have reached the same place alone.
A smaller example says it just as well. Cyera found a serious vulnerability in Ollama and did everything right, but the CVE request sat unresolved for months, which meant no scanner could see it and nobody knew to patch. They came to us partly because I'd worked with the researcher a few years back. We assigned it as a CNA and published the full record. Different companies, no formal relationship. Just a problem that needed someone to move it forward, and enough trust between people to pick up the phone.
That's the real dynamic. Competitive on visibility, collaborative on substance.
What is your take on the future of the human security researcher?
Echo’s solution is all based on AI Agents doing security research work. So I know firsthand that this is the future.
AI has already changed how we work day to day. It orchestrates our tooling, drives the probing, covers far more surface than a person has patience for. What it doesn't do is decide what's a vulnerability – a human and the deterministic tools still make that call.
Attackers are moving faster than that. Some are already running attacks where AI sets its own objectives and executes end-to-end, with barely a human in the loop. We're not there on the defensive side, and I'm not sure we should be. But the gap is worth paying attention to.
Further, what I don't think changes is judgment. AI is very good at exploring a space; it's much weaker at knowing which part of the space matters. Deciding that a particular component deserves a week of attention because everyone trusts it and nobody's looked – that's still a human call, and it comes from having run these systems in production and knowing where their assumptions get thin.
So the human researcher isn't going anywhere, but the job changes shape.
