Domain 8 β€Ί Domain 8 Β· Lesson 1 of 5

Secure Software Development Lifecycle

VΓ²ng đời PhΓ‘t triển PhαΊ§n mềm An toΓ n

Security Activities at Each SDLC Phase

Security is not a phase β€” it is a continuous concern across every stage of the SDLC. The earlier a vulnerability is discovered, the cheaper it is to fix. This is the foundation of shift-left security.

Phase Security Activities Cost to Fix if Found Here
Requirements Security requirements, privacy requirements, compliance requirements (BSP/SBV/PCI-DSS), threat modeling kick-off Cheapest ($1)
Design Architecture risk analysis, secure design principles, data flow diagrams, attack surface analysis, threat modeling Low ($10)
Implementation Secure coding standards, peer code review, SAST in IDE (real-time), avoid dangerous functions Medium ($100)
Testing DAST, IAST, SCA, fuzz testing, security test cases, misuse case testing High ($1,000)
Deployment SAST gate in CI/CD, secrets scanning, container image scanning, DAST against staging Very High ($10,000)
Maintenance Patch management, SCA for new CVEs, periodic penetration testing Highest ($100,000+)

The 1-10-100 Rule: Fixing a defect in Requirements costs $1 (relative). In Design: $10. In Testing: $100 (CISSP exam often uses this simplified ratio). In production: $10,000+. Shift-left to minimize cost and risk.

Development Methodologies & Security Implications

Methodology How Security Fits Security Risk
Waterfall Sequential phases; security review typically at end of cycle HIGH β€” late discovery
Agile / Scrum Security user stories in backlog; security checklist in Definition of Done; security sprints MEDIUM β€” needs discipline
DevOps Continuous delivery; security must be automated in pipeline (β†’ DevSecOps) MEDIUM β€” speed pressure
Spiral Risk-driven; iterates through planning β†’ risk analysis β†’ engineering β†’ evaluation; security naturally embedded LOW β€” risk analysis built-in

Agile Security Checklist (Definition of Done)

  • β–ΈSecurity acceptance criteria met
  • β–ΈSAST scan passed (no new High/Critical)
  • β–ΈNo new CVEs in added dependencies
  • β–ΈPeer security review for security-sensitive code

Key SDLC Security Documents

  • β–ΈSecurity Requirements Specification
  • β–ΈThreat Model (STRIDE / PASTA)
  • β–ΈSecurity Architecture Document
  • β–ΈCode Review Report + VAPT Report

Misuse Cases & Software Acquisition Security

Misuse Cases

A misuse case defines how a system should NOT be used β€” documenting attacker scenarios. For each use case, developers should define the corresponding misuse case and ensure test cases cover it.

Use Case vs Misuse Case

Use Case: "Customer submits loan application"

Misuse Case: "Attacker submits loan application with another customer's ID to commit fraud"

Software Acquisition & Outsourcing

When buying software or outsourcing development, security cannot be assumed β€” it must be contractually defined.

  • β–ΈSecurity requirements in contract/SLA
  • β–ΈRight to audit third-party code
  • β–ΈSLA for critical security patches
  • β–ΈSBOM requirement for delivered software
  • β–ΈSource code escrow for critical systems

Key Terms

SDLC

Software Development Life Cycle β€” structured process for planning, creating, testing, and deploying software

Shift-Left

Move security testing and review to earlier phases β€” requirements and design β€” rather than testing phase

1-10-100 Rule

Relative cost to fix: $1 in requirements, $10 in design, $100 in testing, $10,000+ in production

Misuse Case

Documents how an attacker might abuse the system β€” inverse of a use case; drives security test cases

Spiral Model

Risk-driven iterative methodology: Planning β†’ Risk Analysis β†’ Engineering β†’ Evaluation; security naturally embedded

DAST / SAST / IAST

Dynamic / Static / Interactive Application Security Testing β€” different phases, complementary coverage

Exam Tips β€” Lesson 01
  1. 1. Shift-left = catch security issues EARLY (requirements/design) β€” 100Γ— cheaper than fixing in production. This is a core CISSP principle.
  2. 2. Waterfall security risk: security review only at the end = high cost if issues found late. CISSP often presents Waterfall as the "risky" choice for security.
  3. 3. Agile: add security acceptance criteria to user stories β€” "As a user, I want my data encrypted at rest" is a valid security requirement in a backlog.
  4. 4. Misuse cases: define how system should NOT be used, then derive security test cases from them. This is how QA tests security.
  5. 5. Software acquisition: security requirements must be in the CONTRACT β€” you cannot audit code you have no right to see.
Platform C/FinTech Company X Application

(1) Requirements phase: All new Platform C features require a "Security Impact" field in Jira β€” what data is collected/processed? What regulatory obligation applies (BSP, SBV, PCI-DSS)?

(2) Design phase: STRIDE threat model required for any new external integration (new partner APIs, telco integrations for Partner C, Partner E payment redirect).

(3) Implementation: Security checklist in PR template β€” parameterized queries? input validation? no secrets in code? encryption used?

(4) Testing: govulncheck + gosec run before every merge to main. Java Platform A: SpotBugs + Checkmarx SAST.

(5) Deployment: Trivy image scan + ArgoCD approval required before any production deploy.

(6) Maintenance: Dependabot weekly dependency scans; Partner A penetration test annually.

Action: Add security acceptance criteria to the next 3 Platform C sprints. Example: "Acceptance: loan data encrypted at rest (AES-256), loan_id not guessable from URL."

Practice Questions

Q1: Why does fixing a vulnerability in the requirements phase cost far less than in production?

A: In requirements, only the specification document changes. In production, the fix requires code change, testing, re-deployment, potentially notifying regulators, and possibly incident response β€” all multiplying the cost.
The 1-10-100 rule captures this: requirements ($1) β†’ design ($10) β†’ testing ($100) β†’ production ($10,000+). This is the core justification for shift-left security. CISSP exam may ask "why is shift-left preferred?" β€” answer is cost and risk reduction.

Q2: Which SDLC methodology carries the highest risk of late security discovery, and why?

A: Waterfall β€” because security review is typically performed only at the end of the sequential process. All phases must complete before testing begins, meaning vulnerabilities introduced in requirements or design are not found until very late.
CISSP positions Waterfall as risky for security because it is sequential and does not allow for iteration. Agile and Spiral are preferred for security because they incorporate security review in every cycle/sprint.

Q3: What is a misuse case, and how does it differ from a use case?

A: A use case describes legitimate intended usage ("Customer submits loan application"). A misuse case describes how an attacker would abuse the system ("Attacker submits loan application with another customer's ID"). Misuse cases drive security test cases.
Misuse cases are an important CISSP concept β€” they are the security equivalent of use cases and should be defined during the requirements/design phase. Each misuse case should have a corresponding security test case in the testing phase.

Q4: At which SDLC phase should the initial threat model be created?

A: Design phase β€” before any code is written. A threat model created in requirements/design costs $10 to act on. The same model created after production deployment costs $10,000+.
Threat modeling during design enables architects to change data flows, trust boundaries, and authentication approaches before code exists. CISSP exam tip: "when should threat modeling occur?" β†’ Design phase (sometimes also started at Requirements β€” both are acceptable answers, but Design is the primary CISSP answer).

Q5: When acquiring third-party software, what security element must be contractually defined?

A: Security requirements, SLA for critical security patches, right-to-audit provisions, and SBOM delivery. You cannot enforce what is not in the contract.
Software acquisition security is a CISSP Domain 8 topic. Key principle: security obligations must be in the contract. Vendor promises without contractual enforcement are not controls. This applies to eKYC Vendor (eKYC), eSign Vendor (eSign), AML Vendor (AML), and Card Processor (card issuing) at FinTech Company X.
← D8 Overview Lesson 02: Secure Coding β†’