The document presents a comprehensive framework for building a scalable global application security program by leveraging established strategies such as OWASP SAMM and BSIMM. It emphasizes the importance of culture, process, and governance in fostering security initiatives, and outlines practical steps for organizations at different maturity levels. Key elements include establishing a centralized security group, promoting security champions, and integrating security into development cycles to achieve continuous security at scale.

1. Brian Levine
Senior Director, Product & Cloud Security
A WARRIOR'S JOURNEY:
BUILDING A GLOBAL APPSEC PROGRAM

2. A Warrior's Journey: Building a Global AppSec Program
"Adapt what is useful, reject what is useless, and add what is specifically your own." -Bruce
Lee
This talk covers critical foundations for building a scalable Application Security Program.
Drawing on warrior-tested strategies and assurance frameworks such as OWASP SAMM and
BSIMM, this session gives actionable guidance on building and advancing a global
application security program.
Whether you are starting a fledgling security journey or managing a mature SSDLC, these
foundational elements are core for achieving continuous security at scale.
Brian Levine is Senior Director of Product Security for Axway, an enterprise software
company, delivering product solutions and cloud services to global Fortune 500 enterprises
and government customers.

3. About Brian Levine
Senior Director Product & Cloud Security
Axway Software
Former Stuff:
• Industrial Engineer, Purdue University
• Systems Engineer, EMC & other places
• Product Manager Security, Syncplicity

4. Where
would
you
begin?

5. “Adapt what is useful,
reject what is useless,
and add what is
specifically your own.”
– Bruce Lee

6. • Foundations for building a scalable global application security
program
Outline & Agenda
• Culture
• Process
• Governance

7. LET’S UNPACK THAT...
CULTURE

8. OWASP SAMM – “Secure Software Center of Excellence (SSCE)”
BSIMM – “Software Security Group (SSG)”
Axway – “Product Security Group (PSG)”
Others – “Product Security Office (PSO)” ...
Centralized Application Security Group
a Rose by any other name...

9. OWASP SAMM v2.0
Organization & Culture

10. “According to our observations, the first step of a Software Security Initiative (SSI) is to form an SSG.”
“without an SSG, success ... is very unlikely.”
BSIMM – Software Security Group (SSG)
Source: BSIMM11

11. GETTING STARTED
• Secure Executive Sponsorship
• Establish and Publicize the Charter and
Scope
• Define SSDLC goals & product objectives
• Align with PM, Development, and
Operations
• Internal Evangelism
• Selecting security tools, procedures, and
driving adoption
SOFTWARE SECURITY CENTER OF EXCELLENCE (SSCE)
LEVELING UP
• Stay Focused on the Customer (R&D)
• Publish SSDLC Standards, Procedures, and
Best Practices
• Identify promising security champions to
join the SSCE
• External evangelism
• DevSecOps automation, enabling self-
service & continuous security
• Data-driven program management

12. • 42% (55/130) of the firms in BSIMM11 study have a security champions program.
• 65% of the firms that have been assessed more than once have a security champions program.
SECURITY CHAMPIONS
OWASP SAMM
BSIMM

13. BUILDING
• Identify individuals with
interest/passion for security
• 1 champion per development
project
• Provide formal training, workshops,
and sponsorship for conferences,
certifications, etc.
• Executes SSDLC procedures (and
scans)
• Triages findings into product
backlog
• Work with SSG on Threat modeling
and secure architecture
• Reward and Recognize Publicly
SECURITY CHAMPIONS PROGRAM
SCALING
• Multiple full-time champions
per project
• SPOCs push the curve
identifying improvements, new
security tools and procedures
• Performs secure architecture
design and threat models
• Interested SPOCs rotate into
the SSG
“SPOC”
Security Point
of Contact

14. ANTI-PATTERNS
• SPOC is the only member of
the team responsible for
security. All security tasks and
questions assigned to SPOC
• SPOC is responsible to
prioritize security in the
product development cycle
(bottom-up)
• Adversarial or subordinate
relationship to the SSG
SECURITY CHAMPIONS PROGRAM - GOTCHAS
COURSE CORRECTIONS
• All devs are responsible for fixing
security defects. SPOC works with
devops, build managers, etc. to
automate security testing
• Execs, Product Managers,
Engineering Managers are
responsible to prioritize security
(top-down).
• SSG exists to support R&D
success. SSG and SPOC learn from
each other to improve in a
blameless culture.

16. Mandatory Developer
Security Training
EDUCATION & AWARENESS
Structured Training Programs Security Events Recognition & Rewards
Advanced, role-specific
and platform-specific
training, more hands-on
Behavioral achievements
& certifications
•Security Days
•Tournaments & Challenges
•Capture the flag (CTF)
OWASP Security Shepherd
•Security Stars Program
•Public Praise
•SWAG
•Brand your AppSec program
(T-Shirts)
•Hit-up your Vendors
(Hoodies, Stickers, etc.)

17. PROCESS

18. Define Security Gates and Passing Criteria
Source: Microsoft Security Development Lifecycle © 2010 Microsoft Corporation.

19. BSIMM SM1.4,
“defining checks in the process first and enforcing them later is extremely helpful in moving development
toward security without major pain.
Socializing the conditions and then verifying them once most projects already know how to succeed is a
gradual approach that can motivate good behavior without requiring it.”
SECURITY GATES (PRO-TIP)
Merge security into the existing development cycles. First, identify
the gates & collect the results. But don’t enforce them (yet).
“Be shapeless, formless, like water. Water can flow
or water can crash. Be water.” –Bruce Lee

20. Third-party software component analysis
• For Initial Security Review (ISR) and Final Security Review (FSR) the project is scanned using
approved SCA tool(s).
• All results are reviewed by the development team
• All critical, high, and medium issues are resolved prior to release. (*with enforcement at FSR)
EXAMPLE Security Gate / Security Bar
Other Security Bars (gates) to define:
• Threat modeling / Secure design review
• Static Application Security Test (SAST)
• Container Vulnerability Analysis
• Attack surface analysis
• Dynamic Application Security Test (DAST)

21. “I fear not who has practiced
10,000 kicks once, but I fear who
has practiced one kick 10,000
times.”
– Bruce Lee

22. CONTINUOUS SECURITY & DevSecOps
• Initial Security Review (ISR)
• Security Requirements
• Threat Model
• Training
• Dynamic Analysis (DAST)
• Attack Surface Analysis
• Red Team Pentest
• Container Scanning
• Secure Code Review
• Static Analysis (SAST)
• 3rd-party Component Analysis
• Incident/Intrusion Detection
• Incident Response
• Vulnerability Scanning
• Hardening/Config Management
• Infra Vulnerability Scanning
• Verification
• 3rd party pentesting
• Access Control
• Audits
• Change Control
• Vulnerability Management
• Application Security Bar
• Cloud Security Bar
• Final Security Review (FSR)
• Continuous Security Review (CSR)
DEV OPS

23. CONTINUOUS SECURITY PIPELINE (example)
Defect
Management
Tracking
Attack Surface
Analysis
Dynamic Analysis
(DAST)
Threat
Modeling
Static
Application Testing
(SAST)
Software
Composition / 3rd-
party (SCA)
Container Security
Code
commit
Deploy to Production
Deploy to
staging
Threat & Risk
Correlation
Runtime Analysis &
Monitoring
Vulnerability Scanning
Security Event
Management (SIEM)
CIS Compliance
Cloud Configuration
Monitoring
Host Intrusion Detection
(HIDS)
IAM & Privilege
Management
Continuous Security
Review

24. Dev’s want fast build times and immediate feedback
• Problem: Some security tests cannot be done on every build
• Solution: CI pipeline runs security tests inline in the build (where applicable) and for longer running
tests or manual security tasks (e.g., threat model), it fetches the latest results via API.
Security in CICD

25. Governance

26. • Aggregate security
metrics to communicate
overall risk level.
• Share at the executive
level to show trends and
current security posture.
• Share across all of R&D
so every team can see
how they’re doing
relative to the business
KPI Metrics & Dashboards

27. Released Software (with
security) is our goal.
Conditional Pass Requires:
1. Mitigation Plan
2. Executive Risk Approval
Captured in Ticketing System
and enforced by automation
and orchestration.
SECURITY EXCEPTIONS & RISK APPROVAL

28. Summary
•Culture
•Process
•Governance
Begin where you are...
The warrior’s journey starts with the first step.

29. I would greatly appreciate your thoughts, comments, feedback, disagreements,
complaints, arguments, etc...
Where to find me....
Brian Levine

30. • Microsoft Security Development Lifecycle © 2010 Microsoft Corporation.
• The Software Assurance Maturity Model (SAMM) was created by Pravir Chandra and is now an Open
Web Application Security Project (OWASP) project.
SAMM is licensed under the Creative Commons Attribution-Share Alike 4.0 License
https://owaspsamm.org/
• BSIMM LICENSE
This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License. To view a copy of
this license,visit http://creativecommons.org/licenses/by-sa/3.0/legalcode or send a letter to Creative
Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
ATTRIBUTIONS
Image by Gordon Johnson from Pixabay