Security is often seen as a blocker—something that slows teams down or adds extra steps. But what if it could be part of the product itself? In this conversation, Zishan Khim, Head of Security at Panther Labs, shares how his team builds security into the engineering workflow without slowing anyone down.
At Panther, a cloud-native threat detection platform, Zishan’s team protects customer data, provides security content, and helps employees make safe choices while staying productive. Instead of treating security as an afterthought, they treat it as a feature—something built into the product from day one.
In this episode, Zishan breaks down how that works in practice. From triaging risks and choosing the right tools to writing policy checks directly into infrastructure code, he explains how to build security in without adding friction. The goal? Make it easy for engineers to do the right thing—right from the start.
Security as a Core Product Capability—Not Just Overhead
Security often gets a bad reputation for slowing things down, but it doesn’t have to be that way. Zishan Khim, Head of Security at Panther Labs, believes security should be treated as a core part of the product—just like performance or design. When it’s built into the process from the start, it stops feeling like a barrier and becomes something that adds value, protects users, and strengthens trust.
Changing the Perception of Security in Product Development
Security is often labeled as the “no” team—the one that slows things down. Zishan Khim knows that perception well. In his experience, security is frequently seen as overhead, something that gets added late in the process and makes things harder for engineers. But that view depends on how a company thinks about security—not just culturally, but technically too.
When teams treat security as part of the core product, the conversation changes. It’s no longer a roadblock—it becomes a feature users expect. Just like performance or UX, security and privacy are part of what customers pay for. They may not always ask for it directly, but they assume it’s there. If it’s missing, trust breaks.
Embedding Privacy and Protection into the Product Design Process
Zishan’s team works to build that trust from the start. Instead of bolting on controls at the end, they help teams design with security in mind. That means including it in planning discussions, treating it like any other key feature, and helping engineers ask the right questions early.
This approach only works when security is part of the culture. If engineers see it as something external, they’ll avoid it. But if they’re empowered to think about risk and privacy from day one—and have the tools to do it—they’re more likely to build secure products without losing speed. The shift happens when security isn’t a gatekeeper, but a guide. That mindset clears the path for better adoption, smoother workflows, and fewer surprises later.
Triage and Prioritization: Focusing on What Matters
Avoiding Alert Fatigue with Intelligent Triage
If everything is labeled as critical, nothing truly is. That’s the mindset Zishan Khim brings to his security team at Panther Labs. Instead of pushing every vulnerability or issue to engineering, his team filters and reviews them first. This internal triage helps cut noise, avoid alert fatigue, and build trust across teams.
Engineers are more likely to respond when they know the security team isn’t overloading them with low-impact issues. By reviewing findings, scoring them based on real risk, and narrowing the list, Zishan’s team ensures that when they raise a flag, it matters. This makes security feel less like a burden and more like a helpful signal in the workflow.
Understanding Crown Jewels and Risk Landscape
To triage well, the security team must understand what matters most. That means knowing what systems hold sensitive data, which services are critical, and where the business is most exposed. Zishan calls these the “crown jewels.”
Without that context, it’s easy to treat every alert the same. But when the security team understands the environment deeply—how data flows, what’s valuable, and where risk lives—they can focus on the issues that actually matter. This insight doesn’t just improve prioritization—it makes collaboration smoother. Engineering teams get fewer, clearer, and more relevant tasks, and security becomes a partner—not a blocker.
What “Plugging into the Developer Workflow” Really Means
Shifting Left with Infrastructure as Code
Plugging into the developer workflow isn’t about adding more steps—it’s about meeting engineers where they already work. Zishan Khim shares a clear example using infrastructure as code. Many teams now deploy through tools like Terraform or Pulumi. Instead of waiting until code hits production to flag problems, his team builds policy checks directly into the development process.
With tools like Terraform Sentinel or Pulumi CrossGuard, you can write rules that prevent risky configurations—like public storage buckets or overly permissive IAM roles—before they ever go live. As developers write infrastructure code, it gets scanned against security policies in real time. This lets teams catch issues early, fix them fast, and keep moving.
Automating Policy Enforcement at the Code Level
Early feedback makes everything easier. If a developer gets a warning while writing code, they can fix it on the spot. But if that same issue pops up days later, they have to stop, figure out what changed, and switch context. That delay slows everyone down.
Zishan’s team avoids that by embedding security checks directly into CI/CD pipelines. These automated checks give developers near-instant feedback. It reduces rework, limits back-and-forth, and helps security scale without getting in the way. Instead of creating roadblocks, security becomes part of the natural flow—quietly working in the background to keep things safe.
Tooling Strategy: Capabilities Over Features
Evaluating Tools Based on Existing Developer Workflows
Not every shiny tool is a good fit. Zishan Khim emphasizes that instead of chasing features, security teams should focus on what capabilities they actually need. Before bringing in something new, his team looks at what developers are already using and how security can fit into that flow.
Adding too many tools creates confusion and slows teams down. If the new tool doesn’t work well with existing systems or requires too much effort to maintain, it becomes a burden. The smarter move is to find tools that slide naturally into the developer’s workflow and solve real problems without disrupting progress.
Reducing Operational Overhead for Security Teams
Every tool comes with a cost—especially for the security team that has to run and manage it. Tool sprawl doesn’t just slow you down; it creates scattered data, inconsistent insights, and more upkeep than most teams can handle.
Zishan’s team avoids this by picking tools that do more with less. They look for solutions that integrate cleanly, support their long-term goals, and help them address root issues—not surface-level symptoms. This strategy helps them stay focused, scale effectively, and reduce friction between teams. As a result, security becomes simpler, smarter, and easier to maintain.
Evolving the Security Team: From Plug-and-Play to Security Engineering
Upskilling Security Teams to Keep Up with Developer Needs
Plug-and-play tools used to be enough, but they no longer cut it in modern engineering teams. Zishan Khim points out that today’s security teams need deeper technical skills. Tools won’t understand your environment, your priorities, or what matters to your product. That knowledge has to come from your team.
To support fast-moving development, security must think like engineers. That means building capabilities, writing code, and solving problems at the source—not just reporting them. This shift calls for new skills, new workflows, and a mindset focused on adding value, not friction.
Building and Testing Detection-as-Code Workflows
At Panther, Zishan’s team treats detection rules like software. They write, test, and deploy them through a structured process that mirrors how developers ship features. Each rule is written with clear logic, tested for expected behavior, and run against real historical data before going live.
This approach cuts noise, avoids false positives, and makes alerts more meaningful. It also helps the security team stay efficient—only focusing on what’s actionable and relevant. By using developer best practices like staging, test coverage, and version control, they’ve turned security operations into an engineering discipline that scales with the business.
Shared Responsibility and Developer Enablement
Contributing Templates and Frameworks
Instead of just handing over a policy, Zishan Khim believes security teams should come with ready-to-use solutions. One of the simplest ways to support developers is by building templates and frameworks they can drop directly into their projects. These tools save time, reduce errors, and help security scale without extra back-and-forth.
For example, if your team uses infrastructure as code, the security team can create Terraform or Pulumi templates with safe defaults. On the application side, reusable frameworks can help developers avoid common mistakes like injection flaws or broken auth flows. These ready-to-go resources make it easier to build secure systems without slowing down.
Clarifying Roles Without Slowing Down Delivery
Moving fast doesn’t mean skipping structure. Zishan highlights the importance of clear ownership—knowing who builds, who reviews, and who maintains security-related components over time. Without that, things slip through or pile up.
In some cases, it makes sense for the security team to jump in and build something directly. In others, it’s better to guide engineering teams and give them the tools to do it themselves. The key is balance: contribute when it helps speed things up, enable when it helps teams scale. This keeps momentum high without sacrificing clarity or quality.
Security as a Data Problem
Managing Data Volume and Complexity
Modern security is overwhelmed by data. As companies move to the cloud and adopt more SaaS tools, the amount of log data grows fast—and spreads across more places. Zishan Khim explains that this makes visibility harder and decisions slower.
You can’t treat all logs the same. Not every data source is worth collecting, and not every alert deserves attention. His team focuses on what matters most—high-value logs that help them detect, investigate, or prevent threats. Prioritizing these sources keeps the noise low and the signal clear.
Need for Scalable, Correlated Platforms
Too much scattered data leads to dead ends. To solve this, Zishan’s team treats security like an engineering challenge. They build pipelines that collect, clean, and connect data across systems—making it easier to spot real issues.
The goal isn’t just to gather information, but to make it usable. That means choosing tools that scale, share context, and support smart detection. When data is connected and workflows are clear, security becomes faster, more accurate, and easier to act on.
Conclusion
Zishan Khim’s approach shows that security doesn’t have to be a blocker—it can be part of how teams move faster and build smarter. By treating security as code, focusing on real risk, and meeting developers inside their workflow, his team makes security feel like a natural part of building software. The key takeaway? Empower people, simplify the process, and focus on what matters most. That’s how you build secure products without slowing down.
