AI
Why Engineers Resist AppSec
Engineers don’t avoid security because they’re careless. Matan Rabi, who worked as a software engineer before becoming an engineering manager at Bright Security, names three reasons. Security feels like wasted time. Computer science degrees cover Big O notation, not input sanitization. Developers already have GitHub, Jira, Confluence, Grafana, Datadog, and Kibana open. Adding a seventh tool is a hard sell. And security responsibility isn’t in the written job description: acceptance criteria come from product managers, code reviews check for performance, not attack vectors.
Misaligned KPIs Make Security Somebody Else’s Problem
Engineers are measured on three things: features shipped, bug count, and sprint predictability. Security doesn’t fit any of them. Running a new security step slows feature work, requires talking to the AppSec team, and risks missing sprint commitments. Rabi pulled breach data from August 2024. One company paid a $5.8 million ransom. When that happens, engineers bear the fix. They context-switch every 30 minutes while their manager asks for status. Rabi’s observation: engineers hate working under pressure more than they hate any tool.
Security Awareness Through Concrete Code Examples
Two examples show what a security-aware engineer does differently. Building a gateway that reads the redirect URL as a raw query parameter opens an SSRF vector. A security-aware engineer restricts input to an enum of service names instead. Rendering user input via document.getElementById with no sanitization enables XSS. The fix is output encoding, which existing libraries handle, but only if the engineer thinks to apply it. Neither fix requires knowing every exploit payload. Both require knowing the category of risk.
Automated Tests Are the Fix for Human Error in Security
Education alone doesn’t prevent all vulnerabilities. Bob, a new hire refactoring session cookie code, removed one line: SameSite=Strict. The review missed it. The app shipped vulnerable to CSRF. Engineers already solve this class of mistake for functional bugs with automated CI tests that block regressions. A security vulnerability is a bug. If the team had an automated CSRF test, Bob’s PR would have failed before it merged. Catching a vulnerability during development means the app was never exposed in production.
Sorting Vulnerabilities by Severity Alone Fails
The standard approach of sorting vulnerabilities by CVSS severity has a concrete flaw. An example: broken access control in an internal workday-hours portal is rated critical. An SSRF vulnerability against the main customer-details endpoint is rated high. Severity-only ranking sends engineers to the internal portal first. But the SSRF exposes customer data in production. Rabi’s fix: AppSec and product sit together, each contributing domain expertise, and agree on a business-context-weighted priority list for the quarter.
What Good AppSec Tooling Requires
Three criteria define a tool engineers will actually use. First, coverage: at minimum, OWASP Top 10, OWASP API Top 10, and for LLM-integrated apps, OWASP LLM Top 10. Second, a false positive rate below 10%. High false positive rates waste engineer time and destroy trust. Once engineers learn to skim alerts, real vulnerabilities get dismissed. Third, integration: CI support, an SDK or CLI for local testing, and direct Jira ticket creation. OWASP ZAP provides runtime proof of exploitation, which cuts false positives and shows engineers the concrete impact of their code.
Q&A
Should security bugs count toward the lowered bug count KPI? Yes, security bugs are functional bugs and should be included alongside functional bugs in the quarterly bug count metric. ▶ Watch (29:44)
Should product manager KPIs align with engineering KPIs on bug counts? Product KPIs should correlate with R&D KPIs so the team is measured consistently on the same outcomes. ▶ Watch (30:51)
What if CI security scanning takes too long? Target 10 to 20 minutes for CI scans; for apps with many parameters per endpoint, push runtime tests to nightly pre-production runs rather than blocking every PR. ▶ Watch (32:05)
Notable Quotes
order by severity doesn’t work Matan Rabi · ▶ Watch (19:29)
egoistic we’re now motivated as hell to Matan Rabi · ▶ Watch (26:16)
less than 10% false positive Matan Rabi · ▶ Watch (23:35)
Key Takeaways
- Engineers skip AppSec when their KPIs measure features shipped and sprint predictability, not vulnerability prevention.
- Security bugs deserve automated CI tests. One removed SameSite=Strict attribute shipped a CSRF vulnerability before anyone noticed.
- Sort vulnerability backlogs by business impact, not CVSS severity. A customer-data SSRF outranks an internal-portal broken access control.
About the Speaker(s)
Matan Rabi is an Engineering Manager at Bright Security. His team manages the core research and development effort, focused on building a DAST tool optimized for precision, recall, and vulnerability coverage to help companies identify their actual runtime vulnerabilities.