How to get developers to want to adopt AppSec

## Overview This talk addresses how to get developers to adopt AppSec (application security) practices by aligning incentives, automating security testing, and integrating security into existing workflows. The speaker, an engineering manager at an AppSec company, shares insights from transitioning from an engineer who disliked security to one helping teams adopt security tooling.

## Why Engineers Resist AppSec The speaker identifies four key barriers:

1. **Perceived waste of time**: Engineers struggle to see the immediate impact of security practices (e.g., input sanitization) because computer science education focuses on algorithmic complexity rather than attack vectors.

2. **Tool fatigue**: Engineers already use many tools (GitHub, Jira, Confluence, DataDog, Kibana). Adding another tool feels like extra friction.

3. **Misaligned KPIs**: Engineers are measured on features delivered, bug count reduction, and predictability—not security. This creates natural resistance to tasks that slow feature development.

4. **Knowledge gaps**: OWASP top 10 vulnerabilities and their real-world impacts aren't taught in typical CS degrees or bootcamps.

## Why This Matters to Companies Recent major breaches exploited common vulnerabilities like XSS and broken access control. When vulnerabilities reach production, engineers must context-switch under intense pressure to fix them—a scenario they hate more than dealing with security proactively. Catching vulnerabilities early prevents this costly reactive cycle.

## Solutions: Three Key Areas

**1. Education with Concrete Examples** Engineers need to understand specific attack vectors through practical scenarios. Examples: preventing SSRF by accepting only enum service names rather than full URLs; sanitizing user inputs before rendering to prevent XSS. However, education alone is insufficient; mistakes will happen.

**2. Automated Security Testing** Treat security vulnerabilities like functional bugs. Apply CI/CD automation to security checks, not just manual code review. This prevents one-line changes (like removing a `SameSite=Strict` cookie attribute) from reaching production. Runtime-based testing tools provide stronger proof of exploitation and educational value—engineers become motivated when they see a screenshot of their API being exploited.

**3. Collaborative Prioritization** Product, AppSec, and R&D must jointly prioritize vulnerabilities, combining business context with technical severity. Don't order by CVSS severity alone. Example: a "high" SSRF in customer-facing production code may take priority over a "critical" broken access control bug in internal employee tools.

## Characteristics of Effective Security Tools

**Coverage**: Must address OWASP top 10, API top 10, and LLM top 10 vulnerabilities.

**Low false positives**: Maintain under 10% false positive rate. High false positive rates waste engineering time and erode trust in the tool, causing engineers to ignore legitimate findings.

**Ease of use**: Integrate with existing tools (GitHub, Jenkins, Jira), offer SDK and CLI for local testing, and avoid requiring separate portals. Dissonance between tools kills adoption.

**Proof of exploitation**: Runtime-based tools showing request/response pairs or screenshots help engineers see real impact and motivate fixes. This also has significant educational value.

**Tool evaluation**: Test candidate tools on known-vulnerable open-source projects (OWASP Juice Shop, Broken Crystals, DVWA, BWApp) to assess real-world performance before adoption.

## Implementation and KPIs

Security bugs should count toward the "lower bug count" KPI alongside functional bugs, since both are bugs. Security testing must fit agile development cycles—tools should complete CI checks within 10–20 minutes for typical use cases. For entry points with many parameters, use tiered approaches: fast static checks during development, runtime checks in CI for core functionality, and extended testing in pre-production if needed.

## Key Takeaways - Development is agile; security testing must be agile too - Don't sacrifice coverage for false positives - Integrate security into existing tools and workflows, not as a separate process - Automate security checks like functional tests - Engineers adopt AppSec when they understand impact and face minimal friction