Security by design embeds security requirements into architecture and planning before code is written. Security testing checks whether the implemented application actually meets those requirements through SAST, DAST, pen testing, and related reviews. In practice, design sets the control objectives and testing validates execution. A mature program needs both, because design without testing misses defects, and testing without design is too late.
Why This Matters for Security Teams
Security by design and security testing solve different failure modes in an application security program. Design work determines whether security requirements are built into architecture, data flows, trust boundaries, and third-party integrations before implementation starts. Testing determines whether the delivered application actually behaves as intended under realistic conditions. OWASP ASVS is useful here because it turns design intent into verifiable requirements, rather than treating security as a vague quality goal.
The practical distinction matters because teams often confuse “we tested it” with “we designed it safely.” A secure architecture can still fail if implementation drifts, while heavy testing cannot fully compensate for weak trust assumptions, missing authorization boundaries, or poor data handling choices made up front. Mature programs use design to prevent predictable classes of defects and testing to prove that controls survived contact with real code. In practice, many security teams discover the gap only after development is complete, when the cost of rework is already high.
How It Works in Practice
Security by design starts before code exists. It shapes the application’s security posture through requirements, architecture review, threat modelling, trust boundary definition, and secure defaults. The question is not just “can this feature be built?” but “what must be true for it to be safe?” That means deciding early on authentication flows, authorization rules, input handling, logging, data retention, and failure behaviour. When this step is done well, developers inherit a clear target instead of retrofitting controls later.
Security testing is the validation layer. It checks whether the implemented system matches the intended controls and whether new code introduced regressions. In an application security program, that usually includes:
SAST to find code-level patterns such as unsafe data handling or weak validation.
DAST to exercise the running application from the outside and observe exposed behaviour.
Pen testing to explore chained weaknesses, misconfigurations, and real attack paths.
Reviews of dependencies, configuration, and runtime controls when the implementation shape matters.
The two are complementary, not interchangeable. Design establishes the control objective, for example “only authorised users may reach this function,” while testing proves whether the code and deployment actually enforce that objective. Security by design is strongest when it is integrated into planning gates, architecture decisions, and engineering standards. Security testing is strongest when it is continuous, risk-based, and tied to release decisions rather than treated as a one-time sign-off. OWASP Web Security Testing Guide is a useful reference for structuring that validation work.
These controls tend to break down when teams treat design reviews as documentation exercises and testing as a late-stage checkbox, because neither catches drift between intent and implementation.
Common Variations and Edge Cases
Tighter design controls often increase upfront coordination, so teams must balance delivery speed against the cost of fixing structural mistakes later. In some organisations, “security by design” is embedded in architecture governance and “security testing” is owned by a separate assurance function; in others, the same team performs both. The ownership model matters less than whether the design decisions are explicit and the test evidence is actually used to change code or release decisions.
Some questions that look like testing questions are really design questions. If the repeated defect is missing authorization, unsafe defaults, or unclear trust boundaries, more scanning will not solve the root cause. Conversely, some design choices are only trustworthy when the implementation can be observed under test, especially for APIs, distributed systems, and controls that depend on runtime configuration. Current guidance suggests using design to prevent systemic weaknesses and testing to catch what still slips through.
There is also a common edge case in mature programs: a control may be correctly designed but poorly testable. That is a signal to improve observability, assertions, and acceptance criteria, not to weaken the control. Security teams should also be wary of overvaluing one test method. Static analysis, dynamic testing, and manual review each see different failure classes, so no single technique proves the whole security posture.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl and Credential Exposure | Application testing must catch exposed secrets and weak handling. |
| NHI-03 — Overprivilege and Excessive Permissions | Design and testing both need authorization boundaries that hold. | |
| Recommendation — Scan code, configs, and CI/CD for exposed secrets and rotate anything found. Enforce least privilege and test that privilege boundaries resist bypass. | ||
| OWASP Agentic AI Top 10 | A2 — Tool and Action Authorization | Agentic apps need design-time authority limits and runtime validation. |
| A4 — Prompt Injection and Input Manipulation | Testing must prove resilience against malicious input and control abuse. | |
| Recommendation — Define tool permissions up front and test that agents cannot exceed them. Red-team prompts and inputs to verify the application resists manipulation. | ||
Practitioner Guidance
What to prioritise: Treat security by design as the mechanism that sets requirements and boundaries, then use testing to verify the most failure-prone paths first: authentication, authorization, input handling, session behaviour, and sensitive data flows. If those are weak, broader coverage adds limited value.
Decision rule: If a defect would require architectural change to fix, it is a design problem. If the issue is whether the built system behaves as intended, it is a testing problem. Escalate design gaps earlier in the lifecycle, and reserve testing for proving that implemented controls really hold under realistic conditions.
What to verify: Ask whether every security requirement is stated in a form that can be tested, and whether every major test has a traceable requirement behind it. The best programs can show the link from threat model to control objective to test evidence without guessing how the control was supposed to work.
Practitioner takeaway: Security by design reduces the number of ways an application can fail, while security testing reveals the ways it still does fail, and the gap between those two is where most program maturity issues show up.
Related resources from NHI Mgmt Group
- What is the difference between static analysis and dynamic testing in application security?
- What is the difference between shift left application security and traditional late-stage testing?
- What is the difference between probabilistic and deterministic security testing in application pipelines?
- What is the difference between design review and SAST in application security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
