Security Shift Left Design

# Shift-Left Security Design

> Find security flaws in the design document, not in the penetration test report -- because
> fixing an architecture flaw costs 100x more after deployment than during design

## When to Use

- Starting the design phase of a new feature, service, or system that handles sensitive data
- Conducting a design review and need a structured approach to identifying security concerns
- Integrating security into agile ceremonies without creating bottlenecks
- Building a secure SDLC process for an organization that currently does security only in QA
- Evaluating whether a proposed architecture has fundamental security weaknesses before writing
  code
- Defining security requirements alongside functional requirements for a new project

## Threat Context

The NIST/IBM Systems Sciences Institute data on defect cost escalation shows that a security flaw
found in the design phase costs 1x to fix, in implementation costs 6.5x, in testing costs 15x,
and in production costs 100x. These numbers are not theoretical -- they reflect the difference
between changing a design document and performing an emergency production deployment with data
breach notification, incident response, customer communication, and regulatory reporting.

The 2017 Equifax breach (CVE-2017-5638, Apache Struts) exposed 147 million records. The
vulnerability was in a third-party component, but the architectural failure was deeper: the
application ran with direct access to a database containing 147 million unencrypted SSNs, with no
network segmentation, no data access monitoring, and no principle of least privilege. These are
design-phase decisions. A threat model during design would have identified that a single web
application vulnerability should not grant access to the entire consumer database.

Organizations that defer security analysis to the testing phase consistently find architectural
flaws that cannot be fixed without redesigning the system. At that point, the choice is between
shipping an insecure architecture or missing the deadline by months. Shift-left security ensures
that security-critical design decisions are made when they are cheapest and easiest to change.

## Instructions

1. **Elicit security requirements alongside functional requirements.** For every user story or
   feature specification, ask: What data does this feature access, store, or transmit? Who is
   authorized to use this feature? What happens if this feature is abused? What compliance
   requirements apply? Security requirements are not separate from functional requirements --
   they are constraints on how functionality is implemented. Document them in the same backlog
   and give them the same priority as functional requirements.

2. **Conduct a threat model for every new feature that changes the trust boundary.** Not every
   feature needs a full STRIDE analysis, but any feature that introduces a new data flow, a new
   external integration, a new user role, or a new API endpoint should have a lightweight threat
   model. Use the "four question" approach: What are we building? What can go wrong? What are we
   going to do about it? Did we do a good job? This takes 30-60 minutes in a design review
   meeting and identifies architectural vulnerabilities that no scanner will find.

3. **Integrate security checkpoints into agile ceremonies.** Sprint planning: review new stories
   for security implications. Design review: include a "security considerations" section in every
   design document. Definition of done: include "threat model reviewed" and "security
   requirements addressed" alongside "tests pass" and "code reviewed." Retrospective: review
   security findings from the sprint and adjust processes. These are lightweight additions to
   existing ceremonies, not new meetings.

4. **Create and maintain a security design review checklist.** The checklist should cover:
   authentication (how does the feature verify user identity?), authorization (who can perform
   which actions on which resources?), input validation (what inputs does the feature accept and
   how are they validated?), data protection (is sensitive data encrypted at rest and in
   transit?), logging (what security-relevant events does this feature produce?), error handling
   (do error messages leak internal details?), and dependency risk (what new dependencies does
   this feature introduce?). The checklist is a starting point, not a substitute for thinking.

5. **Use abuse cases alongside use cases.** For every use case ("User uploads a profile photo"),
   write the corresponding abuse case ("Attacker uploads a PHP webshell as a profile photo,"
   "Attacker uploads a 10GB file to exhaust storage," "Attacker uploads an image with EXIF GPS
   data harvesting"). Abuse cases force the team to think adversarially during design, not after
   deployment. They also produce concrete test cases for the QA team.

6. **Establish architecture-level security patterns as defaults.** Reduce the design-phase
   security burden by establishing organizational defaults: all inter-service communication uses
   mTLS, all data stores encrypt at rest, all APIs require authentication, all user input is
   validated against a schema, all sensitive operations produce audit events. When these are
   defaults, the design review focuses on feature-specific risks rather than relitigating
   baseline security decisions.

7. **Track security design decisions as architectural decision records (ADRs).** When a design
   review produces a security-relevant decision (using JWT instead of session cookies, choosing
   row-level security over application-level filtering, accepting a specific risk with
   mitigation), record it as an ADR. This creates a searchable history of why security decisions
   were made, prevents relitigating resolved decisions, and provides context for future threat
   model updates.

## Details

- **The cost curve of defect remediation**: IBM Systems Sciences Institute and NIST data show
  exponential cost increases as defects move through the SDLC. Design phase: 1x (change the
  document). Implementation phase: 6.5x (rewrite code, update tests). Testing phase: 15x
  (fix code, retest, delay release). Production phase: 100x (emergency patch, incident response,
  customer notification, regulatory reporting, reputation damage). The Ponemon Institute's Cost
  of a Data Breach Report (2023) puts the average cost of a data breach at $4.45 million, with
  breaches caused by security system complexity and cloud migration failures (both design-phase
  issues) costing significantly more.

- **Security requirements elicitation techniques**: OWASP Application Security Verification
  Standard (ASVS) provides a comprehensive checklist of security requirements organized by
  level (L1: opportunistic, L2: standard, L3: advanced). Use ASVS as a requirements source
  during design. Microsoft's Security Development Lifecycle (SDL) provides security requirements
  templates. NIST SP 800-53 provides security control families for federal systems. Map
  compliance requirements (SOC2, PCI-DSS, HIPAA) to specific security requirements early.

- **Lightweight threat modeling for agile teams**: The full STRIDE-per-element analysis is too
  heavyweight for every sprint. Use rapid threat modeling: 15-minute session during design
  review, focused on the specific feature being built. Draw the data flow diagram for the new
  feature on a whiteboard, identify trust boundaries, and brainstorm threats at each boundary
  crossing. Document findings as backlog items. This scales to agile velocity.

- **Security design review triggers**: Not every code change needs a security review. Define
  triggers: new authentication or authorization logic, new data stores for sensitive data, new
  external integrations or API endpoints, changes to encryption or key management, new user
  roles or permission models, infrastructure changes (new services, network changes). Changes
  that do not cross a trust boundary can proceed without security design review.

## Anti-Patterns

1. **Security review as a gatekeeping bottleneck.** When the security team must approve every
   design before development can start, security becomes a scheduling constraint that teams work
   around rather than with. Instead, embed security knowledge in development teams (security
   champions), provide self-service design review checklists, and reserve the security team's
   direct involvement for high-risk features that cross trust boundaries.

2. **Treating threat modeling as a document rather than a design influence.** A threat model
   produced to satisfy a process requirement and then filed away provides no security value. The
   purpose of threat modeling is to change the design. If the threat model does not result in
   at least one design modification, backlog item, or accepted-risk decision, it was either done
   too late or not taken seriously.

3. **The "security sprint" anti-pattern.** Batching all security work into a dedicated sprint
   (usually before a release) means security issues accumulate for weeks, are rushed through in a
   compressed timeline, and the fixes are inadequately tested. Security is a continuous concern,
   not a batch process. Integrate security requirements into every sprint, address findings as
   they are discovered, and include security criteria in the definition of done for every story.

4. **Relying solely on automated scanning without design-phase analysis.** SAST and DAST tools
   find implementation bugs (SQL injection, XSS, buffer overflows) but cannot find architectural
   flaws (missing authorization checks, improper trust boundaries, insecure data flows, lack of
   rate limiting). A design that routes all traffic through a single unauthenticated API gateway
   is an architectural vulnerability that no scanner will detect. Design-phase analysis and
   automated scanning are complementary, not substitutes.

5. **Security requirements as non-functional requirements.** Labeling security as "non-functional"
   marginalizes it. Security requirements are functional constraints: "the API must reject
   requests without a valid authentication token" is as functional as "the API must return user
   data in JSON format." Treat security requirements with the same priority, tracking, and
   testing discipline as any other requirement.

6. **One-time threat model never updated.** A threat model created during initial design and
   never revisited becomes stale as the system evolves. New features, new integrations, and new
   threat intelligence change the risk landscape. Review and update threat models when
   significant changes are made to the system, or at minimum quarterly for high-risk systems.