# DevSecOps and Secure SDLC
DevSecOps is the practice of integrating security into every phase of the software development lifecycle (SDLC), from design through development, testing, deployment, and operations. It replaces the traditional model where security is a gate at the end of development (a QA team reviews the finished product before release) with a model where security is embedded throughout (security requirements are defined at design, security tests run automatically in the CI/CD pipeline, and vulnerabilities are remediated before code reaches production).
The Secure SDLC is the structured process that DevSecOps implements: a lifecycle where each phase includes security activities as standard practice, not as an afterthought. Security requirements are captured alongside functional requirements. Threat modeling occurs during design. Static and dynamic analysis runs during development and testing. Dependency scanning checks open-source components. Container scanning validates container images. Infrastructure-as-code scanning validates cloud configurations. Each security check is automated, fast, and integrated into the tools developers already use.
The need is driven by volume. Modern development teams deploy code daily or multiple times per day through CI/CD pipelines. A security team that manually reviews code before each deployment becomes a bottleneck that either slows development (blocking releases for security review) or gets bypassed (teams deploy without review to meet deadlines). DevSecOps resolves this by automating security checks so they execute at the speed of development, providing feedback to developers in minutes rather than weeks.
Requirements. Security requirements are defined alongside functional requirements. Regulatory mandates (HIPAA, PCI DSS, GDPR) translate into specific application security requirements: encrypt PII at rest and in transit, implement role-based access control, log all authentication events, validate all inputs. CDA's VSD-R03 (Application Security Assessment, 16 hours) identifies security requirements for each application based on data classification, regulatory scope, and threat exposure.
Design. Threat modeling identifies potential attack vectors before code is written. Threat modeling methodologies (STRIDE, PASTA, LINDDUN) systematically evaluate each application component for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege risks. The output is a prioritized list of threats that the design must address.
Threat modeling at the design phase is the highest-leverage security activity in the SDLC because it prevents entire categories of vulnerabilities. A design that separates user roles with enforced access control does not produce broken access control vulnerabilities. A design that parameterizes all database queries does not produce SQL injection vulnerabilities. Prevention at design is orders of magnitude cheaper than remediation after deployment.
Development. Developers write code with security-aware practices: input validation, parameterized queries, output encoding, secure authentication patterns, error handling that does not leak sensitive information, and dependency management that tracks and updates open-source components.
Static Application Security Testing (SAST) tools (SonarQube, Checkmarx, Veracode, Semgrep) analyze source code for security vulnerabilities without executing it. SAST runs in the IDE (providing immediate feedback to the developer) and in the CI pipeline (blocking merge requests that introduce vulnerabilities above a defined severity threshold). SAST catches code-level vulnerabilities: injection flaws, hardcoded credentials, insecure cryptographic implementations, and unsafe deserialization.
Software Composition Analysis (SCA) tools (Snyk, Mend, Dependabot, Black Duck) scan application dependencies for known vulnerabilities and license compliance issues. SCA is critical because modern applications contain 70% to 90% open-source code. A single vulnerable dependency (Log4j) can affect every application that includes it. SCA provides visibility into the supply chain risk embedded in every application.
Testing. Dynamic Application Security Testing (DAST) tools (OWASP ZAP, Burp Suite, HCL AppScan) test the running application from the outside, simulating attacker behavior: probing for injection vulnerabilities, testing authentication bypass, discovering exposed endpoints, and evaluating error handling. DAST catches vulnerabilities that SAST misses: runtime configuration issues, authentication logic flaws, and server-side vulnerabilities that depend on the application's deployed state.
Interactive Application Security Testing (IAST) combines SAST and DAST approaches by instrumenting the running application to observe code execution during testing. IAST provides more accurate results (fewer false positives) than SAST or DAST alone because it correlates source code analysis with runtime behavior.
API security testing validates the security of application programming interfaces: authentication enforcement, authorization checks, input validation, rate limiting, and sensitive data exposure. APIs are the primary interface for modern applications and a growing attack surface.
Deployment. Infrastructure-as-code (IaC) scanning (Checkov, tfsec, KICS) validates that cloud and infrastructure configurations meet security requirements before deployment. A Terraform template that creates a publicly accessible S3 bucket is flagged before the infrastructure is provisioned.
Container image scanning (Trivy, Snyk Container, Aqua) validates that container images do not contain known vulnerabilities, default credentials, or insecure configurations before they are deployed to production. Container scanning runs in the CI/CD pipeline and blocks deployment of images that fail the security policy.
Secret scanning (GitGuardian, TruffleHog, gitleaks) identifies credentials, API keys, certificates, and other secrets committed to source code repositories. Secrets in code are a common and high-severity finding: a committed AWS access key provides direct access to the cloud environment.
Operations. Runtime Application Self-Protection (RASP) monitors the application in production for active exploitation attempts. Web Application Firewalls (WAFs) filter malicious traffic before it reaches the application. Runtime container security monitors container behavior for anomalies. Bug bounty programs invite external researchers to identify vulnerabilities that internal testing missed.
"Shift left" is the DevSecOps principle of moving security activities earlier in the development lifecycle. Finding a vulnerability during design costs almost nothing to fix (change the design). Finding the same vulnerability in production costs orders of magnitude more (patch the live system, test the patch, deploy without downtime, investigate whether the vulnerability was exploited, and potentially notify affected users).
The economics are quantifiable. IBM's Systems Sciences Institute research found that defects found during design cost 1x to fix, during development 6.5x, during testing 15x, and in production 100x. Security vulnerabilities follow the same cost curve. DevSecOps shifts security left to minimize the cost of finding and fixing vulnerabilities.
Web application exploitation is a top initial access vector in the Verizon DBIR. OWASP's Top 10 documents the most common web application vulnerabilities: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, identification and authentication failures, software and data integrity failures, security logging failures, and server-side request forgery.
These vulnerabilities are preventable through secure development practices. SAST catches injection and cryptographic failures. SCA catches vulnerable components. Threat modeling catches insecure design. DAST catches broken access control and misconfiguration. DevSecOps provides the systematic framework that ensures each check occurs consistently across every application.
Applications include open-source dependencies that introduce supply chain risk. The Log4Shell vulnerability (December 2021) demonstrated the cascading impact: a vulnerability in a single open-source logging library affected hundreds of thousands of applications globally. SCA is the DevSecOps control that provides visibility into dependency risk and enables rapid response when a critical dependency vulnerability is disclosed.
The regulatory response includes SBOM (Software Bill of Materials) requirements. Executive Order 14028 mandates that software suppliers to the federal government provide SBOMs listing all components in their products. SBOMs enable downstream organizations to assess their exposure when a new vulnerability is disclosed. SCA tools generate SBOMs as a standard output.
Secure development practices are mandated by regulatory frameworks. PCI DSS Requirement 6 (Develop and Maintain Secure Systems and Software) requires secure coding training, vulnerability management in custom code, and code review processes. NIST SSDF (Secure Software Development Framework, SP 800-218) defines secure development practices that federal software suppliers must implement. ISO 27001 A.8.25 (Secure Development Lifecycle) requires organizations to establish rules for secure software development.
DevSecOps sits in the VSD (Vulnerability and Surface Defense) domain of the Planetary Defense Model. VSD is the ocean layer: the attack surface that adversaries probe and breach. Application vulnerabilities are a significant portion of that surface. CSR (Continuous Surface Reduction) applies: every application vulnerability is an exposed surface that CSR identifies and eliminates.
The distinction between DevSecOps and traditional application security is operational integration. Traditional application security operates as a separate team that reviews applications before release. DevSecOps integrates security into the development workflow so that security is a continuous practice, not a periodic gate.
CDA's primary DevSecOps mission:
This mission is scoped for organizations that have existing development teams and CI/CD pipelines. CDA does not write application code. CDA integrates security tooling into the development workflow, establishes secure development standards, and trains the development team on security-aware practices.
The interaction with adjacent domains: DPS governs data handling requirements that translate into application security requirements (encrypt PII, restrict data access by role). IAT governs authentication and authorization implementations within applications (OAuth 2.0 configuration, session management, RBAC). SPH governs the infrastructure that applications run on (container runtime security, host hardening, WAF configuration). TID detects exploitation of application vulnerabilities in production (WAF alerts, RASP detections, anomalous API usage patterns). RGA mandates secure development through compliance frameworks and uses application security metrics (vulnerability density, remediation velocity, SCA coverage) for governance reporting.
CDA approaches DevSecOps differently from application security vendors in one way: we integrate application security into the broader PDM posture view. A SAST vendor measures application vulnerability counts. CDA measures application vulnerability density as a VSD metric that feeds the composite Posture Score alongside infrastructure vulnerability density, attack surface size, and patch compliance. Application security is not a separate program. It is a VSD program component measured in the same framework as every other attack surface control.
Word count: 1,847