'Inside Security' with Nathan Koester (Staff Security Engineer at Ironclad)

In past editions of Inside Security, we’ve explored the evolution of security infrastructure, the burden of compliance, and the critical role of integrations, among other things. But sometimes, the biggest threats don’t live in cloud misconfigurations or zero-days - they live in our org charts.

In this edition, we dive into a raw and honest conversation with Nathan Koester, a seasoned Staff Security Engineer at Ironclad, who has operated across sectors and scale - from the frontlines of dev teams to the policy-driven world of compliance and risk. The insights? Unfiltered. The lessons? Cultural. The takeaway? Security doesn’t fail because of tools. It fails because of people - and how we fail to talk to each other.

Let’s unpack what that means.

A Culture of Pessimism (and Why That’s Not a Bad Thing)

Most industries celebrate optimism. Security demands pessimism. It’s not cynicism - it’s survival. In the role of the security engineer, one is always playing bad cop telling people what they can’t do.

But here’s the kicker: 

That pessimism is productive. It drives security teams to think ahead, assume breaches, and enforce discipline. While engineering teams dream of shipping features, security teams prepare for what happens when those features break, leak, or get exploited.

That tension? It’s not dysfunctional. It’s design. And the sooner organizations acknowledge it, the better they can bridge the cultural divide.

The Collaboration Gap: “I Just Want to Build” vs. “I Just Want to Protect”

Nathan has been on both sides - as an engineer and a security lead. That dual lens reveals a harsh truth: most security teams speak in controls, most engineers speak in velocity. And neither feels heard.

A developer wants to try a new language. A security lead wants a paper trail. The result? You can no longer push code by yourself. You need a review. You need pipelines. And while our job is to make that as painless as possible, the truth is most people don’t want to collaborate.

This is where most security strategies fall apart. Not because the frameworks are wrong - but because the humans don’t trust each other. Security gets framed as an obstacle, not a partner. And that lack of empathy, especially when tools flag critical CVEs or enforce new policies, kills momentum.

So, you’re probably asking yourself or wondering - what’s the fix? Well, it starts by embedding security into the rhythms of product teams - not just the retros!

Why Security Tools Fail (and It’s Not the Tech)

You’ve probably heard the phrase: People are the weakest link in security. But Nathan reminds us that they’re also the biggest lever for progress - if we get the culture right.

Take vulnerability management. With all the scanners, dashboards, and automation at our disposal, you’d think we’d be moving faster. But, we’re not. 

The biggest bottleneck isn’t the tooling. It’s that people don’t ask questions. Because they’re afraid. Afraid of being seen as ignorant. Afraid of friction. Afraid of getting it wrong. This fear blocks communication between engineers and security, between ICs and CISOs, between buyers and end users. Even the best tools - Wiz, CrowdStrike, you name it - become shelfware if the people using them don’t feel psychologically safe.

Which brings us to the most overlooked part of security maturity: your org chart.

Security as a Team Sport: Building Culture, Not Just Controls

Security doesn’t break because people don’t care - it breaks because people don’t connect. The challenge isn’t capability, it’s capacity. Security and engineering often run parallel, but rarely intersect. That’s where things start to slip.

Neither side has the capacity or time to learn from the other, so the collaboration is paramount. Just like I can't learn the code base proficiently, an engineer cannot keep pace with the ever evolving landscape of threats and vulnerabilities.

So, we asked Nathan – what does good look like? His response was a complete tactical vision that could easily be adopted by fast-growing engineering teams:

1. Early and frequent handoffs - share roadmaps and architecture with security before the work starts, not after the code freezes.
   
   
2. Designate security champions - mid-to-senior ICs on engineering teams who act as the bridge. They don’t need to be security experts, but they need access, context, and buy-in.
   
   
3. Triage together - when new branches introduce new risks, have collaborative sessions to determine what’s noise, what’s urgent, and what’s learnable.
   
   
4. Continuously tune tools - don’t assume your scanner is always accurate. Security tooling should evolve with your codebase and threat model.
   
   
5. Create feedback loops post-release - just like product features, security practices need retros, reviews, and iteration.
   

These aren’t just DevSecOps best practices. They are empathy practices. And when you adopt them, security stops being “the team that says no” and starts being ‘the team that helps us build safely.’ 

Security is as much a stakeholder in the product as engineering is. If engineering can't make great products, security is out of a job.

The Real Reason Security Products Miss the Mark

Turn to blogs or LinkedIn, and you’ll see enough chatter about the tooling debate. How much is too much? What exactly should an organization’s security stack look like? And what are the best-in-class tools out there? 

Too many of them rely on death by volume. The issue isn’t capability. It’s user alignment. Buyers - often CISOs or procurement - choose based on vision. But the people implementing it are drowning in alerts, complexity, and half-configured dashboards. And when a vendor’s SE says –– “your team isn’t smart enough to use our product,” that’s not a feature gap - that’s a cultural fail.

What security leaders (and vendors) must remember: Your end user isn’t just the security team. It’s the product owner. The developer. The SRE.

Build for them, not just the buyer.

So, Can CISOs, Engineers, and Vendors Ever Align?

Nathan believes it’s possible. But it requires a shift in posture. Everyone has different pictures of what success looks like, but the key is compromise.

Instead of one tool trying to be everything to everyone, we need platforms that are opinionated - but flexible. Give the engineers an API. Give the CISOs visibility. Give the security team workflows that actually work. And above all, align everyone on the one thing they all care about: outcomes.

Whether it’s fewer breaches, faster triage, or stronger compliance - security is only as strong as the sum of its relationships. You don’t need AI to fix that. You need trust, tooling that fits the org, and the willingness to listen.

Especially with the new AI hype and fear mongering. AI is flawed, but working together can overcome any person's individual deficiency.

Conclusion: Culture Eats Compliance for Breakfast

Security is no longer just about patching CVEs or passing audits. It’s about orchestrating trust across fragmented teams, competing incentives, and overlapping systems.

If there’s one thing to take from Nathan’s insights, it’s this: You can’t solve culture with code. But you can build systems, rituals, and relationships that make security a first-class citizen in the engineering org.

As we think about the next decade of security - with all its complexity, regulation, and AI hype - let’s not forget the human layer. Because in security, culture isn’t just part of the problem. It’s the platform. Everything else builds on top.

We’d like to thank Nathan for his time and insights. If you’d like to connect with him or learn more from his security experience, feel free to reach out via LinkedIn.