The AppSec Poverty Line: Minimal Viable Security

The AppSec Poverty Line: Minimal Viable Security

Speakers: Tanya Janca

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=0QFW36FCRlY

Overview

In her compelling talk, "The AppSec Poverty Line: Minimal Viable Security (MVS)," Tanya Janca, CEO and Secure Coding Trainer at She Hacks Purple Consulting, addresses a critical and often overlooked challenge in the cybersecurity landscape: how small businesses, startups, and resource-constrained teams can achieve a baseline level of application security. Janca argues that not every organization possesses the vast budgets and dedicated security teams of tech giants like Microsoft or Google, leaving many vulnerable to common, easily exploitable threats. This presentation introduces the concept of the "AppSec Poverty Line," defining the absolute minimum security investment, knowledge, and practices required to adequately protect internet-exposed applications.

Janca’s central premise is that while every application should ideally strive for robust, multi-layered security, there exists a fundamental threshold below which an organization is grossly irresponsible for putting an application on the internet. This "Minimal Viable Security" is not about defending against nation-state attacks or zero-day exploits, but rather about shoring up defenses against the most prevalent and basic vulnerabilities that free scanners can detect. The talk provides a pragmatic roadmap for prioritizing essential security controls, identifying what can be de-prioritized for smaller teams, and leveraging free or low-cost resources to elevate an organization's security posture above this critical poverty line.

The importance of this discussion cannot be overstated. As the digital attack surface continues to expand, even the smallest applications can become entry points for larger breaches, impacting user trust, data integrity, and business continuity. Janca's insights are particularly valuable for development teams operating without dedicated security personnel or significant financial backing, offering actionable strategies to embed security fundamentals into their development lifecycle and foster a more secure culture without overwhelming limited resources.

Background

▶ Watch: Why minimal viable security? Addressing non-enterprise budgets. (1:00)

The premise of "The AppSec Poverty Line" stems from a stark reality: the vast majority of companies do not operate with the enormous security budgets and specialized teams characteristic of FAANG (Facebook, Amazon, Apple, Netflix, Google) companies. Tanya Janca's own 2024 survey of 60 companies revealed a sobering truth about the industry's overall AppSec maturity, indicating that many organizations, even well-known ones, are only just beginning to implement their first application security programs. This disparity creates a significant vulnerability gap, especially for startups and small businesses that frequently launch internet-facing applications without adequate protection.

Janca employs the analogy of the general poverty line—a threshold below which income fails to cover basic necessities—to define the AppSec poverty line. This security-specific threshold represents the minimal investment, knowledge, and practices required to protect applications from common, credible threats. Falling below this line means an organization cannot defend itself against even the most basic attack vectors, making it "grossly, ridiculously irresponsible" to expose an application to the internet.

The concept of Minimal Viable Security (MVS) is borrowed from the Minimum Viable Product (MVP) framework, which focuses on building the smallest possible set of features to demonstrate value. Similarly, MVS outlines the smallest set of security controls, practices, and processes necessary to meaningfully reduce risk and protect an application or system from common threats, all without impeding its core functionality or delivery. It explicitly excludes defense against sophisticated zero-day exploits or nation-state attacks, emphasizing that these concerns are secondary if fundamental hygiene is neglected. MVS, therefore, is presented not as an ideal state, but as the absolute bare minimum—a foundational layer upon which more advanced security can eventually be built.

Key Findings

▶ Watch: What Minimal Viable Security (MVS) entails. (4:40)

Tanya Janca's talk delivers a clear, actionable framework for achieving Minimal Viable Security (MVS), distilled into several key findings:

1. The 11 MVS Essentials: For any internet-exposed application (beyond static HTML), Janca identifies 11 non-negotiable security practices: rigorous input validation, proper output encoding for the web, safe database interaction via parameterized queries, use of modern, supported tools, thorough logging and monitoring, reliance on bought security systems for authentication/authorization, proactive dependency management, strategic risk transfer (e.g., outsourcing payments), ubiquitous HTTPS encryption, ability to pass a basic DAST scan, and engagement in a minimal threat model.
2. What Doesn't Matter (for Small Teams): Janca provides a crucial counter-list of advanced security concerns that resource-constrained teams can temporarily de-prioritize. These include obsession over specific TLS versions (beyond avoiding ancient SSL), worrying about zero-days (unless actively exploited), custom cryptography or complex RBAC, security through obscurity, formal penetration testing (until basics are covered), advanced tooling like RASP/IAST, strict governance, and striving for 100% code coverage (focus on critical flows first).
3. Free and Low-Cost Developer Training: Acknowledging budget constraints, Janca highlights numerous free resources for developer training. These include OWASP projects (Top 10, ASVS, Secure Coding Dojo, intentionally vulnerable apps), community chapters (OWASP, BSides, ISSA, Isaka), and even affordable books. She also advocates for embedding security into daily practices like code review (using checklists, short reviews, rotating roles) and fostering internal security communication channels (Slack/Discord).
4. Open-Source Tools That Punch Above Their Weight: Janca recommends specific open-source tools that offer significant value without cost. For static analysis, Semgrep and CodeQL are mentioned. For secret detection, TruffleHog and GitLeaks are highlighted. While dependency scanning is acknowledged as harder with free tools, OWASP ZAP and Burp Suite Community Edition are endorsed as excellent free/low-cost options for dynamic scanning.
5. When MVS is Not Enough: Janca clearly defines scenarios where organizations must scale beyond MVS. These include handling sensitive user data (health info, PII), managing payment systems or high-profile exposures, rapid organizational growth, inability of security teams to keep pace with development, significant changes in threat model or threat surface (especially due to mergers/acquisitions), and experiencing unmanageable security incidents.
6. Gradual Security Scaling: For organizations needing to level up, Janca suggests a phased approach: prioritizing automation of repetitive tasks, investing in advanced testing (pentests, risk assessments), structured training, establishing and maturing security processes (e.g., DSOM, ASVS), implementing comprehensive monitoring, adopting specialized big tools, and eventually building a dedicated security engineering team.

Technical Deep Dive

▶ Watch: Crucial clarification: MVS is absolute bare minimum. (6:00)

The core of Janca's MVS framework lies in a set of practical, fundamental security controls designed to address the most common and impactful vulnerabilities. These are the "bare essentials" for any application exposed to the internet:

1. Input Validation: This is paramount. Janca stresses that if all developers perfected input validation, the internet would be significantly safer. The principle is simple: validate all incoming data to ensure it conforms to expected types, formats, and ranges. If input is malformed or malicious, it should be rejected, not "fixed," as attempts to sanitize often introduce new vulnerabilities. If potentially dangerous characters or data must be accepted, rigorous sanitization or escaping must be applied before the data is processed or stored. This directly combats a wide array of injection attacks and other data-manipulation vulnerabilities.
2. Output Encoding: To eliminate Cross-Site Scripting (XSS), all data rendered in a web browser must be output encoded according to the context in which it appears (HTML, attribute, JavaScript, URL, CSS). Janca notes that while XSS was often a standalone category, the OWASP Top 10 2025 has folded it into the broader "Injection" category, reflecting its nature as a client-side injection attack. Proper encoding ensures that user-supplied data is treated as data, not executable code, in the browser.
3. Safe Database Interaction: SQL Injection remains a pervasive threat. The MVS approach mandates the use of parameterized queries or prepared statements when interacting with databases. This mechanism ensures that user input is passed as data parameters to the database engine, completely separate from the SQL query structure. The database engine then treats these parameters strictly as values, preventing any attempt to inject malicious SQL commands. Using this method effectively "takes away its powers" by removing the ambiguity between code and data.
4. Use Modern Tools: This is straightforward but often overlooked. Applications should be built and run on supported, up-to-date versions of operating systems, libraries, frameworks, and programming languages (Long-Term Support - LTS versions where applicable). Using outdated software means missing out on critical security patches and often exposes applications to known vulnerabilities that have been fixed in newer releases.
5. Thorough Logging and Monitoring: While often seen as an expensive overhead, Janca argues that the cost of not logging and monitoring is far greater, especially during an incident. Comprehensive logs provide forensic evidence to understand what happened during a breach, while monitoring alerts teams to application downtime or anomalous behavior before customers notice. This applies to all components, from traditional web apps to APIs and serverless functions.
6. Secure Authentication, Authorization, Session Management, Identity: This complex domain is prone to subtle errors when implemented from scratch. Janca's unequivocal advice is: buy a system, don't write it yourself. She cites Microsoft Active Directory as an example of a system with decades of investment and still occasional bugs, underscoring the difficulty of building secure identity solutions. Transferring this risk to specialized, battle-tested third-party providers (e.g., identity-as-a-service platforms) is a crucial MVS strategy.
7. Dependency Management: Modern applications rely heavily on third-party libraries and components. MVS requires careful dependency management, including verifying the trustworthiness of chosen dependencies, regularly scanning for known vulnerabilities (e.g., using Software Composition Analysis - SCA tools), and actively managing the risk associated with any identified flaws. Software "doesn't age well," meaning regular checks are essential.
8. Transfer Risk: For highly sensitive or regulated functions, transferring risk to specialized providers is a smart move. Janca specifically mentions payment processing. Instead of investing heavily in achieving PCI DSS compliance and managing sensitive cardholder data, organizations can integrate with services like Stripe or similar payment gateways. These providers specialize in secure payment handling, offloading a significant security burden and regulatory compliance challenge.
9. HTTPS Everywhere: Encryption in transit is non-negotiable. All internet-facing applications must use HTTPS. Janca also advocates for encrypting traffic behind the firewall. Thanks to initiatives like Let's Encrypt (supported by organizations like the EFF), obtaining and managing SSL/TLS certificates is largely free and automated, removing previous cost barriers. Browsers like Chrome actively shame insecure HTTP sites, further reinforcing the necessity of HTTPS.
10. Pass a Basic DAST Scan: Before even considering advanced threats, an MVS application should be able to pass a scan from a free Dynamic Application Security Testing (DAST) tool. Tools like OWASP ZAP, Burp Suite Community Edition, or Nuclei can identify common vulnerabilities (e.g., injection flaws, misconfigurations). If an app fails a basic DAST scan, the focus should be on fixing these easily detectable issues rather than worrying about zero-days or advanced persistent threats.
11. Basic Threat Model: Security is not just about tools; it's about understanding risks. MVS includes conducting a minimal threat model, ideally a single conversation. Janca references Adam Shostack's four-question framework: "What are we building?", "What could go wrong?", "What are we going to do about it?", and "Did we do a good job?" This simple process helps identify critical assets, potential threats, and initial mitigations.
12. System Security Assessment (4 Questions): To quickly gauge the required security level, Janca proposes a four-question assessment: Is the app public-facing? Does it handle sensitive data? Is it mission-critical? Is it subject to legislation/compliance? Each "yes" adds a point to a score out of four. A score of two or higher indicates a need to go beyond basic MVS.
13. Report Security Issues: Organizations should provide a clear, easy way for both internal staff and external researchers to report security vulnerabilities. Implementing a security.txt file on the web server with a dedicated email address is a simple, effective solution. This encourages responsible disclosure over public shaming or exploitation.

Janca also outlines what doesn't require immediate attention for small teams, allowing them to focus resources effectively:

• TLS Version Obsession: While using the latest is good, worrying about minor differences between TLS 1.2 and TLS 1.3 is less critical than fundamental hygiene, unless using ancient, broken protocols like SSL.
• Zero-Days: Unless a vulnerability is actively being exploited in the wild (like Log4Shell or major React flaws), small teams should focus on known, common vulnerabilities.
• Custom Crypto/PKI/RBAC: Complex security primitives should be bought, not built. Custom Role-Based Access Control (RBAC) schemes with excessive roles (e.g., 12 roles for 8 users) introduce complexity and potential flaws; simplification is key.
• Security Through Obscurity: Hiding endpoints or obfuscating code offers minimal protection against a determined attacker and is an advanced concern.
• Penetration Testing: While valuable, a formal pentest is not cost-effective at the MVS stage. Testers will find numerous basic flaws that a free DAST tool could have already identified.
• Advanced Tooling: Tools like Runtime Application Self-Protection (RASP), Interactive Application Security Testing (IAST), or DDoS testing are for more mature programs.
• Strict Governance & Perfect Code Coverage: Without a dedicated security team, intense governance is impractical. Focus on critical application flows and internet-exposed components rather than 100% code coverage.

Demo / Proof of Concept

▶ Watch: Prioritizing: Essential #2 - Output encoding for XSS. (7:40)

The talk "The AppSec Poverty Line: Minimal Viable Security" by Tanya Janca is a conceptual and instructional presentation focused on practical strategies and advice. It does not include a live demonstration or a proof of concept of an exploit or a security tool in action. Instead, Janca relies on real-world examples, industry observations, and a structured framework to convey her message about achieving baseline application security.

Defensive Implications

▶ Watch: Prioritizing: Essential #3 - Safe database interaction. (8:15)

For defenders, particularly those in resource-constrained environments, Tanya Janca's MVS framework provides a clear and actionable blueprint for prioritizing security efforts. The core defensive implication is a directive to focus intensely on the MVS 11 essentials before diverting resources to more advanced or niche security concerns. This means that if an application is exposed to the internet, fundamental controls like input validation, output encoding, and parameterized queries for database interaction are non-negotiable starting points. These three alone can eliminate a vast percentage of common injection vulnerabilities.

Defenders should actively leverage free and low-cost tools to maximize their impact. Running OWASP ZAP or Burp Suite Community Edition against internet-facing applications should be a mandatory first step, with any findings immediately prioritized for remediation. Integrating open-source static analysis tools like Semgrep or secret detection tools such as TruffleHog or GitLeaks into CI/CD pipelines can catch vulnerabilities early in the development cycle without significant financial investment. While dependency scanning has acknowledged limitations in free tools, implementing any available solution is better than none.

A crucial defensive strategy lies in investing in developer education and fostering a strong security culture. Defenders must move beyond being "bad news bears" and instead become enablers and champions. This involves providing access to free secure coding training (e.g., OWASP Secure Coding Dojo, ASVS, Top 10 resources), encouraging participation in security communities (local OWASP chapters, BSides), and embedding security into daily development practices. Simple measures like creating a security.txt file and a dedicated channel for reporting issues (internal and external) can significantly improve incident response and proactive vulnerability management. Code reviews should include security checklists, and the security review role should be rotated to spread knowledge.

Furthermore, defenders must understand when MVS is no longer sufficient and initiate a strategic shift to scale security efforts. Key triggers for this escalation include handling sensitive user data (e.g., healthcare, financial PII), processing payments, experiencing rapid organizational growth, significant changes in the threat model (e.g., new attack surface from a merger or acquisition), or facing recurring, unmanageable security incidents. In these scenarios, the defensive posture must evolve to include dedicated AppSec personnel, more sophisticated tooling (e.g., commercial DAST/SAST, RASP), formal penetration testing, and adherence to established security frameworks like DSOM or ASVS.

Finally, the call to action for every MVS team is explicit: run a DAST scan on your main internet-facing app and fix the findings, add a security.txt file, and start asking "what's the worst that can happen?" to proactively plan for potential incidents. By adopting these foundational practices, organizations can elevate themselves above the AppSec poverty line, significantly reducing their risk exposure and building a more resilient digital presence.

Key Takeaways

• MVS is a Critical Baseline: Minimal Viable Security (MVS) defines the absolute bare minimum security practices for internet-exposed applications, crucial for startups and resource-constrained teams that cannot afford extensive security investments.
• Prioritize Fundamental Controls: Focus intensely on the 11 core MVS essentials, including robust input validation, proper output encoding, parameterized queries, modern tooling, comprehensive logging, secure authentication (bought, not built), and ubiquitous HTTPS.
• Leverage Free & Low-Cost Resources: Utilize powerful open-source tools like OWASP ZAP, Burp Suite Community Edition, Semgrep, TruffleHog, and GitLeaks to achieve significant security gains without substantial financial outlay.
• Invest in Developer Education & Culture: Foster a strong security culture by providing free training resources (OWASP Top 10, ASVS, secure coding dojos), embedding security into code reviews, and normalizing the reporting and celebration of security wins.
• Know When to Scale Beyond MVS: Understand the triggers that necessitate moving beyond MVS, such as handling sensitive user data, processing payments, rapid organizational growth, or significant changes in the threat landscape (e.g., mergers and acquisitions).
• Start with Basic Proactive Measures: The immediate call to action for MVS teams is to run a basic DAST scan, implement a security.txt file for vulnerability reporting, and engage in basic threat modeling to proactively identify and mitigate risks.

About the Speaker(s)

Tanya Janca is a highly respected figure in the cybersecurity community, renowned for her expertise in application security and secure coding. She serves as the CEO and Secure Coding Trainer at She Hacks Purple Consulting, a company dedicated to empowering developers and organizations with practical security knowledge. With an impressive career spanning over 28 years in the IT industry, Janca has garnered numerous accolades, including recognition as an OWASP Lifetime Distinguished Member and being named Hacker of the Year. She is the best-selling author of "Alice and Bob Learn Secure Coding" and "Alice and Bob Learn Application Security," both widely regarded resources for developers seeking to enhance their security skills. Additionally, Tanya Janca played a significant role in helping to write the new OWASP Top 10, further solidifying her contributions to global application security standards. Her passion for making security accessible and actionable for all teams, regardless of budget, is a hallmark of her work.