Secure by Design
An approach where security is built into a product's architecture, code and development process from the very beginning, instead of being added on top at the end.
Also known as: Security by Design, Secure-by-Design
Category: Software Development
Tags: security, cybersecurity, software-design, software-development, software-architecture, principles, best-practices
Explanation
For decades, software security worked like this: build the product, ship it, then fix the vulnerabilities as attackers find them. Patch, patch, patch. The cost of that approach lands on customers, who have to install updates, configure protections and clean up after breaches.
Secure by Design flips that. Security becomes a core requirement from day one, at the same level as features and performance. It shapes the architecture, the choice of languages and libraries, the APIs, and how the team works.
**What it looks like in practice**:
- **Threat modeling early**: Ask "what could go wrong?" while designing, not after shipping
- **Memory-safe languages** where possible, to remove entire classes of vulnerabilities
- **Safe-by-construction APIs**: parameterized queries, auto-escaping templates, typed domain primitives instead of raw strings
- **Least privilege and defense in depth** built into the architecture
- **Secure defaults** (see Secure by Default) so what ships is protected out of the box
- **Security in the development process**: code review, dependency scanning and security testing (see shift left and DevSecOps)
- **Transparency**: publishing vulnerability data and fixing root causes, instead of quietly patching symptoms
**Two meanings worth knowing**:
1. **The industry movement**: In 2023, CISA and partner agencies from several countries published joint guidance on Secure by Design. Their core message is that software manufacturers, not customers, should own the security outcomes of their products. In 2024, CISA launched a Secure by Design pledge that software companies can sign
2. **The book**: Secure by Design (2019) by Dan Bergh Johnsson, Daniel Deogun and Daniel Sawano argues that good design and good security go hand in hand. Their key idea is the domain primitive: a small value object (e.g., `EmailAddress`, `Quantity`) that validates itself at creation. If invalid data can't exist, a lot of injection and logic attacks have nothing to work with
**Secure by Design vs. Secure by Default**:
The two work together. Secure by Design is about how the product is built. Secure by Default is about how it ships. A product built securely but shipped with an open admin panel and default credentials still fails its users.
This is the Pit of Success applied to security engineering: when the architecture makes insecure code hard to write, developers end up writing secure code without thinking about it.
Related Concepts
← Back to all concepts