A lifecycle reference aligned with v2.1 §10. For the developer-first entry point (why design reviews are theatre and how to make them bite) start at the SSDLC Hub. For roles and the cluster-indexed secure coding checklist (§10.1 & §10.3), see Programmer vs Coder. For CWE triage logic (§10.4), see the SonarQube case study.
The TLCTC Approach to SSDLC
TLCTC does not replace language-specific secure coding standards (OWASP, CERT, and peers). It provides the stable threat vocabulary that keeps cause and outcome separated, makes coverage across generic vulnerabilities explicit, and enables consistent reporting of findings and residual exposure over time.
Every phase answers the same question:
"Which generic vulnerabilities are we addressing now, and how do we know?"
The perspective is always MY software and the threats to MY software (see white paper §2 axioms).
- One step = one cluster (Axiom VI). Don't label a single action with two clusters — decompose into a sequence
#X → #Y. #2vs#3is where the flaw executes, not two different flaw types. Same CWE (e.g. CWE-787) maps to#2in a server parser,#3in a PDF reader.- "RCE" is a sequence, not a cluster. Decompose to
#2 → #7(server exploit → FEC execution) or#3 → #7(client exploit → FEC execution).#7 Malwareis the cluster for Foreign Executable Content (FEC) — designed execution of untrusted code, distinct from exploit code that runs via a flaw. #10 Supply Chainmarks trust-boundary crossing, positioned inside sequences. Use the domain-boundary operator||[context][@From→@To]||at the crossing step (white paper §5).
Phase mapping at a glance
The v2.1 canonical phase-to-deliverable mapping (§10.2.1). Every phase below expands this row into detail.
| SSDLC phase | Key TLCTC deliverables | Primary cluster focus |
|---|---|---|
| Requirements & Planning | threat model in clusters; misuse cases for #1; initial attack-path hypotheses | all (coverage) + #1 |
| Design & Architecture | trust boundaries; secure patterns; approved primitives; path-interruption plan | #1,#4,#5,#6,#7,#10 (+ #2/#3 patterns) |
| Implementation | cluster-tagged coding checklists; reviews tied to patterns; cluster-derived tests | #2,#3,#4,#7,#10 + #1 enforcement |
| Testing & Verification | cluster-driven test plan; SAST/DAST/SCA/fuzzing mapped to clusters | all (verification), emphasis on #2/#3 and #10 |
| Deployment | secure baseline (#1), secrets (#4), transport (#5), rate limits (#6), artifact integrity (#10→#7) | #1,#4,#5,#6,#10 |
| Maintenance | patch & dependency metrics by cluster; incidents stored as attack paths | all (monitor) + #2/#3/#10 |
Phase 1: Requirements & Planning
Produce a first-cut threat model expressed as cluster coverage, not a list of CVEs. Answer the three SSDLC coverage questions (§10.1.2): which clusters are in scope, which are out of scope with what assumptions, and what controls/tests/operational hooks address each generic vulnerability.
- Cluster coverage decision: for each of
#1–#10, in scope or out, with a one-line rationale. - Misuse cases for
#1: how could legitimate features be weaponized within their intended parameters? - Initial attack-path hypotheses: two or three plausible sequences (e.g.
#9 → #4 → #1 → #7) the design must interrupt. - Trust boundaries and third-party dependencies: where does
#10appear, and across which domain?
Phase 2: Design & Architecture — where all 10 clusters demand a decision
Every cluster requires strategic choices at design time — even those that manifest as implementation bugs later. The question is not "which clusters apply?" but "what architectural decision does each cluster demand?"
#1 Abuse of Functions
- Generic Vulnerability: Software scope and functional complexity
- Design Decisions:
- What is the minimum functionality required? Every feature expands attack surface.
- How could legitimate features be weaponized within their intended parameters?
- What business logic constraints must be enforced?
- What approval workflows prevent abuse of sensitive functions?
#2 Exploiting Server
- Generic Vulnerability: Server-side code implementation flaws
- Design Decisions:
- What programming language/framework minimizes server-side implementation risk?
- Which components are security-critical and require senior developers?
- What secure coding standards will be mandated?
- What SAST tooling is required in the pipeline?
The design phase determines the conditions for secure implementation. Complex cryptographic code or authentication modules may require senior developers; a straightforward CRUD API might not.
#3 Exploiting Client
- Generic Vulnerability: Client-side code implementation flaws
- Design Decisions:
- What client technologies minimize implementation risk (framework choice)?
- How complex is the client-side logic? What skill level is required?
- What CSP and security headers will be enforced?
- Will we use a framework with built-in XSS protection, or roll our own?
#4 Identity Theft
- Generic Vulnerability: Weak identity management and credential protection
- Design Decisions:
- What authentication architecture? (OAuth, SAML, custom, federated?)
- Where will credentials be stored, transmitted, and validated?
- What's the session management strategy?
- Is MFA required? For which user classes?
- What's the credential lifecycle (issuance, rotation, revocation)?
#5 Man in the Middle
- Generic Vulnerability: Insufficient control over communication paths
- Design Decisions:
- What's the minimum TLS version and cipher suite policy?
- Is mTLS required for service-to-service communication?
- What's the certificate management strategy?
- Do we need end-to-end encryption, or is transport encryption sufficient?
#6 Flooding Attack
- Generic Vulnerability: Finite system capacity
- Design Decisions:
- What are the bottleneck resources (CPU, memory, connections, storage)?
- What rate limiting strategy applies to each endpoint?
- How will the system degrade gracefully under extreme load?
- Do we need DDoS mitigation services?
#7 Malware
- Generic Vulnerability: Environment's capability to execute foreign code
- Design Decisions:
- How do we secure the build and deployment pipeline?
- What code signing strategy ensures artifact integrity?
- What file upload/processing capabilities exist, and how do we sandbox them?
- Will we use application allowlisting in production?
#8 Physical Attack
- Generic Vulnerability: Physical accessibility of hardware and facilities
- Design Decisions:
- Do I trust my computing provider's physical security? This is a fundamental boundary decision.
- What's my exposure to collateral damage?
- Do I need multi-region or multi-provider redundancy?
- If an attacker gains physical access to hardware running my software, what's the blast radius?
#8 is a "bridge cluster" that crosses from the physical security domain into the cyber domain. Your design must account for trust boundaries you don't directly control.
#9 Social Engineering
- Generic Vulnerability: Human psychological factors
- Design Decisions:
- How do we design UI/UX that makes secure choices the default and easy path?
- What process controls prevent single points of human failure?
- What confirmation dialogs or cooling-off periods protect against manipulation?
#9 is a "bridge cluster" that bypasses technical controls entirely by exploiting authorized humans. Design must assume technical controls can be circumvented via the human element.
#10 Supply Chain Attack
- Generic Vulnerability: Trust in third-party components and processes
- Design Decisions:
- What's the vetting process for third-party dependencies?
- How will we track dependencies (SBOM) and monitor for vulnerabilities?
- Do we trust our CI/CD provider? Our cloud provider?
- Do we need vendor security assessments or SOC 2 reports?
Design-phase summary: strategic questions by cluster
| Cluster | Core Design Question |
|---|---|
| #1 Abuse of Functions | What functionality am I exposing, and how could it be misused? |
| #2 Exploiting Server | What language/framework/team skill level minimizes server-side bugs? |
| #3 Exploiting Client | What client architecture and tooling prevents implementation flaws? |
| #4 Identity Theft | What authentication architecture protects the credential lifecycle? |
| #5 Man in the Middle | What communication security architecture protects data in transit? |
| #6 Flooding Attack | What capacity planning and rate limiting prevents resource exhaustion? |
| #7 Malware | What pipeline security prevents malicious code introduction? |
| #8 Physical Attack | What physical trust boundaries am I accepting, and what's the collateral risk? |
| #9 Social Engineering | What UI/UX and process design protects against human manipulation? |
| #10 Supply Chain | What third-party trust am I accepting, and how do I manage it? |
Phase 3: Implementation
With design decisions made, coders execute within the defined boundaries. The detailed cluster-indexed checklist lives in the Programmer vs Coder page (§10.3). Headline focus:
Primary Implementation Focus
#2Exploiting Server — secure server-side code: parameterized queries, input validation at trust boundaries, safe memory & resource handling, output encoding, safe deserialization.#3Exploiting Client — secure client-side code: context-aware output encoding, safe DOM APIs, strict CSP, never trust external data.#7Malware — FEC control: no unsafe dynamic execution (eval, command injection, unsafe deserialization), safe file handling, allow-listing / sandboxing where justified.#10Supply Chain — intake & build trust: approved dependencies only; verify integrity; treat data crossing third-party components as compromised.
Implementation of Design Decisions
The remaining clusters land as implementation of controls chosen in Phase 2:
#1: enforce authorization server-side; validate workflow state transitions; no debug bypasses.#4: implement auth flows exactly per spec (OAuth/OIDC state/PKCE); secure secret storage; cookie flags.#5: use standard TLS libraries; verify certs (host/chain/expiry); no disabled verification.#6: implement rate limits, timeouts, efficient algorithms; close/release resources reliably.#8: secure storage, encryption-at-rest, tamper-evident paths where in scope.#9: consistent trust cues, friction for irreversible actions, safe defaults.
Tag every review note, commit, and finding with the cluster it addresses. Reporting then reads "3 findings enabling #2, 1 enabling #4" instead of disconnected CWE lists (§10.3, §10.4.5).
Phase 4: Testing & Verification
TLCTC clusters drive the test plan. Each tool or technique below is primarily verifying one generic vulnerability.
| Cluster | Testing Approach |
|---|---|
| #1 | Business logic testing, abuse case scenarios, privilege escalation tests |
| #2 | SAST, DAST, manual code review, fuzzing of server endpoints |
| #3 | Client-side SAST, XSS testing, CSP validation |
| #4 | Authentication bypass testing, session management review |
| #5 | TLS configuration testing, certificate validation |
| #6 | Load testing, rate limit verification |
| #7 | Pipeline security audit, code signing verification |
| #8 | Physical security assessment of deployment environment |
| #9 | Social engineering simulations, UI/UX security review |
| #10 | SCA scanning, SBOM validation, dependency audit |
Attack-Path Design Reviews (v2.1 §10.2.2)
Complex compromises are sequences, not isolated bugs. During design reviews, teams walk the most plausible paths for the product and verify a named interruption exists at each step. A step without an interruption is the review's output — that is the finding.
This is a design-time tool, not a red-team post-mortem artifact. Red teams later verify the interruptions hold in practice — but the paths themselves belong to architecture.
#9 → #4 → #1 → #7. Design passes only if each step has a named interruption.
For each step in the path, record the control that stops it. Empty cells are the review's output.
#9 phishing-resistant MFA ✔#4 device-bound tokens ✔#1 step-up on admin APIs ✘ gap#7 EDR allow-list ✔
When a path crosses a responsibility sphere (vendor → org, dev → prod), record the crossing with ||[context][@From→@To]|| per white paper §5.
More patterns: attack-path examples. Common shapes: #9 → #3 → #7 (phishing → client exploit → execution), #10 ||[dev][@Vendor→@Org]|| → #7 (dependency compromise → execution on install), #1 → #6 (abuse-based amplification → exhaustion).
Phase 5: Deployment
Controls move from design into the running environment. Each action below closes one generic vulnerability.
#1: secure configuration baseline — no debug toggles, safe defaults, least privilege service accounts.#4: secrets management — no secrets in images/configs; rotation; scoped tokens.#5: transport configuration — TLS baseline enforced at ingress, MTLS where defined.#6: rate limiting at the edge; quotas per tenant/endpoint.#10 → #7: artifact integrity — signed builds, image digests pinned, provenance verified before run.
Phase 6: Maintenance
Monitoring by cluster
#1: anomaly detection for unusual API patterns, workflow violations.#4: failed logins, impossible travel, credential-stuffing detection.#6: traffic-volume alerts, resource-exhaustion watchdogs.#7: EDR, file-integrity monitoring, behavioral analysis.#10: dependency/vulnerability feeds tagged with cluster; SBOM drift alerts.
Metrics that actually report risk
Tag every finding, patch, and incident with its cluster. Stable reporting then reads "top open findings by cluster" and "mean-time-to-interrupt for #2 → #7 paths" rather than CWE totals that break comparability. This prevents drift toward outcome-based labels ("RCE", "breach") per §10.3.
Attack Velocity (Δt)
The time between threat detection and response determines real exposure. Design-phase decisions about monitoring, automation, and incident response capabilities directly drive detection coverage per cluster.
Phase 7: Decommissioning
Not formally part of §10 but tightly coupled to the same clusters:
#4Identity Theft: revoke all credentials — API keys, service accounts, certificates, federated trust relationships.#8Physical Attack: secure wipe, cryptographic erasure, or physical destruction of storage.#10Supply Chain: notify downstream consumers if your artifact is someone else's dependency. Unmaintained code that others still run is a#10exposure for them.
Conclusion: Design decides everything
All 10 clusters demand design-phase decisions. Even implementation-focused clusters (#2, #3, #7) require strategic choices about language, team, tooling, and standards before a single line of code is written. The lifecycle turns "secure by design" from a slogan into a discipline when every phase produces cluster-tagged deliverables and attack paths with named interruptions.
Where next: SSDLC Hub · Roles & cluster checklist · CWE triage case study · Coming from STRIDE · White paper v2.1 §10.