About OWASP Secure by Design Framework
🔹 Introduction
Secure-by-Design (SbD) is a foundational approach in the software development lifecycle that ensures security is engineered into applications and services from the outset, making them resilient to threats and aligned with both regulatory and organizational policies.
This framework delivers structured, actionable guidance for embedding security during the architecture and system design phase of the SDLC—long before code is written. It closes the gap between high-level security requirements and code-level verification standards, enabling teams to design systems where security is a built-in foundation rather than an afterthought.
By applying these practices early, you not only reduce vulnerabilities and costly rework, but also create systems that are inherently more reliable, maintainable, and easier to verify.
â—˝ Scope
This framework focuses exclusively on design-time decisions—the architectural and systemic choices that determine how security is built into a solution. It is intended for:
It does not cover secure coding practices (e.g., OWASP Top 10, ASVS), implementation-phase testing or scanning, or the threat-modeling methodology itself, which follows design. The guidance here is about shaping secure architecture before development begins, ensuring that implementation work starts from a secure foundation.
â—˝ Why This Project Matters
Security flaws introduced during system design are often the most costly and complex to remediate—sometimes requiring fundamental architectural changes that ripple through the entire product. By embedding Secure-by-Design practices early, we prevent these issues before they materialize, avoiding expensive rework and reducing risk exposure.
Modern systems are increasingly distributed, API-driven, and interconnected. This complexity amplifies potential attack surfaces, dependency risks, and failure modes. Without intentional, principle-based design, security controls become inconsistent, bolt-on, and fragile—leaving gaps that can be exploited.
This project provides a structured, repeatable, and scalable way to align architecture decisions with proven security principles. It empowers:
In short, it shifts security from reactive gatekeeping to proactive enablement, making it part of the natural flow of product design and evolution.
â—˝ Relationship to Other OWASP Projects
Secure-by-Design does not exist in isolation—it is a critical link between other OWASP security practices across the entire SDLC. As shown in the diagram, the process begins in the Planning phase, where formal security requirements are established (e.g., via OWASP ASVS requirements mapping). These define the baseline protections the system must meet. In the Design phase, the SbD framework applies structured principles, architectural patterns, and specific controls to address those requirements before any code is written. For high-risk or business-critical projects, an optional Threat Modeling checkpoint follows to validate that chosen SbD controls mitigate the most critical threats and leave no significant risks unaddressed.
The lifecycle then flows into Development, where teams follow OWASP ASVS and other secure-coding standards to ensure implementation faithfully reflects the secure design. In the Test phase, security verification confirms that all layers—design, code, configuration, and deployment—work together as intended before release. This alignment embeds security at every stage, with SbD providing the architectural backbone that other OWASP practices reinforce. The result: systems that are secure by construction, not by retrofit.
End-to-End Security Integration in the SDLC
◽ What Is a Secure‑by‑Design Review?
A Secure-by-Design (SbD) Review is a structured assessment of an application’s architecture and design, performed before development begins, to ensure that security is engineered into the system from the outset.
It systematically examines components, data flows, interfaces, dependencies, and trust boundaries to verify that required security controls are built directly into the architectural blueprint.
Typical outcomes include:
â—˝ When and How Should It Be Considered?
SbD Reviews should be performed early and iteratively—during the Planning and Design phases, at the start of major epics, and whenever there is a significant architectural change (e.g., new external exposure, introduction of sensitive data, adoption of novel technology, or Tier-1 impact).
Run an SbD Review whenever:
The review process, participant roles, and hand-off mechanics are described in Section Secure-by-Design Process.
â—˝ Expected Benefits
By applying this framework and running Secure-by-Design reviews, teams can:
🔹 SbD Process
The Secure-by-Design Process is the operational playbook for applying Secure-by-Design during the design phase and engaging with AppSec efficiently without creating bottlenecks. It describes the end-to-end process, what a design review examines, when to escalate (risk-based triggers), how the SbD Review Checklist fits into the workflow, and the mechanics for handing off to AppSec. See the Process tab for the complete content.
🔹 SbD Principles & Recommendations
SbD Principles & Recommendations provide authoritative design-time guidance for building systems that are secure by construction. It is organized into six domains (core principles, architecture & service design, data management & protection, reliability & resilience, access control & secure communication, monitoring/testing/incident readiness) and translates the project’s security requirements into concrete, architect-level controls, and provides actionable, design‑time recommendations that architects and product teams apply while shaping systems. See the Principles tab for the full content.
🔹 SbD Review Checklist
The SbD Review Checklist is a condensed, control-oriented tool for self-review and for communicating with AppSec. It ensures the security requirements are verified before implementation. Each item abstracts key recommendations from the principles into a Yes/No/N-A decision with justification. The full checklist appears on the Checklist tab.
🔹 SbD Best Practices, Patterns & Reference Architectures
This is a living catalog of Secure-by-Design examples you can study and reuse. It illustrates how the Section Principles & Recommendations appear in real designs (trust boundaries, authN/Z, data protection, resilience, observability) without product‑specific noise. See the Catalog tab for the full content—reference architectures, reusable patterns, and contribution instructions.
🔹 Links
Download the full Secure-by-Design Framework (PDF) for easy offline use.
Project Resources
Project Leaders
ization approaches
secure channel enforcement
secret/key management
policy enforcement mechanisms
ization
Permissions
ization denials
rate-limit behavior)
incident readiness
data protection
resilience
observability—are put into practice
Project Information
Incubator Project
Classification
Incubator
OWASP is a nonprofit foundation improving software security through open-source projects, global communities, and education. All resources are free and open to everyone.
SlackOWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec California, AppSec Cali, SnowFROC, OWASP Boston Application Security Conference, and LASCON are trademarks of the OWASP Foundation, Inc.
© 2026, OWASP Foundation Inc. All rights reserved.