BSidesSF 2026 - The AppSec Poverty Line: Minimal Viable Security (Tanya Janca)

### Overview In this BSidesSF presentation, Tanya Janca (She Hacks Purple) addresses the reality that most small businesses, startups, and small engineering teams do not possess the massive security budgets of tech giants like Microsoft, Google, or Meta. Janca introduces the concept of the "AppSec poverty line"—an analogy to the economic poverty line defined as the minimum threshold of security investment, knowledge, and practices below which an organization cannot adequately protect itself against common threats. To address this gap, she details "Minimal Viable Security" (MVS): the absolute bare minimum set of controls, practices, and processes required to meaningfully mitigate risk on public-facing applications without hindering core business delivery.

### Key Topics & Prioritizing What Matters For any non-static application exposed to the internet, Janca outlines fundamental, low-cost essentials: - **Input Validation & Sanitization:** Strict input validation, rejecting bad input by default rather than attempting to fix it, and escaping or sanitizing when necessary. - **Output Encoding & Database Safety:** Output encoding for the web to prevent cross-site scripting (XSS), and using parameterized queries or prepared statements rather than string concatenation to prevent SQL injection. - **Modern Platforms & Dependency Management:** Using supported, long-term support (LTS) toolchains and actively verifying third-party dependencies. - **Logging, Monitoring & Basic Encryption:** Thorough logging to ensure incident response is possible, basic monitoring to detect downtime, and enforcing HTTPS/TLS. - **Risk Transfer & Identity:** Buying third-party identity, authentication, and authorization solutions instead of writing custom auth implementations, and offloading payment handling to compliant third parties (e.g., Stripe). - **Basic Scanning & Vulnerability Reporting:** Ensuring applications pass a basic free Dynamic Application Security Testing (DAST) scan (using tools like OWASP ZAP or Burp Suite), and implementing `security.txt` so external researchers have a direct contact email to report bugs.

### What Small Teams Can Ignore Janca highlights practices that small teams on tight budgets should deprioritize: - Worrying about edge-case TLS versions (e.g., TLS 1.2 vs. 1.3) or theoretical zero-days that are not actively exploited in the wild. - Custom cryptography, custom PKI, or overly complex role-based access control (RBAC). - Security through obscurity, code obfuscation, or hiding endpoints. - Expensive external penetration tests before basic hygiene and DAST scans are resolved. - Advanced tooling such as RASP, IASP, and intensive DDoS testing. - Strict governance overhead or burning resources on achieving 100% code coverage across every line instead of focusing on critical flows.

### Developer Training, Culture, and Tooling To scale security with minimal spend, organizations should train developers directly via hands-on code reviews, lightweight checklists, and free community resources (such as OWASP top 10 lists, OWASP ASVS, books, and local meetups). Recommended tooling includes open-source/free solutions like Semgrep for SAST, TruffleHog or Gitleaks for secret detection, and free DAST scanners. Janca emphasizes cultivating a supportive security culture—rewarding developers for security wins, normalizing pauses during emergencies, and moving away from a punitive "bad news bears" mentality.

### Beyond MVS & Takeaways Minimal Viable Security is merely the starting threshold. Teams must graduate beyond MVS if they handle sensitive customer data, manage health or payment records, undergo rapid organizational growth, experience a significant threat surface expansion (such as mergers and acquisitions), or encounter incidents their teams cannot resolve alone. For offline or specialized applications, teams should assess criticality using threat modeling questions regarding potential real-world harm. Janca concludes with a simple three-step call to action for small teams: run a free DAST scan against public applications and fix the findings, deploy `security.txt`, and begin asking what the worst-case scenario is to plan accordingly.