Security by design means that every phase of the software development lifecycle produces a security outcome, rather than one phase at the end producing a verdict. It is an engineering sequence, not a slogan, and each phase has its own artefacts, its own techniques and its own way of failing.
Quick Overview
The phrase is usually explained as a culture. That framing skips what practitioners need: what actually changes in the work. This article walks the lifecycle phase by phase and states what each one owes:
- Why the late gate fails — and what it costs beyond the obvious
- Requirements and design — security requirements and threat modelling as design artefacts
- Code — the practices that eliminate whole classes of defect rather than instances
- Testing — what static, dynamic, interactive and composition analysis each catch
- Deployment and operation — configuration, dependencies, and the response plan
- Culture — why it is the consequence of the sequence, not its entry point
The boundary with the adjacent topic is worth stating up front. DevSecOps as a way of organising teams, tools and shared responsibility is covered separately in the guide to DevSecOps culture and tooling. What follows here is narrower and more mechanical: the engineering work each lifecycle phase has to do.
Why Bolting Security On At The End Fails
The traditional arrangement puts security at the boundary before release: a penetration test, an audit, a sign-off. It fails for reasons that compound.
Remediation gets more expensive the later a defect is found: at the requirements stage it costs a sentence, after release it costs a patch, a regression cycle, a deployment and a customer conversation. Late discovery also arrives at the worst moment for the schedule, which is why late findings so often become accepted risks rather than fixed defects — the deadline wins the argument.
The deeper problem is that a late gate can only find instances. A penetration test reports that a particular input is not validated. It cannot report that the application has no input validation strategy, because that is a design property and the test never saw the design. Fixes made there patch symptoms, and the same class of defect reappears in the next feature. National guidance now states the expectation directly: the CISA Secure by Design programme places responsibility for eliminating classes of vulnerability on the producer of the software rather than on whoever tests it last.
Requirements and Design: Making Security an Artefact
Security work begins where the functional requirements are written, and it begins by making implicit assumptions explicit. Who may see this data. What happens to it at rest. How a session ends. What the system does when authorisation is ambiguous. Requirements written this way are testable; the same expectations left unwritten become opinions that surface during code review as personal preference.
The NIST Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities organises these expectations into practices an organisation can adopt and evidence, which matters because “we take security seriously” is not a control and cannot be audited.
Threat modelling is the design-phase technique, and it is cheap relative to what it prevents. The team describes what the system does, decomposes it into components and data flows, then asks systematically where an attacker could interfere. Structured approaches such as STRIDE exist so the question is asked exhaustively rather than imaginatively — the value is in the coverage of the enumeration, not the cleverness of any individual answer. The output is a set of design decisions: a boundary moved, a trust assumption removed, a mechanism added. Because it happens before implementation, the expensive corrections are the ones never built.
Code: Eliminating Classes, Not Instances
At the coding phase the goal shifts from designing defences to not creating openings. The categories are well documented — the OWASP Top Ten Web Application Security Risks catalogue is the common reference — and the durable improvements are structural rather than vigilant.
Injection is prevented by parameterised queries and interfaces that make string concatenation of untrusted input inconvenient, not by remembering to escape. Cross-site scripting is prevented by output encoding applied by the rendering layer, not by each developer. Secrets stay out of source control because a secrets manager exists and the pipeline rejects commits that contain credentials. Errors are handled so that a failure returns a useful signal to the operator and an uninformative one to the caller.
The pattern is the same in each case: change the environment so that the insecure version requires deliberate effort. The OWASP Application Security Verification Standard (ASVS) is useful here because it converts that intention into checkable requirements at a stated level of assurance, which turns “write secure code” into a list. In languages where memory handling is the developer’s responsibility the discipline is stricter still, which is why grounding in secure programming remains a distinct competency rather than a general one.
Testing: What Each Technique Actually Catches
Automated security testing belongs in the pipeline, and the techniques are complementary rather than competing.
- Static analysis reads source code without running it, catching injection patterns, unsafe calls and dangerous defaults early and cheaply, at the price of false positives
- Dynamic analysis exercises a running application from the outside, finding what only appears at runtime — misconfiguration, authentication weaknesses, exposed endpoints — but only where it reaches
- Interactive analysis instruments the running application, combining the visibility of static analysis with the realism of dynamic
- Composition analysis inventories dependencies and matches them against known vulnerabilities, which is where a large share of real exposure sits
Treating any one of these as the security test is the common mistake: static analysis will not find a broken access-control rule, and dynamic analysis will not find the vulnerable library that is present but unreached. Placement matters as much as selection — a scan that runs weekly and reports into a queue nobody owns is documentation, not a control. Keeping pace with the tooling and its failure modes is an ongoing task, which is what a survey of secure coding trends and practices is for.
Deployment and Operation: Configuration, Dependencies, Response
A securely written application deployed onto a permissive environment is not secure, and the failure is invisible to everything upstream. Configuration is therefore part of the lifecycle: environments defined as code, differences between them deliberate and reviewable, permissions granted narrowly.
Dependencies need a durable record rather than a periodic scan. A software bill of materials, in a machine-readable format such as the one described in CycloneDX: Specification Overview, means the question “are we affected by this disclosure” is answered by a query instead of an investigation. Organisations without one discover their exposure by reading the news.
The last phase is response. Monitoring has to be capable of showing that something is being attempted, and the plan for what happens next has to exist before it is needed. This is also where the boundary with operations is negotiated, and where security priorities meet delivery pressure most directly — a tension examined in the discussion of security priorities in DevOps.
Culture Is the Consequence, Not the Entry Point
Culture change is usually presented as the first step. It is more reliably the last one, and it arrives on its own once the sequence above is real.
Developers treat security as shared work when the pipeline gives them fast, specific feedback they can act on; they treat it as somebody else’s department when it arrives as a quarterly report of findings. Nothing about that is attitudinal. Organisations that begin with awareness campaigns and end with unchanged tooling get compliance without behaviour. The order that works is the reverse: instrument the lifecycle, make the secure path the convenient one, and let the culture follow — an approach consistent with wider modern software development practice rather than separate from it.
Frequently Asked Questions
Does building security in slow delivery down?
It moves the cost earlier rather than adding to it. The visible slowdown is at the requirements and design stage; the saving is in defects that are never written, emergency patches that are never needed, and releases that are not held at the final gate.
Where should an organisation start if none of this exists?
With composition analysis and secrets scanning in the existing pipeline. Both are quick to add, both surface real exposure immediately, and neither requires the development process to be redesigned first. Threat modelling can follow once there is evidence the pipeline is trusted.
Is threat modelling worth it for a small application?
Yes, and it is cheaper there. A small system can be decomposed in a single session, and the enumeration still catches the trust assumptions nobody stated. What does not scale down is a heavyweight formal method — the technique should match the size of the system.
How is this different from DevSecOps?
Security by design describes what each lifecycle phase must produce. DevSecOps describes how teams, tooling and responsibility are organised to deliver it continuously. The first is an engineering sequence; the second is an operating model built on top of it.