Navy Officer Reveals the Threat Modeling Mindset Most Cybersecurity Teams Are Missing

Ben Lipczynski spent 12 years on nuclear submarines before enterprise security. His take on patching, legacy systems, and the CVE avalanche.

Full Metal Packet Episode 10: Ben Lipczynski

Ben Lipczynski has a phrase his colleagues are tired of hearing. When a quarter goes sideways or a target gets missed and the room starts to panic, he looks around and says the same thing. No one's gonna die here.

He earned that perspective the hard way. Before joining Origina as Director of Security and Regulatory Services, Ben spent 12 years in the British Royal Navy, much of it on nuclear submarines, where a wrong move next to high-pressure hydraulics or tons of explosives doesn't get a debrief in the next meeting, but a eulogy.  

On this episode of Full Metal Packet, Yegor Sak and Alex Paguis sit down with Ben to unpack what that environment teaches you about risk, why the industry's patching reflex creates a false sense of safety, and what to do when the CVE count hits numbers no team can keep up with.

TL;DR

  • Before patching anything, check whether the CVE even applies to you. One customer's 700-line scan came down to 20 real actions.
  • Your patch covers less than you think: roughly 60% of enterprise vulnerabilities sit in bundled open source libraries the vendor may not support.
  • Don't upgrade because newer feels safer. Recent major breaches came through social engineering and flat architecture, not old software.
  • Assume the exploit arrives before your change window does. Segmentation and MFA are what protect you in that gap, not patch speed.
  • Your riskiest asset is the one nobody remembers. Cross-check what security sees, what engineering maintains, and what your licenses say you own.

Stand Back and Take a Breath

The submarine service drills one habit into people that Ben says the corporate world has largely lost: the pause. When something goes wrong on a boat, nobody sprints. There's a deliberate pace, what he calls the “marching pace,” because rushing into action next to a nuclear reactor is how people end up dead.

He sees the opposite instinct everywhere in corporate security. A scanner dumps hundreds of CVEs on the desk, the regulation says critical vulnerabilities get patched in 14 days, and everyone scrambles. Nobody stops to ask the obvious questions first.

"Sometimes if you just stand back and go, is that CVE even applicable to me? Am I even using that technology? Have I actually got it deployed? Or if I have got it deployed, what's it doing? Is it just ordering toilet rolls? Or if this stops, does my business stop working?"

The same applies to incident response. It's exciting, people want to jump in, and that urgency produces self-inflicted errors. The teams that handle incidents well already know who's accountable for what before anything happens, because they thought it through in advance instead of improvising at 2 a.m.

That preparation gap is structural. Submarine training runs about three years before your first job, and you can't qualify until you understand every system on the boat and how they interact. Corporate onboarding, in Ben's words, is "three months and a couple of PowerPoints if you're lucky." Commercial industry can't afford military training ratios, but it can afford the habit underneath: knowing your environment well enough that nothing surprises you during a crisis.

How a Water Plant Ends Up on an iPad

One of the more unsettling moments in the episode comes from Yegor. His father works at a municipal water treatment plant and used to do his rounds with a notebook, manually checking gauges. Today he carries an iPad showing every pressure level and chemical flow across the plant. He doesn't have write access from it. But the capability exists. It's a permissions setting away.

Ben has watched this drift play out across his career, and no single step in the chain looks reckless:

"Let's remote it out. Still air-gapped, still within the plant. Then someone goes, well, why can't I do it from the office block across the parking lot? Then it's, why do I need two computers on my desk? And before you know it, you've punched a hole from the internet down to that motor controller, which might be controlling chlorine tanks."

The danger compounds because fear erodes along with distance. The engineer who stood next to the tanks knew exactly what they could do. The analyst monitoring them from home doesn't. Ben once consulted for a wind farm where the turbine-control iPad doubled as the kids' YouTube device in the evenings.

Ben has no problem with remote control of industrial systems in principle. The issue is that an attacker no longer needs to break in on site. Someone inquisitive finds an open port, wonders what the iPad is connected to, and starts opening valves. Add nation-state motive and you have a feasible remote attack on a district's drinking water. Connectivity decisions need controls that scale with them, and the controls usually lag years behind.

The Patching Trap

Here's where Ben breaks hardest from mainstream advice. The industry has spent two decades preaching that legacy is dangerous and the latest version is safe. His experience says otherwise.

Start with what a patch actually covers. Origina analyzed a set of enterprise products and found roughly 60% of their vulnerabilities lived in bundled open source libraries, not the vendor's core code. The vendor's patch may not touch any of that. Read the small print of your support contract: does your OEM support the whole application or just the code they wrote?

Then there's the assumption that patches work. The Log4j cycle in 2021 is his go-to example. The first patch fixed the original vulnerability and introduced four new ones. Two weeks later, another patch for those. Customers ended up trading vulnerabilities for vulnerabilities every fortnight, when most of them weren't even using the component. The right fix was to delete the jar file and move on. That delete-first instinct barely exists in engineering culture, where the reflex is to repair rather than ask whether the thing should exist at all. Yegor pushes the logic to its endpoint in this episode: the most secure software is the one that doesn't exist. Ben's version is more practical. If you're not using it, get rid of it.

Upgrading carries its own risk too. New versions mean new functionality, new attack surface, and new vulnerabilities, bought at the cost of licensing and migration effort. The major breaches of recent years back him up: entry came through social engineering, and the damage came from poor architecture and easy lateral movement. Version numbers had nothing to do with it. Ben's blunter assessment is that patches are "being weaponized" by OEMs to maintain support revenue and keep customers dependent.

The math that makes this concrete: a customer came to Origina with a 700-line vulnerability scan, ready to patch all 700. Analysis found 660 were false positives. Of the remaining 40, existing defenses already covered 20. The real workload was 20 actions. That's patching as one tool in a broader, layered defense, not the whole strategy. Those layers matter most when a patch doesn't exist yet, or can't be applied. Exploits now appear within hours of a CVE announcement while many production systems only get a change window every few weeks. The layers keep you alive in the gap.

This also changes what resilience means. The industry tends to treat it as the ability to recover quickly; the military treats it as the ability to keep operating, even at 30% capacity. Telling customers about a six-week delay is a survivable story. Telling them you can't deliver for six months usually isn't.

Surviving the CVE Avalanche

The volume problem is getting dramatically worse. 2023 produced around 40,000 CVEs, the following years pushed toward 48,000, and this year is predicted to top 50,000, possibly 60,000, before AI-driven vulnerability discovery adds to that volume at industrial scale. Patch-everything dies here, full stop.

NIST is already adapting, prioritizing which CVEs get full documentation based on risk and federal requirements. That means a two-tier system: some CVEs documented properly, others published thin, with no pressure on any OEM to develop a fix. The one that matters to you might land in the thin pile. Triage is shifting onto you whether you want it or not.

The hosts add a prediction worth flagging: with AI agents now parsing CVE feeds automatically, the CVE text itself becomes an attack vector: prompt injection aimed at the tooling that reads it. Both expect to see it this year.

Ben's filter still works at any volume. Of everything published, what applies to technology you run? Of that, what touches systems that matter? Of that, what have your existing controls already neutralized? The list that survives is short enough to act on. The full list never will be again.

Go Talk to Your Engineers

Asked what he'd tell security teams stuck maintaining legacy systems, Ben corrects the premise: security teams usually aren't the maintainers, and that silo is exactly where risk hides.

His advice is almost embarrassingly simple. When a box number shows up on your SOC screen, go ask the engineers what it actually is and what it delivers to the business. Then cross-reference three sources that should agree but rarely do: what security sees on the network, what engineering knows it maintains, and what your licenses say you own. If engineering maintains five nodes and security sees six, that sixth node is either forgotten or shouldn't be there. Either way, it's an unmonitored attack surface no scan report would ever have flagged.

Pressed for a single takeaway, Ben doesn't hesitate: patches aren't a silver bullet. Know yourself, focus on what matters most, and build the layers so that when the patch fails or can't be applied until the next change window, your business is still standing.


Ben Lipczynski is Director of Security and Regulatory Services at Origina, where he helps enterprises secure and maintain legacy software systems outside the standard OEM patch cycle. He previously spent 12 years in the British Royal Navy across submarine and surface fleet operations, working extensively in electronic warfare.

Listen to the full episode on Apple Podcasts, Spotify, or YouTube. Subscribe so you don't miss the next one.