Security by design means treating security as a first-class requirement from the very start of software development instead of bolting it on at the end of a project. In practice that means building layered defenses, not inventing your own security technology, enforcing secure defaults and making threat modeling a fixed part of the development process.
Key Takeaways
- Using security mechanisms in isolation isn’t enough: if you rely on a single layer, attackers have a free run of the whole system after the first breach.
- Building your own encryption or authentication is a classic mistake, because even security technology built by professionals has weaknesses that only intensive testing uncovers.
- Threat modeling doesn’t have to be complicated. It’s enough to get the team together and ask, in a structured way, what is valuable, who wants it and what an attack might look like.
- Testers have a natural role in the security process, because they systematically ask what can go wrong and expose weaknesses before they turn into disasters.
Secure by Design: Security Belongs at the Start
Software that is secure by design treats security as part of the work from day one, and treating it as a downstream task is the most common mistake in software development. If you only think about security in the last ten percent of a project, you get ten percent security.
Security belongs to the same class of properties as performance, resilience and availability. In theory everyone understands this. In practice these qualities get pushed to later, and later never comes. Any tester can confirm that this plan doesn’t work.
Interest in security has shifted. Eoin Woods, who started speaking on the subject about ten years ago, remembers rooms with five people in the audience, all of them security specialists. Today those rooms are filled with software developers who genuinely care about the topic. That shift is what makes it possible to build security in early at all.
Why Security Experts and Development Teams Talk Past Each Other
The gap exists because the two sides speak different languages. Software developers often know security only in the abstract: authentication, authorization and auditing as terms, without any concrete implementation behind them.
Security engineers are smart specialists who do exactly that all day. But they often come from infrastructure and know little about modern software delivery. When the two meet, the expert quickly overwhelms the team with complicated material that supposedly has to be implemented at once, or disaster will strike.
That all-or-nothing logic is misleading. In security, nothing is absolute. Every decision is a trade-off, and the job is to find the right balance, not to demand maximum effort.
Design Principles Make Security Tangible
A manageable set of design principles helps teams more than an exhaustive catalog. Good principles are easy to understand, easy to remember and get developers thinking about security earlier.
When he looked around, Eoin Woods found collections ranging from eight or nine items to several hundred. The very large ones are all correct, and all useless: nobody works with hundreds of rules day to day. The practical route lies in the middle, with a set that covers most of what software teams need to know.
“I firmly believe that design principles help you make design decisions.”
(Eoin Woods)
Defense in Depth
Never rely on a single security mechanism. Today’s attackers are sophisticated enough to defeat any one mechanism, whether it’s encryption or an authentication system.
Almost every mechanism has weaknesses, or mistakes creep in when it’s applied. Several independent layers make sure an attacker doesn’t own the whole system after clearing one hurdle. In heavily protected systems, such as those run by government agencies, every layer has its own mechanisms. Break through one and you face the next. The goal is to make a break-in expensive.
Don’t Build Your Own Security Technology
Building your own security technology is much harder than it looks. Many less experienced developers underestimate the effort: they want to write their own password vault, or they wonder how hard encryption can really be.
The same goes for integrating with systems like OAuth for authentication and authorization. Find a library that does it. Even security technology built by professionals has weaknesses. Experienced security testers take every new product apart right away and always find something. The chance that a home-grown solution is cleaner is close to zero. On top of that comes extra work the project doesn’t need.
Between open source and commercial libraries, there is no universal winner. Open source offers transparency and many independent researchers checking the code. In certain markets, a closed-source product can be the better choice, as long as you ask the vendor the right questions.
Be Careful What You Trust
Don’t accept unauthorized or unauthenticated network connections, and watch what you let into your system. That applies to connections, to data and to the building blocks you assemble the system from.
Countless vulnerabilities let malicious data slip in. Just as important is the question of what you’re building on: open source components, but also commercial libraries and platforms. How secure are they, and how would you even notice a vulnerability?
Secure Defaults and Failing Safely
Software has to ship with secure default settings and fall back to a safe state when something goes wrong. This principle is called secure by default, and it is one building block of security by design: the design takes security into account, and the default settings make it effective from the moment the software ships. Default passwords are an old problem that refuses to die.
Older Oracle systems came with privileged accounts and fixed default passwords. The running joke was: if you have Oracle, you have a Scott Tiger account, a user “Scott” with the password “Tiger”. That demo user opened practically any system. The pattern lives on. Open source software, cloud demos and even enterprise-grade network hardware ship with preset users and passwords because it’s convenient. Convenient and insecure at the same time.
The second part is how a system behaves when it fails. A database vendor known for performance and availability built a tamper-proof audit trail at a customer’s request. The engineers, however, switched off the logging as soon as the storage was full or showed a fault, and simply kept processing. It took a beta customer to stop it: the audit trail was full, and processing carried on without any audit. From a throughput and availability point of view, the audit seemed expendable. It wasn’t.
Message-driven systems raise similar questions after a complex outage. On restart, does the system wait until all security services are available and end-to-end authentication is guaranteed? Or does it start processing whenever it gets the chance? The second option opens a window nobody meant to open.
Typed Interfaces Instead of the Lowest Common Denominator
The easiest way to move data between systems is also the most dangerous: turn everything into a string. That approach rejects nothing, which is exactly why it’s tempting.
And that’s where the hole is. Attackers send malformed strings that the string handler waves through. The damage happens later, when the data is converted into another format, and ranges from denial of service to exploits that run remote commands. If you read in large amounts of unstructured data without checking it carefully, you take on considerable risk.
Strongly typed interfaces are the safer answer, but they come at a price. They take more effort to build, are less flexible and are harder to evolve. That trade-off has to be made deliberately, especially in landscapes with many connected applications and APIs, where a problem that gets in would otherwise spread through every system.
How Security Gets Into the Development Process
Design principles speak to the people who design. The bigger question is how the whole team works together to deliver secure software. The answer is a secure software delivery lifecycle that spans the entire life of the product.
You don’t have to invent that lifecycle yourself. There are established models, for example from OWASP, an organization with extensive resources and a mature, widely used secure development lifecycle. Government agencies offer such models too. Start from a proven model and adapt it to your context instead of beginning from scratch.
Security is a non-functional requirement, and that’s where the trap lies: once the user stories are written, it’s often too late. That’s why security stories belong early in the process.
Attacker Stories and Threat Modeling
A simplified form of security analysis is the attacker story: how could someone attack this system? It’s the accessible version of the threat modeling that is part of every secure development lifecycle.
Threat modeling sounds complicated, but it isn’t. The team sits down and works through three questions in a structured way:
- What do we have that’s valuable? A piece of information, a financial transaction, or an action someone wants to trigger or block.
- Who would consider it valuable?
- How would that attacker go about getting it?
The approach resembles planning for high availability: you sit down and work out everything that could go wrong and what would happen in each case. Once you’ve been through that, you have a much clearer idea of how resilient your system really is. Adam Shostack’s book is considered the classic on the subject, and there are other good ones. The experts’ most important advice: don’t make it more complicated than it needs to be.
Zero-Day Vulnerabilities Can’t Be Designed Away
There is no single design trick against zero-day vulnerabilities, only several principles working together. If you rely on a single component and it has a zero-day, you’ll be attacked.
This is where defense in depth pays off directly. Then there’s the operational side: do you have a strategy for keeping your components up to date? In the open source era that’s hard. Some ecosystems, Node.js for example, consist of very fine-grained parts. Without automated support, you lose track of vulnerabilities.
Complete control over zero-days isn’t possible, because there’s a black market for these exploits and their existence is hard to detect. What remains is to be consistent within your own sphere of influence: know what’s in your system, and monitor its components for vulnerabilities automatically.
Testers Are Security’s Natural Advocates
Thinking about what could go wrong is part of a tester’s job. That makes testers the most valuable allies when it comes to anchoring security in a project, because most other roles don’t think that way.
Software architects think about risk too, but they’re under pressure to ship new features, or they spend two or three sprints focused on one quality attribute such as throughput. They know security matters, but their heads are elsewhere at the moment. That’s exactly where the tester steps in, noticing that a new feature bypasses the security check.
For that to work, teams need to encourage testers to ask these questions. There’s a risk that the tester feels unpopular for raising the awkward point. The right reaction isn’t defensiveness but thanks: without that question, the team would have made a mistake.
The DevOps mindset helps, because testers join the team earlier. In the past, the tester was the last to see the software and could only record what had already been done.
Who Else to Bring In Early
Besides the tester, the security engineer belongs at the table, ideally someone with experience in both application security and infrastructure. Invite them to the joint threat modeling session, ask the right questions, and they’ll raise points nobody on the team had thought of.
It pays to bring in an internal pen testing team early, not just for the final tests. Early penetration tests reveal everything that goes wrong. Things may look fine for now, but suddenly everyone realizes that this part has to be secure and isn’t yet. Sometimes even the product owner then recognizes that security is a bigger topic than they thought.
Frequently Asked Questions
Why Isn’t It Enough to Address Security Only Toward the End of a Project?
If you don’t think about security until the last ten percent of a project, you’ll only get ten percent security. Security belongs to the same category of characteristics as performance, reliability, and availability. In theory, this is clear to everyone, but in practice, people put it off until later, and later never comes. Retrofitting is the most common mistake in software development.
Does a team have to implement all of an expert’s security recommendations immediately?
No. In security, nothing is absolute; every decision is a trade-off, and the task is to find the right balance, not to demand the maximum effort. Security engineers quickly overwhelm development teams with complicated material that supposedly must be implemented immediately, or else disaster will strike. This all-or-nothing logic is misleading.
Does it make sense to develop encryption or a password vault on your own?
No. Building your own security technology is much harder than it looks, and less experienced developers regularly underestimate the effort involved. Even solutions built by professionals have weaknesses: Experienced security testers take every new product apart and always find something. The probability that a custom-built solution is more secure is close to zero. It’s better to use a library, even for OAuth.
What should a system do if logging fails or storage is full?
It should enter a safe state (that is, stop processing) rather than continue running without an audit trail. A database vendor built in a tamper-proof audit trail, but the engineers disabled the logging when storage was full. It wasn’t until a beta customer pointed it out that this was stopped. The same question arises during a reboot: Does the system wait until all security services are available?
Why are interfaces that pass all data as strings risky?
Because such an interface never rejects anything. Attackers send malformed strings, which the string processor lets through. The damage only occurs during conversion to another format and ranges from denial-of-service attacks to exploits for remote commands. Strongly typed interfaces are the safer solution, but they come at the cost of development effort, flexibility, and ease of future development.
How does a team get started with threat modeling?
The team gets together and works through three questions in a structured manner: What do we have that is valuable, such as information or a financial transaction? Who would consider this valuable? How would an attacker go about it? The approach is similar to planning for high availability. The most important advice is not to make it unnecessarily complicated.
When is a penetration test worthwhile during the course of a project?
Early on, not just for the final tests. Early penetration tests reveal everything that could go wrong and shift the team’s focus: Suddenly, everyone is thinking about how a certain part needs to be secure but isn’t yet. Sometimes even the product owner realizes that security is a bigger issue than they thought.
