Itamar Sher and the art of changing less

Before Itamar Sher was selling a way to repair software, he was taking it apart. His old Symbian phone was among the subjects. So were embedded devices and mainframe switches. He began reverse engineering in middle school, an age when most people are still willing to accept that a phone does what its manufacturer says it does.

There is a useful distinction between owning a device and understanding it. Sher was interested in the second proposition. Years later, that same interest would lead him toward an awkward question for the security business: once you have shown someone everything that is wrong with their software, who is going to fix it?

Today, Sher is CEO and co-founder of Seal Security. The company builds security patches for open source software, including versions that customers already use. Its central idea sounds almost impolite in an industry accustomed to recommending upgrades: sometimes you can repair the dangerous part without requiring an organization to reorganize its life around a new release.

The phone was only the beginning

Sher attended the Israeli Arts and Science Academy from 2006 to 2009. His public education record includes physics and computer science, but also basketball, FIRST robotics and Model UN. The combination makes a pleasantly varied school timetable: machines to build, arguments to make, a ball that occasionally requires leaving the keyboard.

From 2010 to 2015, he worked as a technological researcher in the Israel Defense Forces, serving in Unit 8200. His work involved low-level research. His 2015 conference biography records awards for projects and individual technical work. It is a fairly direct path from investigating what a device does beneath its interface to making that investigation a profession.

By 2015 he was a senior developer at Cymmetria, a cybersecurity startup working in deception. He subsequently became its head of research. The job put him in a peculiar corner of computing: building defenses that depend on an intruder misunderstanding what is in front of them.

A trap can have a trapdoor

A honeypot is a decoy. It looks like something worth attacking, giving defenders an opportunity to observe the person or program that takes the bait. The trouble is that a decoy is also software. It has recognizable behavior, assumptions and, sometimes, vulnerabilities of its own. A burglar who recognizes the police sting has acquired a different sort of opportunity.

In 2015, Sher, Dean Sysman and Gadi Evron presented “Breaking Honeypots for Fun and Profit.” The work appeared at Black Hat and at the Chaos Communication Congress. Its premise was pointed: detect the defensive traps, bypass them, and examine how they could be turned against their operators. Even the equipment intended to watch an attacker deserved a skeptical inspection.

The following year, Cymmetria Research released MTPot, an open source Telnet honeypot credited to Sher, Sysman and Imri Goldberg. Written in Python and distributed under the MIT license, it included configurations for recognizing Mirai activity. Here was a practical contribution to the same field whose assumptions the researchers had been testing.

Its README contains a small piece of programmer comedy. The team recorded an unresolved problem in which a remote Mirai infector crashed after receiving a response it expected. Some people, the authors observed, considered this a feature. The joke works because in defensive computing, a malfunction can occasionally have excellent manners.

“For me, it was really a matter of wanting to be a builder.”

Itamar Sher, 2024

Fifty conversations, one stubborn backlog

After Cymmetria, Sher continued in security research and research leadership, including freelance work for Gilgamesh Cyber Solutions. In 2022, he joined forces with Lev Pachmanov and Alon Navon to start the company that became Seal Security. Pachmanov became CTO; Navon became CPO; Sher took the CEO role.

The founders began with experience on the receiving end of application security tools. Then they spoke with more than 50 organizations. The recurring difficulty was the labor required to keep up with vulnerable open source components. Organizations had tools. They still had patching problems.

Prioritization could make the list shorter while leaving an enormous amount of work. In his account of the founding, Sher described organizations that could remove 70 percent of issues from immediate consideration and still leave developers facing thousands of vulnerabilities. A tidier queue is welcome. It remains a queue.

The founders’ response was to build a process for applying fixes with centralized control and less manual developer involvement. Their experience in exploitation and mitigation suggested that many security changes could be separated from the other changes bundled into a software release. That separation became the business.

The upgrade has other plans

To understand the appeal, consider what an upgrade can ask of a developer. A newer library may contain the desired security fix alongside changes to behavior or interfaces. The security team wants the vulnerability removed. The application team has to establish what else will happen when the replacement arrives.

Sher returned to this coupling in a May 2024 video discussion about AI and open source vulnerability management. Security fixes arrive attached to unrelated code changes, which can make immediate adoption risky. The delay becomes part of the security problem. Knowing that a fix exists does not make installing the whole release a trivial decision.

Backporting takes a fix from a newer line of software and adapts it to an older one. Seal calls its patched dependencies “sealed packages.” The aim is to preserve compatibility while removing a specific vulnerability. It is a promise about the size and predictability of a change, which helps explain why the details of verification matter so much.

In March 2025, Sher announced Seal’s entry into Snyk’s Technology Alliance Partner Program. The arrangement placed the company’s patching approach beside an established vulnerability discovery workflow. For a founder working on the work that follows an alert, that is a sensible place to stand.

Capital arrives; the old code stays

Seal emerged from stealth in February 2024 with a $7.4 million seed round led by Vertex Ventures Israel. Crew Capital, PayPal Alumni Fund and Cyber Club London also participated. The public introduction put Sher’s team in front of an audience larger than the organizations involved in its early conversations.

In July 2025, the company announced a $13 million Series A, again led by Vertex Israel, with Crew Capital, More Investments, SBI Group and CCL participating. Seal said its headcount had more than doubled over the preceding year. The funding was intended to expand both the platform and its commercial operations.

Sher’s explanation centered on the pace of development. As large language models accelerate the production of code, he argued, security work needs help from those models too. Otherwise, the organization gets faster at creating the material it must subsequently inspect and repair. The backlog acquires a better engine.

Seal’s scope now includes application dependencies, Linux operating system packages, containers and older software environments. This is work among the accumulated choices of earlier engineering teams. A system can be old, useful and difficult to replace all at once. Sher’s company is organized around taking that combination seriously.

The latest version needs an introduction

By March 2026, Sher was making another argument about the relationship between security and change. In an essay titled “When ‘latest’ stops being ‘greatest’,” he urged teams to pin their dependencies and make updates deliberate. A package can change outside an organization even when its own application code remains untouched.

The point extends beyond whether a new version breaks something. Passing tests establishes something about the behavior tested; it does not, by itself, establish that an artifact came from a trustworthy process. Compatibility and integrity are separate questions. A malicious package has little incentive to announce itself by failing the build.

This is a consistent concern in Sher’s work: the gap between a comforting signal and the reality underneath it. A defensive trap might be recognizable. A vulnerability dashboard might describe work nobody has completed. A green build might say less about trust than its reassuring color suggests.

His proposed response is controlled movement. Pin what runs, examine changes, use automation to reduce repetitive work, and retain a deliberate process for accepting new code. It is an argument for engineering judgment in a business that can be tempted to treat the newest available version as an answer in itself.

What happens after the machine finds the flaw?

In October 2026, Sher returned to the founding question in an essay about AI-generated findings and patching capacity. He described the work that follows discovery: establish whether a flaw affects the deployed version, locate a fix, adapt it, test it and deliver it. More findings create more obligations unless this work also becomes faster.

His case for AI-assisted repair is therefore quite specific. Use automation to validate the finding, isolate the relevant upstream change, adapt it to the software in use and verify the result. The ambition is to shorten the distance between a discovered weakness and a tested repair.

That brings the story back to the old Symbian phone. The early question was how a thing actually worked. The later question includes the people responsible for keeping it working, the changes they can safely accept and the time they have to make them. Sher has carried a researcher’s suspicion into a builder’s job. There is still plenty to take apart. He has chosen to spend his company’s time putting something useful back.