Secure Development and Integration
Secure development is described in the OWASP Software Assurance Maturity Model (SAMM) Design, Implementation and Verification business functions.
Prelude
The best introduction to practical secure software development is the OWASP Application Security Fragmentation article :
Or how I worried less and stood on the shoulders of giants. - Spyros Gasteratos, Elie Saad
Much of the material in this section is drawn from this OWASP Integration Standards project.
Overview
Almost all modern software is developed in an iterative manner passing through phase to phase, such as identifying customer requirements, implementation and test. These phases are revisited in a cyclic manner throughout the lifetime of the application. A notional Software Development LifeCycle (SDLC) is shown below, in practice there may be more or less phases according to the processes adopted by the organization.

With the increasing number and sophistication of exploits against almost every application or business system, most companies have adopted a secure Software Development LifeCycle (SDLC). The secure SDLC should never be a separate lifecycle from an existing software development lifecycle, it must always be the same development lifecycle as before but with security actions built into each phase, otherwise security actions may well be set aside by busy development teams. Note that although the Secure SDLC could be written as ‘SSDLC’ it is almost always written as ‘SDLC’.
DevOps integrates and automates many of the SDLC phases and implements Continuous Integration (CI) and Continuous Delivery/Deployment (CD) pipelines to provide much of the SDLC automation.
DevOps and pipelines have been successfully exploited with serious large scale consequences and so, in a similar manner to the SDLC, much of the DevOps actions have also had security built in to them. Secure DevOps, or DevSecOps, builds security practices into the DevOps activities to guard against attack and to provide the SDLC with automated security testing.
Examples of how DevSecOps is ‘building security in’ is the provision of Interactive, Static and Dynamic Application Security Testing (IAST, SAST & DAST) and implementing supply chain security, and there are many other security activities that can be applied. Refer to the CI/CD Security Cheat Sheet for the latest DevSecOps security controls.
Secure development lifecycle
Referring to the OWASP Application Security Wayfinder development cycle there are four iterative phases during application development: Requirements, Design, Implementation and Verification. The other phases are done less iteratively in the development cycle but these form an equally important part of the SDLC: Gap Analysis, Metrics, Operation and Training & Culture Building.
All of these phases of the SDLC should have security activities built into them, rather than done as separate activities. If security is built into these phases then the overhead becomes much less and the resistance from the development teams decreases. The goal is for the secure SDLC to become as familiar a process as before, with the development teams taking ownership of the security activities within each phase.
There are many OWASP tools and resources to help build security into the SDLC.
- Requirements: this phase determines the functional, non-functional and security requirements for the application. Requirements should be revisited periodically and checked for completeness and validity, and it is worth considering various OWASP tools to help with this;
- the Application Security Verification Standard (ASVS) provides developers with a list of requirements for secure development,
- the Mobile Application Security project provides a security standard for mobile applications and SecurityRAT helps identify an initial set of security requirements.
Further reading from OWASP
- Cheat Sheet Series
- CI/CD Security Cheat Sheet
- Cornucopia
- CycloneDX Bill of Materials (BOM) standard
- DevSecOps Guideline
- Security Champions Guide
- Security Culture project
- Top 10 Proactive Controls
OWASP verification projects
- Application Security Verification Standard (ASVS)
- Amass project
- Code Pulse
- Defect Dojo
- Mobile Application Security (MAS)
- Nettacker
- Offensive Web Testing Framework (OWTF)
- Web Security Testing Guide (WSTG)
- Zed Attack Proxy (ZAP)
OWASP training projects
- API Security Project (API Top 10)
- Juice Shop
- Mobile Top 10
- Security Shepherd
- Snakes And Ladders
- Top Ten Web Application security risks
- WebGoat
OWASP resources
- CSRFGuard library
- Dependency-Check Software Composition Analysis (SCA)
- Dependency-Track Continuous SBOM Analysis Platform
- Enterprise Security API (ESAPI)
- Integration Standards project Application Security Wayfinder
- Mobile Application Security (MAS)
- Pythonic Threat Modeling
- Threat Dragon
- SecurityRAT (Requirement Automation Tool)
The OWASP Developer Guide is a community effort; if there is something that needs changing then submit an issue or edit on GitHub.
The OWASP ® Foundation works to improve the security of software through its community-led open source software projects, hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.
Developer Guide (draft)
- 1. Introduction
- 2. Foundations
- 2.1 Security fundamentals
- 2.2 Secure development and integration
- 2.3 Principles of security
- 2.4 Principles of cryptography
- 2.5 OWASP Top 10
- 3. Requirements
- 3.1 Requirements in practice
- 3.2 Risk profile
- 3.3 OpenCRE and Integration Standards
- 3.4 SecurityRAT
- 3.5 Application Security Verification Standard
- 3.6 Mobile Application Security
- 3.7 Security Knowledge Framework
- 4. Design
- 4.1 Threat modeling
- 4.1.1 Threat modeling in practice
- 4.1.2 pytm
- 4.1.3 Threat Dragon
- 4.1.4 Cornucopia
- 4.1.5 LINDDUN GO
- 4.1.6 Threat Modeling toolkit
- 4.2 Web application checklist
- 4.2.1 Checklist: Define Security Requirements
- 4.2.2 Checklist: Leverage Security Frameworks and Libraries
- 4.2.3 Checklist: Secure Database Access
- 4.2.4 Checklist: Encode and Escape Data
- 4.2.5 Checklist: Validate All Inputs
- 4.2.6 Checklist: Implement Digital Identity
- 4.2.7 Checklist: Enforce Access Controls
- 4.2.8 Checklist: Protect Data Everywhere
- 4.2.9 Checklist: Implement Security Logging and Monitoring
- 4.2.10 Checklist: Handle all Errors and Exceptions
- 4.3 Mobile application checklist
- 5. Implementation
- 5.1 Documentation
- 5.1.1 Top 10 Proactive Controls
- 5.1.2 Go Secure Coding Practices
- 5.1.3 Cheatsheet Series
- 5.2 Dependencies
- 5.2.1 Dependency_Check
- 5.2.2 Dependency_Track
- 5.2.3 CycloneDX
- 5.3 Secure Libraries
- 5.3.1 Enterprise Security API library
- 5.3.2 CSRFGuard library
- 5.3.3 OWASP Secure Headers Project
- 6. Verification
- 6.1 Guides
- 6.1.1 Web Security Testing Guide
- 6.1.2 MAS Testing Guide
- 6.1.3 Application Security Verification Standard
- 6.2 Tools
- 6.2.1 Zed Attack Proxy
- 6.2.2 Amass
- 6.2.3 Offensive Web Testing Framework
- 6.2.4 Nettacker
- 6.2.5 OWASP Secure Headers Project
- 6.3 Frameworks
- 6.3.1 secureCodeBox
- 6.4 Vulnerability management
- 6.4.1 DefectDojo
- 7. Training and Education
- 7.1 Vulnerable Applications
- 7.1.1 Juice Shop
- 7.1.2 WebGoat
- 7.1.3 PyGoat
- 7.1.4 Security Shepherd
- 7.2 Secure Coding Dojo
- 7.3 Security Knowledge Framework
- 7.4 SamuraiWTF
- 7.5 OWASP Top 10 project
- 7.6 Mobile Top 10
- 7.7 API Top 10
- 7.8 WrongSecrets
- 7.9 OWASP Snakes and Ladders
- 8. Culture building and Process maturing
- 8.1 Security Culture
- 8.2 Security Champions
- 8.2.1 Security champions program
- 8.2.2 Security Champions Guide
- 8.2.3 Security Champions Playbook
- 8.3 Software Assurance Maturity Model
- 8.4 Application Security Verification Standard
- 8.5 Mobile Application Security
- 9. Operations
- 9.1 DevSecOps Guideline
- 9.2 Coraza Web Application Firewall
- 9.3 ModSecurity Web Application Firewall
- 9.4 OWASP CRS
- 10. Metrics
- 11. Security gap analysis
- 11.1 Guides
- 11.1.1 Software Assurance Maturity Model
- 11.1.2 Application Security Verification Standard
- 11.1.3 Mobile Application Security
- 11.2 Bug Logging Tool
- 12. Appendices
- 12.1 Implementation Do's and Don'ts
- 12.1.1 Container security
- 12.1.2 Secure coding
- 12.1.3 Cryptographic practices
- 12.1.4 Application spoofing
- 12.1.5 Content Security Policy (CSP)
- 12.1.6 Exception and error handling
- 12.1.7 File management
- 12.1.8 Memory management
- 12.2 Verification Do's and Don'ts
- 12.2.1 Secure environment
- 12.2.2 System hardening
- 12.2.3 Open Source software
Upcoming OWASP Global Events
Corporate Supporters
OWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec California, AppSec Cali, SnowFROC, and LASCON are trademarks of the OWASP Foundation, Inc. Unless otherwise specified, all content on the site is Creative Commons Attribution-ShareAlike v4.0 and provided without warranty of service or accuracy. For more information, please refer to our General Disclaimer. OWASP does not endorse or recommend commercial products or services, allowing our community to remain vendor neutral with the collective wisdom of the best minds in software security worldwide. Copyright 2024, OWASP Foundation, Inc.