Battle Tested Application Security - Ty Sbano

Ty Sbano presents a pragmatic guide to building and scaling application security programs based on his experience in financial services and startups. Rather than focusing on specific tools or frameworks, the talk emphasizes relationships, understanding organizational culture, and strategic positioning within engineering teams.

**Building an App Sec Program Fundamentals**: Sbano outlines three initial steps: learn your organization's technology culture and code delivery methods (IDEs, languages, tech stacks); ignore vendor hype in the first 30 days and listen to engineering teams instead to understand real pain points; and be willing to put in the work—showing up during releases, incident response, and high-stress moments to earn credibility.

**Key Relationship Areas**: Success requires engaging multiple stakeholders differently: development teams (present and empowering), operations (understanding CI/CD tools like Jenkins, Concourse, and how code moves to production), compliance (helping translate regulations into sensible practices), and legal (securing contractual language with vendors). Sbano stresses alignment with business mission—if you don't believe in what the company does, leave.

**SDLC and Risk-Based Approach**: Security gates are outdated; instead, be present in the code change process. Reject prescriptive 30-60-90 day remediation policies that don't align with actual release cycles. Risk-based prioritization matters more than tracking all static analysis findings—50,000 coding flaws require filtering and manual validation, not rigid compliance metrics. Different engineering teams have different release cadences, and policies must reflect that reality.

**Metrics and Measurements**: Sbano warns against measuring yourself to death with complex formulas (cosine and sine). Instead, track what matters: code coverage, portfolio risk, and application inventory. One example: early in his career, he learned that static analysis output produces "coding flaws," not "vulnerabilities," until validated—a lesson that changed how he educated auditors and regulators.

**Team Composition and Staffing**: Insourced programs are more rewarding and allow true partnership with engineers. Outsourced programs require careful contract language (Software Security Annex) and vendor management. Hybrid approaches work when your team deeply understands outsourced technologies—e.g., don't outsource static analysis unless you understand rule engines, tuning, and authentication.

**Training and Education**: Live coaching with individual engineers is the most impactful method. The example of explaining why null checks alone don't validate input—an engineer with a null check still couldn't prevent code injection until Sbano walked through the actual attack—illustrates the value of presence over CBTs and compliance trainings. Sneakernet (walking around) and building relationships matter more than lectures.

**Open Source Over Silver Bullets**: Embrace tools built into your tech stack (Java security modules, Kubernetes controls, OWASP Zap) before buying commercial solutions. Budget constraints are real; tools like Brakeman, OWASP proxy, and license checking via artifact registries provide significant value without enterprise spending.

**Asset Management and Risk Assessment**: Before starting a program, map all applications, data flows, and external attack surface. Move beyond questionnaires to automation—API analysis and stream analysis to detect if sensitive data flows in the clear or only appears encrypted, giving a reality check on true risk.

**Final Philosophy**: Hygiene over hype; dialogue over confidentiality (transparent reporting in backlogs); support and celebrate people doing great work rather than shaming mistakes; and always be learning. Risk management matters, but continuous learning is the core principle—no expert truly masters app sec.