2016 - Chad Butler - Big Shop AppSec for Everyone Else

### Overview In this presentation, Chad Butler, Managing Director of Security Services at Caliber Security Partners, addresses the challenges smaller software shops and startups face when attempting to establish an application security (AppSec) program. Startups frequently build great software products only to see critical deals stalled by enterprise prospective customers' security teams demanding compliance with exhaustive questionnaires and stringent requirements. Drawing on historical data from the Verizon Data Breach Investigations Report showing web applications as the persistent leading source of breaches, Butler explains that traditional AppSec approaches designed for waterfall development fail to keep up with modern agile and rapid deployment cadences. He outlines practical, cost-effective strategies for smaller organizations to build an effective AppSec posture, satisfy enterprise vendor audits, and integrate security directly into developer workflows.

### Key Topics - **Vendor Security Assessments and Overcoming the "Special Snowflake" Problem**: Large enterprises often hit suppliers with 30-page security questionnaires that pile on irrelevant or unused security controls. Butler advises teams to "plant the flag and declare success" by proactively choosing and justifying recognized frameworks before enterprise customers impose arbitrary requirements. He highlights Boeing's publicly available vendor security questionnaire on SafeCode's website (Principles for Software Assurance Assessment) and alignment with standards like ISO 27034 as strong baselines. - **Rethinking Threat Modeling**: Traditional multi-hour whiteboard threat modeling sessions developed under waterfall frameworks often cause developer friction and fail in fast-paced sprint cycles or multi-daily release environments. Butler advocates replacing or augmenting them with pragmatic, lightweight approaches. - **Winning Developer Hearts and Minds**: AppSec programs fail when security teams adopt a "my way or the highway" approach. Security teams must reduce friction, meet developers where they work (e.g., inside Jira rather than forcing separate portals), provide actionable solutions rather than just problems, and offer engaging incentives.

### Technical Details - **Task-Level Threat Assessments**: A lightweight mechanism implemented directly into backlog or defect trackers (such as Jira). Developers answer an eight-question checklist covering areas like sensitive data, authentication, authorization, password resets, cryptography, and third-party libraries. If any response is "yes," the workflow assigns specific application security controls as acceptance criteria for that task, embedding security validation into developer and QA testing while providing an auditable metric of reviewed features. - **Standardized Security Requirements**: Grounding development and QA requirements in established standards such as OWASP ASVS (Application Security Verification Standard) and the CWE/SANS Top 25 Monster Mitigations list. Storing requirements and stack-specific implementation guides in team wikis allows developers to adapt code patterns to their specific frameworks. - **Interactive Training**: Avoiding expensive, passive training in favor of hands-on exploitation and remediation labs using deliberately vulnerable applications (e.g., WebGoat, BeEF). Motivation can be driven through gamified recognition systems, such as Adobe's martial arts belt system (white to black belt), custom challenge coins, or helmet stickers. - **Tooling and Testing Strategy**: Focusing on pragmatic testing rather than expensive enterprise platforms (e.g., a $300 Burp Suite Pro license in skilled hands instead of a $40,000 scanner). Implementing tools like ThreadFix to aggregate vulnerability results from static/dynamic testing and automatically sync defect tracking with Jira.

### Takeaways Organizations should adopt Paul Graham's startup philosophy to "do things that don't scale" when beginning AppSec: start small by tackling a single vulnerability class (like cross-site scripting or SQL injection), track progress in simple spreadsheets or dashboards, and gradually formalize the practice. Proactive adoption of standard baselines, lightweight task-level gating, and developer-first collaboration yield significantly better security outcomes than heavyweight, obstructive gates. Finally, while stopgaps like Web Application Firewalls (WAFs) provide temporary protection, they should never serve as a permanent replacement for secure coding.