This week, Venture in Security is excited to feature a guest article from Nielet D’Mello. Nielet is a security engineer with nearly a decade of experience designing and scaling secure systems across the software development lifecycle. She has held roles at McAfee, Intel, and currently Datadog, working across consumer, enterprise, and cloud-native security domains. Her work focuses on integrating security into engineering workflows, with an emphasis on threat modeling, developer enablement, and secure-by-design principles. Nielet also shares her perspectives through writing and public speaking, helping bridge the gap between security and software development.
Community announcement – BSidesNYC call for papers is still open.
In addition to amazing technical talks, BSidesNYC has a special ‘Entrepreneur’ track – a space for founders to share real stories and lessons from building security companies. If you’re a founder, this is your chance. It’s rare to find a conference that mixes security/tech with honest startup experiences.
Three tracks are now accepting proposals:
> Technical Talks – Core conference content: red/blue team, privacy, policy, and more.
> Technical Workshops – Longer session of hands-on exercises.
> Entrepreneur Talks – Share what it’s really like to build and scale a security company.
As practitioners in Application Security or Product Security (more broadly), we operate in an interesting space where theory meets reality and often, they do not match up as neatly as we would like. Throughout my experience in application security, I’ve observed a persistent disconnect between how the industry talks about application security and how we actually practice it day-to-day.
Effective AppSec/ProdSec requires connecting abstract security concepts back to first principles and real-world contexts. However, there’s this massive chasm to cross between what we hear at conference presentations about the latest security program win, tooling improvements or AI-powered vulnerability detection/remediation and what we’re actually dealing with in our daily standups: context gaps, integration headaches and the never ending challenge of balancing engineering velocity with security rigor.
I’ve come to realize this isn’t just a communication problem. It’s a fundamental misalignment between vendor categories and real security needs at organizations today. We’ve built an entire ecosystem around theoretical security models that simply don’t match how modern software organizations actually operate.
So what does effective product security actually look like? From my experience across different organizational contexts and the various archetypes we end up embodying, whether as Orchestrators managing diverse complex portfolios, Builders creating scalable solutions, Specialists diving deep into specific domains, or Rapid Responders handling urgent situations-it’s not about having the perfect tool stack or the most comprehensive processes. Effective AppSec works within organizational realities: resource constraints, velocity requirements, legacy technical debt, and yes, the fact that most engineers turn over every 18-24 months.
It’s increasingly getting to the point of building secure systems that developers actually want to use, not security processes they’re forced to endure. And honestly, most of us are still figuring this out as we go.
The theory-practice gap shows up in how we define problems, the solution blind spots that ignore real operational constraints and the market dynamics that reward solving the wrong problems. Until we confront this disconnect, we’ll keep adapting “solutions” to reality – when what we really need is alignment from the start.
Most vendor pitches start with the problems they claim to solve: “We detect vulnerabilities in code!” “We secure your supply chain!”. Or more recently – “AI powered XYZ”.
As Kane Narraway recently wrote about systemic prevention challenges, this dynamic plays out particularly acutely in Application Security workflows. Here’s the thing – these problem definitions often miss what we actually struggle with day-to-day as AppSec practitioners. Here’s how I’ve seen the real problem areas emerge across orgs, through the lens of first principles, not vendor marketing.
The first fundamental security concern is about making informed security decisions without sufficient context about systems, business logic and risks. As practitioners, an example of experiencing this would be getting a Slack ping from one of your service team stakeholders asking – “Okay to store this OAuth token in localStorage? Need to ship by the end of the week.” Seems simple, yet to answer, I need to understand the system’s threat model, token sensitivity, session handling, user privilege boundaries, and downstream data flows. In short, I need all the context that should have informed the question to begin with.
Most vendors frame this as a “visibility” problem and sell asset discovery tools, dependency scanners, or architecture mapping solutions. While these help, they miss the core issue: AppSec teams need contextual intelligence for decision-making, not just more data about what exists. We don’t need more data, we need contextual intelligence to make better decisions, faster. The simplest example would be a SAST scanner that flags 10 SQL injection vulnerabilities across your codebase. It outputs a list of potentially vulnerable code locations. What you actually need is contextual intelligence that tells you the 2 vulnerabilities in your payment processing endpoints with direct database access to customer PII need immediate attention, while the 5 in internal admin functions with read-only access to configuration data can wait until next sprint, and the 3 in rarely-executed error handling paths are deprioritized to be addressed only when spare cycles allow.
This brings us back to the fundamental question: “Given my threat model, business criticality, and deployment timeline, which of these findings actually matter?“. The gap between detection and decision-making remains enormous because most contextual intelligence still lives in experienced practitioners’ heads rather than in scalable tooling.
The second thing being balancing thorough security evaluation with development speed requirements. Product teams want security decisions that don’t slow down development cycles, yet meaningful application security assessment requires understanding business logic, reviewing architectural choices, and often testing implementation details. You’re caught between these two impossible standards: deliver fast, precise answers while building the context foundation that makes those answers meaningful.
From my experience working across different organizational velocities and team structures, this tension manifests differently but it’s always there. You end up providing rapid assessments based on pattern recognition rather than comprehensive analysis, then you absorb the accountability when those quick evaluations miss risks.
The “shift left” movement frames this as a tooling problem – automate security testing earlier in the development process. The “developer-first” security trend treats it as a UX problem – make security tools easier for developers to use. Both approaches help by acknowledging that security must fit into development workflows. However, the assumption centers around the core issue being tool placement or interface design, not the fundamental tension between speed and thoroughness.
The next problem area is the intricate balance of making tools, people, and processes (the triad of success for AppSec at any organization) work together under real-world resource constraints. Here’s a scenario we commonly see: there’s the SAST tool, SCA scanner, DAST setup, and CSPM monitoring. Each vendor promised their tool would solve specific vulnerability classes, but somehow AppSec teams spent months on integration work, writing custom scripts, and doing ongoing maintenance (the infamous, unthanked KTLO work) to make everything actually work together. The vendor pitch was “just add this tool,” but the reality is that you’re now running a mini-IT operation just to keep your security stack functional.
Let’s also be real about resources – most of us are operating below what researchers call the “security poverty line.” Post-ZIRP budget constraints have made tool acquisition challenging, and security work is competing directly with feature development for engineering attention. You’re trying to build a comprehensive security program with constraints that vendors rarely acknowledge in their demos.
The more I’ve worked within resource constraints or even chatted with my industry peers on their experiences, I’ve learned that success isn’t about having the perfect tool stack. It is about making thoughtful trade-offs and building solutions that actually work within our operational realities. Most vendors treat this as separate problems: “platform consolidation” (buy all tools from one vendor), “orchestration” (connect tools with APIs), or “automation” (reduce manual work). The categorization helps by acknowledging that tool sprawl is real.
However, these vendor approaches miss a fundamental issue: they’re solving at the wrong abstraction layer entirely. Here’s what the AppSec tooling landscape actually looks like when mapped against practitioner needs:
This reveals why the integration complexity challenge persists. Vendors are heavily investing in the bottom layers where practitioners have the least operational pain, while practically ignoring the upper layers where teams struggle most with daily decision-making and organizational scaling. The top three layers represent where practitioners spend most of their cognitive energy, yet they remain largely unaddressed because they’re much harder to productize.
How do you scale security without turning practitioners into organizational glue? Structuring AppSec teams and responsibilities as organizations grow without losing effectiveness is another problem worth highlighting.
One thing I’ve observed across different organizational contexts is that the same Application Security/ Product Security Engineer job title encompasses radically different responsibilities depending on organizational constraints. You often end up stacking different archetypes as you gain experience, transitioning between fundamentally different skill requirements based on organizational needs rather than what might be optimal for security outcomes.
Most vendors assume uniform team structures and responsibilities, building for the generic application/ product security team. When they acknowledge organizational differences, it’s usually around company size (enterprise vs. startup) rather than operational models or role archetypes. This hampers more than it helps by creating systematic mismatches between how security work actually happens and how vendors position solutions. Different organizational archetypes need fundamentally different tooling approaches but the market largely ignores these structural realities. Consider the stark reality of how organizational context shapes tooling needs. High-velocity organizations shipping code continuously throughout the day are averse to security tools that add friction to their deployment pipeline – they need fast, fail-safe scanning that keeps pace with their release velocity. Heavily regulated enterprises moving at structured release cycles need the exact opposite: comprehensive audit trails, detailed compliance documentation, and tools that support their heavyweight change management.
An AppSec engineer orchestrating security across a handful of product teams is drowning in noise from individual team alerts – they need executive dashboards that cut through the chaos and surface real, relevant organizational risks. Embedded AppSec engineers partnering with a single product team’s workflow need tools that speak their team’s language – not generic security platforms, but solutions that understand their specific codebase and business logic.
You can’t protect velocity with brakes. You need a steering wheel. As practitioners, the north star is all about providing security controls that enable rather than constrain development velocity.
Working in high-velocity environments taught me that gate-based security actually undermines what we’re trying to achieve. When teams are deploying code multiple times daily, requiring them to pause for security evaluation breaks their flow state, introduces delays, and creates an adversarial relationship between security and engineering. Most security tools still assume gate-based workflows where teams stop and wait for security approval. The “DevSecOps” movement acknowledges this tension but often focuses on tool integration rather than workflow philosophy. Continuous security approaches recognize the need for ongoing monitoring but don’t always address the fundamental gate vs. guardrail distinction. The categorization helps by acknowledging that security must fit into development and CI/CD workflows. However, it falls short by treating this as an automation problem rather than recognizing the need for fundamentally different security control models- ones that embed continuous guidance into development workflows, keeping developers in flow state instead of requiring them to pause at periodic security checkpoints.
That being said, let’s take a closer look at where the real gaps exist in the AppSec solution landscape. These are the areas where practitioner pain is acute but the market offers little meaningful relief. These gaps reveal something important about how the security industry operates: problems that don’t fit neatly into established vendor categories tend to get ignored or superficially addressed, even when they represent some of the most significant challenges practitioners face daily.
What makes these gaps particularly interesting is how LLMs could potentially address many of these challenges, yet we’re seeing surprisingly limited proven successful adoption in the areas where they could provide the most value. The AI integration in security tools has largely focused on detection and classification tasks rather than the reasoning and decision support challenges that practitioners struggle with most.
The most striking gap in today’s security tooling landscape centers on decision support rather than data collection. Current security tools excel at gathering information: vulnerability scanners identify potential issues, asset discovery tools map infrastructure, compliance platforms track policy adherence, etc.
Consider what actually happens when a practitioner needs to make a security decision. Say, a developer asks whether implementing a particular OAuth flow introduces unacceptable risk. To answer this question properly, the security practitioner needs to go beyond understanding the technical implementation. There’s the business context, the existing threat model, the organizational risk tolerance and the potential operational impact. The decision isn’t just about whether the implementation has vulnerabilities, it is about whether any vulnerabilities that do exist are acceptable given the specific circumstances. LLMs could generate context-aware remediation advice based on architectural patterns, business risk tolerance, and compliance requirements. They could act as a security copilot that helps practitioners work through questions like “Given our risk tolerance and deployment timeline, should we fix this vulnerability now or defer it to the next version?”. Additionally, AI could augment threat modeling by helping practitioners reason through likely attack paths and mitigations based on partial system diagrams or high-level application descriptions. Regardless, all of this requires a deep understanding of organizational dynamics and how trade-offs are actually made in real companies. That’s hard to productize, especially at scale – it’s much easier to just keep surfacing more issues and calling it “insight”.
The second major gap stems from the industry’s tendency to build generic security platforms rather than workflow-specific tools. Most security vendors optimize for broad market appeal by creating solutions that claim to work for any security team in any organization. This one-size-fits-all approach ignores the reality that security work varies dramatically depending on organizational structure, team size, and operational context.
Think about how different the daily workflows are for various security archetypes. An Orchestrator managing security across multiple product teams needs coordination tools, visibility and consistency tracking. An embedded Specialist working within a single product team needs deep integration with development workflows, intimate system knowledge, and rapid feedback loops. A Rapid Responder handling urgent security issues needs efficient triage capabilities, quick access to decision-makers, and streamlined escalation paths. These are fundamentally different roles with different information needs, different success metrics, and different operational constraints. Despite that, most security tools treat them as variations of a generic “application security engineer” role. The result is software that kind of works for everyone but excels for no one.
AI-powered tools could tailor pull request reviews, incident communications, and remediation plans based on the specific workflow patterns of the team using them. Instead, most AI-enabled security tools today provide generic outputs regardless of the user’s role or organizational context.
Perhaps the most significant gap in the current vendor landscape is the almost complete absence of solutions designed explicitly for resource-constrained environments. Most security tools are built with the assumption that organizations have dedicated security teams, comprehensive budgets and the operational capacity to implement and maintain complex security programs. This assumption creates a fundamental mismatch with the reality that many organizations have insufficient resources to implement comprehensive security programs, limited personnel to maintain complex tooling and competing priorities that constrain their ability to invest heavily in security infrastructure.
For teams operating under these constraints, the challenge isn’t finding security tools with more features, it is finding solutions that provide maximum security impact with minimal operational overhead. This means challenging the perception that security slows down development. Solutions that prioritize operational simplicity, target resource-constrained teams, and integrate seamlessly into existing workflows (development, CI/CD, project management, communication, and monitoring & observability) will have a significant advantage in delivering security controls that enable rather than constrain development velocity.
The gap between Application Security theory and practice isn’t just an inconvenient reality, it is the defining challenge of our field. Security isn’t failing because we lack tools, frameworks, or best practices. We’re struggling because most solutions ignore the messy, high-velocity, resource-constrained environments we actually work in. The fundamental challenge we face as AppSec practitioners isn’t technical – it’s philosophical. Bridging this gap requires more than shifting left or buying smarter scanners. It demands a deep alignment between our security philosophies, the workflows they must support, and the real-world contexts we live in.
What does this mean for practitioners? We need to stay pragmatic while pushing the industry toward solutions that actually solve the problems we face daily. That means being honest about what works and what doesn’t, building internal capabilities to bridge the gaps that vendors haven’t addressed, and continuing to advocate for security approaches that enable rather than constrain the software development practices that drive modern business success.
For security founders and product leaders, this reality creates both challenges and opportunities. The current funding environment demands more than innovative technology – it requires demonstrating clear market traction and operational sustainability from the earliest stages.
The market is saturated with point solutions, and successful cybersecurity companies (particularly in the AppSec space) will be those that address multiple layers of the abstraction stack we’ve discussed while simplifying their offerings for practitioners. After all, at the core of any successful startup is solving real customer problems and creating value. This means addressing the sharp pain points we’ve outlined – contextual decision-making, workflow integration, and resource constraints.
Customers will only adopt your product if it solves a specific, painful problem they’re experiencing and fits seamlessly into their existing workflows. If your solution is hard to use or requires them to change how they work, they’ll abandon it regardless of how technically sophisticated it is. Additionally, regular customer conversations are essential to staying aligned with evolving practitioner needs; these conversations must go beyond feature requests to truly empathetic listening that understands the frustrations and constraints practitioners face daily.
Building lasting relationships requires creating support experiences where customers feel heard and valued, with quick problem resolution that builds the kind of loyalty that turns users into advocates. As organizations mature, their security requirements become more complex, so building scalable solutions that can grow with your customers will ensure long-term success.
The theory-practice gap in application security isn’t going away on its own. By acknowledging it explicitly and working to address it systematically, we can build more effective security programs that actually work within the organizational realities we all navigate every day.
