Security by design (SbD) explained
Security by design (SbD) is a software development approach that embeds security controls into products from the earliest design phase rather than adding them later. This means enterprises can deploy software that is secure out of the box without purchasing additional security features or scrambling to patch vulnerabilities after release.
Think of it like building a warehouse for valuable goods. You could construct walls from plywood and then bolt on sensors, cameras, and guards. Or you could build with reinforced concrete and heavy steel doors from the start, then add the same monitoring. The concrete warehouse is inherently harder to breach regardless of what security you layer on top. SbD applies this same logic to software: build the foundation secure, and every additional control compounds rather than compensates.
Catch code risks before you deploy
Learn how Wiz Code scans IaC, containers, and pipelines to stop misconfigurations and vulnerabilities before they hit your cloud.
Why security by design?
Enterprises bear the legal, financial, and reputational consequences when breaches occur, yet they historically had little control over whether the software they purchased was secure. Vendors shipped products with security as an afterthought, forcing customers to buy add-on protections and apply emergency patches. This "vulnerable by design" model worked for vendors who profited from selling fixes, but it left enterprises exposed to supply chain attacks and compliance failures.
SbD addresses this "penalize the enterprise user, spare the vendor" problem by promoting a culture of software development whereby both the user and vendor are held responsible for their actions or inactions. This improves both the vendors' and users' software security posture by reducing their attack surface and facilitating other key outcomes.
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download Cheat Sheet
Easier, cheaper patching
Applying security fixes in a hurry while the software is in use (to prevent data breaches and associated financial and reputational damage) can be a pain in the neck, costly, and fraught with error.
Products designed to be secure from the outset require fewer and less critical patches, making the process a whole lot cheaper and easier.
Cost-effective products
The only way to secure vulnerable-by-design systems is to bolt on multiple add-ons. However, attackers can still leverage the backdoors created by the VbD flaw to infiltrate systems.
Securing systems by default is more cost-effective than facing a higher risk of data breaches and their associated costs, lawsuits, and fines.
Regulatory compliance
Since software developed using the SbD approach has security at its core, they are more likely to be compliant by default. This eases the process of checking different software components to ensure compliance with various regulations.
How security by design differs from traditional security
Traditional security treats protection as a layer added after software is built. Teams write code, ship the product, then bolt on firewalls, endpoint agents, and monitoring tools to defend what already exists. When vulnerabilities surface, patches follow, sometimes months after exploitation begins.
Security by design inverts this sequence. Security requirements are defined before the first line of code is written. Threat modeling happens during architecture reviews, not after production incidents. Controls are native to the application rather than wrapped around it.
| Approach | What it looks like in practice | Where it commonly breaks |
|---|---|---|
| Traditional (bolt-on) | Security controls are added after release or after deployment. | A "secure" environment depends on perfect configuration and constant manual follow-up. |
| Security by design | Safe defaults, opinionated guardrails, and least-privilege built into the product and its workflows. | Legacy features and compatibility modes keep unsafe paths alive unless they are actively removed. |
| Security by default (related, not identical) | Common installs start safe without extra steps. | Can still miss deeper design issues like weak isolation boundaries or insecure extensibility. |
The practical difference shows up in how teams spend their time. Traditional approaches generate a constant stream of reactive work: emergency patches, incident response, and compliance remediation. SbD front-loads that effort into design and development, where fixes are cheaper and less disruptive. A vulnerability caught during code review costs a fraction of what the same flaw costs after it reaches production and gets exploited.
In cloud-native environments, security by design needs to account for identity and exposure. The design has to assume users will over-permission roles, attach public IPs, and deploy quickly, then make those unsafe states harder to create.
How does security by design work?
The SbD approach has four key stages, which we explore below.
Stage 1: Define security requirements
SbD begins with a clear study of the software to be developed, its potential vulnerabilities, and corresponding security requirements. For a database service, security requirements would include encryption, role-based access control (RBAC), and other authorization techniques.
Stage 2: Conduct risk assessments and threat modeling
This stage entails using a context-sensitive vulnerability scanner to map out the software’s potential attack paths.
For example, a database service provider is exposed to possible attack paths such as public IPs or privileged accounts due to sensitive personal identifiable information (PII) and protected health information (PHI) stored in its databases.
Free Cloud Risk Assessment
Connect with a Wiz expert for a personal walkthrough of the critical risks in each layer of your environment.
Request Assessment
Stage 3: Write code and build security measures simultaneously
In this stage, the engineering team jettisons conventional coding procedures to develop software with native security measures. For the database provider, this could include writing code that:
Prevents databases from being open to the public by default
Automatically validates user input without enterprise users having to purchase add-ons
Requires multiple authentication mechanisms before any form of access is granted
Limits access points for privileged accounts
Stage 4: Continuously monitor and patch
Finally, the software is tested and, if found to be secure by design, shipped. As users deploy the software, the vendor continuously monitors, audits, and sends out SbD updates as new threats and vulnerabilities emerge.
Security by design principles
CISA has emerged as the leading voice pushing software vendors toward accountability for security outcomes. The agency's Secure by Design guidance outlines three core principles—Take Ownership of Customer Security Outcomes, Embrace Radical Transparency and Accountability, and Lead From the Top—that shift responsibility from enterprise customers back to the manufacturers who build the software.
Shared responsibility
Vendors and customers both carry security obligations, but the balance shifts under SbD. Manufacturers must build products that are secure by default and release timely patches as threats evolve. Customers remain responsible for secure configuration, access controls, and protecting their own data. In practice, this means a cloud database vendor ensures encryption is enabled by default, while the customer manages who has access to query that data.
Radical transparency
Software manufacturers should share information about what makes their products secure by design. They are accountable to their customers for accurate vulnerability advisories, the associated common vulnerability and exposure (CVE) records, and authentication mechanisms, to name a few of the things expected of an SbD product.
Organizational structure
SbD requires C-suite-level commitment and communication between all stakeholders. Collaboration is key between vendors and customers as well as developers and security teams. This will facilitate the implementation of near-impenetrable security controls and enable insight-based budget planning and resource allocation.
Challenges of implementing security by design
| Challenge | Description |
|---|---|
| Short-term costs vs. long-term profits | The cost of restructuring legacy software and switching programming languages to embed security rather than bolt it on is discouraging for most vendors. Even in modern systems, embedding security is a complex and costly process. Still, in the long run, fewer and less complicated patches, fewer attacks, etc. will mean the initial cost pays for itself. |
| Marketability | The motivation for cloud vendors to implement SbD is low, as there are no direct monetary returns for them. It is difficult to market restructured SbD products on the "now secure-by-design" premise, as this will leave enterprise users with the presupposition that the products weren't properly built and secured earlier on. It is easier to sell legacy software as is, alongside aftersales/add-on security products like firewalls and antivirus. |
| Third-party vendor liability | An important implication of SbD is that software vendors are liable for supply chain vulnerabilities. For example, a single security flaw can affect several enterprise customers who would want the vendor to take the blame, i.e., face the financial and reputational consequences. Getting all parties onboard with the shared responsibility model is thus critical, as discussed above. This makes it clear that security is in fact a shared burden between the vendor and the customer. |
Security by design best practices
CISA offers some SbD tactics culled from the Secure Software Development Framework (SSDF) of the National Institute of Standards and Technology (NIST): NIST's SP 800-218. Organizations should integrate these practices into every stage of their software development lifecycle (SDLC).
Use secure software components
Deploy well-secured software components, including libraries, frameworks, and middleware, from verified providers only. Also, avoid software with known vulnerabilities, including cryptographic and authentication failures, broken access controls, injection vulnerabilities, and logging issues.
A cloud native application protection platform (CNAPP) will come in handy to detect unsecured components.
Adopt good design practices
Good design practices reduce the blast radius when something goes wrong:
Defense in depth: Layer multiple security controls so that if one fails, others still protect the system.
Sandboxing: Isolate components so a compromise in one area cannot spread to the rest of the application.
Patch-friendly architecture: Design software so updates can be applied with minimal downtime, encouraging faster adoption of security fixes.
Utilize memory-safe programming languages
NIST encourages developers to implement common memory-targeted mitigations such as control-flow integrity (CFI) and address space layout randomization (ASLR). But beyond this, NIST also notes they should adopt modern memory-safe languages, e.g., Rust, Go, Java, C#, Swift, and Python, while avoiding their memory-unsafe counterparts, C and C++.
This will help mitigate memory-safety vulnerabilities like SlammerWorm, Ghost Engine, and Stagefright.
Adopt parameterized queries and web template frameworks
Parameterized queries are SQL queries with parameters that separate user input from the query itself. Web template frameworks contain context-sensitive information that automatically prevents suspicious user input. Together, these mechanisms help prevent SQL injection and cross-site scripting (XSS) attacks.
Provide SBOMs
Software vendors should provide users with a list of the proprietary and third-party software components, libraries, and tools they used to develop software, often utilizing the three key formats of SPDX, CycloneDX, and SWID. This list, which can be generated via an agentless SBOM scanner, enables easy vulnerability resolution.
Eliminate default passwords
Providers must avoid rolling out products with default passwords. Instead, they should adopt multi-factor authentication and require users to set strong passwords immediately after they configure the software.
Provide software authorization profiles
These profiles designate user roles and use cases to limit unnecessary access to user data and privileged accounts. Software manufacturers should provide detailed software authorization profiles, implement the principle of least privilege, and issue warnings against deviating from the designated limits.
How Wiz supports security by design
Security by design is easiest to maintain when teams can quickly prove whether a design decision actually reduced real risk in production. This is where cloud context matters. If you cannot connect a weakness in code or configuration to how it is deployed, what it can reach, and what permissions it has, you end up treating every finding as equally urgent.
Building security into software from the design phase eliminates the endless cycle of patching, bolt-on tools, and emergency fixes that define legacy approaches. When vendors take responsibility for shipping secure products, enterprises can focus on configuring and operating those products safely rather than compensating for foundational flaws.
Wiz helps organizations verify whether the software they build and deploy actually meets SbD principles. By connecting code-level decisions to runtime cloud context, Wiz reveals how early design choices impact production exposure and attack paths. Teams can see which vulnerabilities are exploitable in their actual environment, not just which ones exist in theory.
SbD is a cheaper, faster, and more robust approach to building and securing apps. This is why Wiz is a leading advocate for shipping secure code. Its solution:
Facilitates end-to-end software visibility
Provides up-to-date SBOMs
Enables attack path analysis
Get a demo to see how Wiz connects code security to cloud risk.
See for yourself...
Learn what makes Wiz the platform to enable your cloud security operation
