14.4 Secure Software Development Lifecycle (SSDLC) & DevSecOps
Key Takeaways
- Integrating security quality gates across every phase of the SSDLC ('Shift Left') reduces defect remediation costs by up to 100x compared to fixing security vulnerabilities in production.
- Threat modeling during the architectural design phase uses structured frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to systematically identify and mitigate structural flaws before code is written.
- Comprehensive AppSec programs combine complementary testing methods: SAST (white-box source code), DAST (black-box runtime), IAST (hybrid agent-based), SCA (open-source third-party dependencies/SBOM), and manual Penetration Testing.
- Software Composition Analysis (SCA) and Software Bill of Materials (SBOM) tracking are critical supply chain controls that mitigate third-party open-source risks such as Log4j and malicious dependency injection.
- DevSecOps operationalizes security as code within CI/CD automated pipelines, using Policy as Code guardrails to enforce automated quality gates without impeding software release velocity.
14.4 Secure Software Development Lifecycle (SSDLC) & DevSecOps
In modern digital enterprises, software is the engine of commercial execution. However, rapidly developed, insecure software represents one of the largest attack surfaces and operational risk vectors. Traditional software development approaches treated security as an isolated, post-development checkpoint—often conducting a hurried penetration test days before a scheduled production release. This legacy approach created massive technical and security debt, introduced critical vulnerabilities into production, and resulted in catastrophic release delays.
According to ISACA's CRISC Body of Knowledge, COBIT 2019, and ISO/IEC 27034 (Application Security), managing application risk requires embedding security into every phase of the development process. By "Shifting Left" and adopting DevSecOps principles, organizations integrate automated security quality gates, architectural Threat Modeling, comprehensive testing methodologies (SAST, DAST, IAST, SCA), and Software Supply Chain Governance directly into automated Continuous Integration and Continuous Delivery (CI/CD) pipelines.
+-----------------------------------------------------------------------------+
| THE SECURE SDLC & DEVSECOPS PIPELINE |
| |
| [REQUIREMENTS] [DESIGN] [DEVELOPMENT] [TESTING] [RELEASE] |
| - Security reqs - Threat model - Secure coding - SAST/DAST - IaC scan |
| - Compliance - STRIDE/DREAD - IDE linting - IAST/SCA - Signed |
| baselines - Architecture - Peer review - Pen testing binaries |
| ----------------------------------------------------------------------- |
| |<--- SHIFT LEFT: DEFECT REMEDIATION COST IS 1x TO 5x --->| | COST: |
| | 30x-100x!|
| v |
| +---------------------------------------------------------------------+ |
| | AUTOMATED DEVSECOPS CI/CD GATES | |
| | - Pre-commit: Secret Scanning, Linting | |
| | - Build Phase: SAST, Software Composition Analysis (SCA), SBOM | |
| | - Test Phase: DAST, IAST, Container Vulnerability Scanners | |
| | - Deploy Phase: Policy as Code (OPA), Signed Artifact Provenance | |
| +---------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------+
1. The SSDLC Framework & The Economics of "Shift Left"
The Secure Software Development Lifecycle (SSDLC) extends traditional SDLC models (Agile, Scrum, Waterfall) by incorporating mandatory security activities and verification milestones into each development stage.
+-----------------------------------------------------------------------------+
| THE RELATIVE COST OF FIXING SECURITY DEFECTS |
| |
| Phase Detected Relative Cost to Remediate (Boehm Curve) |
| ----------------------------- ---------------------------------------- |
| 1. Requirements Engineering $ 1x (Baseline: Minor text edit) |
| 2. Architectural Design $ 5x (Update diagram / security model) |
| 3. Development / Coding $ 10x (Refactor local function code) |
| 4. Integration & QA Testing $ 30x (Re-test and rebuild pipeline) |
| 5. Post-Release Production $ 100x+ (Emergency patch, incident |
| response, breach notification, |
| regulatory fines, litigation) |
+-----------------------------------------------------------------------------+
SSDLC Phase Breakdown & Security Milestones:
| SSDLC Phase | Security Focus & Governance Gate | Key Artifacts & Activities |
|---|---|---|
| 1. Requirements | Define regulatory, compliance, and security objectives | Data classification mapping, privacy requirements (GDPR/HIPAA), regulatory compliance checklists (PCI DSS), security user stories (Abuse/Misuse Cases). |
| 2. Design & Architecture | Identify architectural flaws before writing code | Architectural risk assessment, attack surface minimization, Threat Modeling (STRIDE/PASTA), secure interface design. |
| 3. Development / Coding | Prevent vulnerability introduction at the source | Secure coding standards (OWASP, CERT), IDE security plugins, secret scanning pre-commit hooks, peer code reviews. |
| 4. Testing & Verification | Validate security posture through automated & manual tests | SAST, DAST, IAST, SCA (Dependency scanning), container scanning, fuzz testing, manual penetration testing. |
| 5. Deployment / Release | Ensure operational environment and artifacts are secure | Infrastructure as Code (IaC) security scanning, container image signing (Cosign), Software Bill of Materials (SBOM) generation, pre-flight configuration audits. |
| 6. Operations & Maintenance | Continuous monitoring, vulnerability response, and patching | Vulnerability management SLAs, automated patch deployment, runtime application monitoring (RASP), incident response playbooks, responsible decommissioning. |
2. Threat Modeling in the Design Phase
Threat Modeling is a structured engineering process conducted during the software design phase to identify potential threats, architectural attack vectors, and missing safeguards before developers write code.
+-----------------------------------------------------------------------------+
| THE STRIDE THREAT MODELING FRAMEWORK |
| |
| Threat Category Security Property Violated Remediation Control |
| ---------------------- -------------------------- ------------------ |
| [S] Spoofing Identity Authenticity MFA, PKI, mTLS |
| [T] Tampering with Data Integrity Digital signatures, |
| hashes, HMAC |
| [R] Repudiation Non-Repudiation Centralized SIEM, |
| immutable logs, WORM|
| [I] Information Discl. Confidentiality AES-256 encryption, |
| TLS 1.3, tokeniz. |
| [D] Denial of Service Availability Rate limiting, DDoS |
| scrubbers, CDN/HA |
| [E] Elevation of Priv. Authorization Least privilege, |
| RBAC, ABAC, PAM |
+-----------------------------------------------------------------------------+
Supporting Threat Scoring Frameworks:
- DREAD Methodology: Quantitative risk scoring framework that rates threats from 1 to 10 across five dimensions: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.
- PASTA (Process for Attack Simulation and Threat Analysis): A risk-centric, 7-step threat modeling methodology that aligns technical application vulnerabilities with business impact and threat actor motivations.
3. Application Security Testing Methodologies (AppSec)
A mature Application Security program deploys a combination of automated and manual testing methodologies across the development lifecycle.
+-----------------------------------------------------------------------------+
| APPLICATION SECURITY TESTING (APPSEC) MATRIX |
| |
| Method Perspective SDLC Phase Strengths Weaknesses |
| ------ ----------- ------------ ----------------- -------------- |
| SAST White-Box Early Build Scans 100% source High false-pos; |
| (Source Code) (Pre-compile) code; pinpoints no runtime |
| line number. context. |
| |
| DAST Black-Box Testing / QA Finds runtime & Late in SDLC; |
| (Running App) (Post-deploy) config flaws; no cannot pinpoint |
| source code needed. source line. |
| |
| IAST Hybrid Testing / QA Agent inside app; Requires active |
| (Inside App) (Functional) real-time code functional test |
| context; low false+ suite to run. |
| |
| SCA Third-Party Build / CI Detects known CVEs Only scans open-|
| Dependencies (Continuous) & license risks in source/vendor |
| open-source libs. libraries. |
+-----------------------------------------------------------------------------+
In-Depth Tool Capabilities:
- SAST (Static Application Security Testing): Analyzes raw source code, byte code, or binaries without executing the program. It detects syntax flaws, insecure cryptographic functions, hardcoded API secrets, and buffer overflow patterns. Because it lacks runtime context, SAST often generates false positives that require developer triage.
- DAST (Dynamic Application Security Testing): Operates from the outside as an unauthenticated or authenticated attacker, executing HTTP requests against running web applications and APIs. It identifies authentication bypasses, cross-site scripting (XSS), SQL injection, and web server misconfigurations.
- IAST (Interactive Application Security Testing): Combines the advantages of SAST and DAST by embedding an agent sensor directly inside the application runtime engine (JVM, .NET CLR, Node.js). As QA testers execute functional tests, the IAST agent inspects memory, database queries, and code execution paths, providing pinpoint accuracy with extremely low false-positive rates.
- SCA (Software Composition Analysis): Scans the application's software bill of materials (dependencies, frameworks, open-source packages) to identify known Common Vulnerabilities and Exposures (CVEs) and open-source licensing risks (e.g., GPL contamination).
4. Software Supply Chain Security & SBOM
Modern software applications are rarely built from scratch; between 70% and 90% of an enterprise application codebase consists of third-party open-source libraries and components. Consequently, attackers increasingly target the software supply chain rather than attempting to breach hardened perimeter defenses.
+-----------------------------------------------------------------------------+
| SOFTWARE SUPPLY CHAIN THREATS & DEFENSES |
| |
| Supply Chain Attack Vector Example Threat Mandatory Defensive |
| Governance Control |
| ------------------------------ ------------------ ------------------- |
| Compromised Open-Source Library Log4Shell, event- Automated SCA scans |
| stream, colors.js in CI/CD pipelines |
| |
| Build Pipeline Tampering SolarWinds Orion, Cryptographic build |
| Codecov breach provenance (SLSA) |
| |
| Dependency Typosquatting / Malicious npm/PyPI Private artifact |
| Dependency Confusion package injection repository proxy |
+-----------------------------------------------------------------------------+
The Role of the Software Bill of Materials (SBOM):
A Software Bill of Materials (SBOM) is an immutable, machine-readable inventory of all third-party components, libraries, dependencies, and hierarchical sub-dependencies contained within a software artifact. Formatted in standardized schemas such as CycloneDX or SPDX, SBOMs allow organizations to query their entire application portfolio within minutes of a zero-day vulnerability announcement (e.g., Log4j) to identify every impacted production service.
5. The OWASP Top 10 Application Security Vulnerabilities
The Open Web Application Security Project (OWASP) Top 10 represents the authoritative global consensus on the most critical web application security risks.
+-----------------------------------------------------------------------------+
| THE OWASP TOP 10 RISK LANDSCAPE |
| |
| Rank Vulnerability Category Core Risk & Preventative Control |
| ---- ------------------------------ --------------------------------- |
| A01 Broken Access Control Users act outside intended bounds; |
| enforce server-side RBAC/ABAC. |
| A02 Cryptographic Failures Exposed data; enforce TLS 1.3 & |
| AES-256, deprecate MD5/SHA-1. |
| A03 Injection (SQLi, XSS, Command) Untrusted data executed as code; |
| use parameterized queries / ORMs. |
| A04 Insecure Design Missing security architecture; |
| mandate threat modeling in Design. |
| A05 Security Misconfiguration Default passwords, open buckets; |
| automate IaC CIS benchmark scans. |
| A06 Vulnerable & Outdated Comps. Known CVEs in libs; enforce SCA and |
| automated SBOM dependency patching. |
| A07 Identification & Auth Failures Weak passwords, brute force; |
| enforce phishing-resistant MFA. |
| A08 Software & Data Integrity Fail. Unverified updates; enforce binary |
| code signing & CI/CD verification. |
| A09 Security Logging & Monitor Fail Delayed breach detection; enforce |
| centralized SIEM logging & alerts. |
| A10 Server-Side Request Forgery Server coaxed to query internal |
| (SSRF) resources; validate destination IPs.|
+-----------------------------------------------------------------------------+
6. DevSecOps & Automated CI/CD Pipeline Governance
DevSecOps integrates security seamlessly into the automated DevOps delivery pipeline, transforming security from a manual bottleneck into automated Policy as Code.
+-----------------------------------------------------------------------------+
| AUTOMATED DEVSECOPS PIPELINE ARCHITECTURE |
| |
| [DEVELOPER IDE] |
| - IDE security linter (SonarLint) |
| - Pre-commit hook: Git-secrets blocks hardcoded credentials |
| | |
| v GIT PUSH / PULL REQUEST |
| [CONTINUOUS INTEGRATION (CI) BUILD ENGINE] |
| - Step 1: Compilation & Dependency Resolution |
| - Step 2: SAST Code Scan (SonarQube / Checkmarx) |
| - Step 3: Software Composition Analysis (Snyk / Dependency-Track) |
| - Step 4: Container Vulnerability Scan (Trivy / Clair) |
| | |
| v SECURITY QUALITY GATE: Any Critical / High CVE? |
| +---[ YES ] ---> BUILD BROKEN! Deployment blocked. Jira logged. |
| +---[ NO ] ---> BUILD PASSED! Artifact signed with Cosign. |
| |
| v CONTINUOUS DEPLOYMENT (CD) TO STAGING / PROD |
| [STAGING RUNTIME ENGINE] |
| - Automated DAST scan (OWASP ZAP) against staging API |
| - Interactive IAST agent validates runtime SQL calls |
| - Infrastructure as Code (IaC) Terraform scan via Open Policy Agent (OPA) |
+-----------------------------------------------------------------------------+
Enforcing Policy as Code & Breaking the Build:
- Automated Quality Gates: The pipeline must enforce non-negotiable security rules. If a code commit introduces a High or Critical CVE (CVSS $\ge 7.0$) without an approved business exception, the build is automatically halted ("Break the Build"), and the commit is rejected back to the developer.
- Policy as Code (e.g., Open Policy Agent - OPA): Security and compliance guardrails (such as "No S3 bucket can be public" or "No container can run as root") are defined in declarative code and evaluated automatically during pull requests, preventing human compliance oversight from slowing down releases.
7. CRISC Exam Traps & Real-World Scenarios
Exam Trap 1: Relying Exclusively on DAST and Late Penetration Testing
- The Trap: An organization relies solely on an annual penetration test right before production deployment as its primary application security control.
- The Reality: Late-stage testing violates the Shift Left principle. Fixing architectural or fundamental design flaws right before release is extremely costly (up to 100x baseline) and frequently causes missed go-live dates or pressure to bypass security controls.
Exam Trap 2: Believing SCA Scans Only Custom-Written Code
- The Trap: Confusing SAST with SCA. A question asks how to identify vulnerable third-party open-source libraries in an application portfolio, and the candidate selects SAST.
- The Reality: SAST analyzes proprietary custom source code. Software Composition Analysis (SCA) specifically scans third-party open-source packages and dependencies against public vulnerability databases (CVEs/NVD).
Exam Trap 3: Assuming DevSecOps Requires Manual Review of Every Pull Request
- The Trap: Believing that implementing DevSecOps means embedding a human security analyst to manually inspect every line of code committed to Git.
- The Reality: DevSecOps achieves scalability and speed through automation, automated testing suites, and Policy as Code. Security teams define the policies and guardrails, while automated CI/CD pipelines enforce compliance.
A software enterprise is developing a cloud-native microservices application to process sensitive customer healthcare records. During which phase of the Secure Software Development Lifecycle (SSDLC) should the engineering team execute STRIDE Threat Modeling to identify architectural trust boundary violations and minimize defect remediation costs?
An Application Security team is evaluating automated testing methodologies for its continuous integration pipeline. The team requires a tool that analyzes raw proprietary source code without executing the application, identifying syntax vulnerabilities, hardcoded secrets, and buffer overflow patterns at the exact line of code. Which security testing methodology fulfills these specific requirements?
Following a major zero-day disclosure in a widely used open-source logging library, an enterprise risk committee requests an immediate report detailing all internal applications and third-party software products containing the vulnerable package. Which software governance capability and artifact enable the organization to query and identify affected systems across the enterprise portfolio most rapidly?
An enterprise DevSecOps engineering team is configuring security guardrails within its automated CI/CD deployment pipeline. To prevent high-risk vulnerabilities from reaching production without creating human review bottlenecks, which mechanism should the team implement to automatically halt deployment when a build violates security policy?