This chapter covers DevSecOps and the practice of 'shifting security left'—integrating security controls and testing into the earliest phases of the software development lifecycle. For the CS0-003 exam, this topic falls under Domain 2 (Vulnerability Management), Objective 2.4: 'Explain the importance of integrating security into the development process.' Expect 5–10% of exam questions to address DevSecOps concepts, CI/CD pipeline security, and security testing at different stages. Mastering this chapter will help you understand how to prevent vulnerabilities rather than just react to them, a key mindset tested on the CySA+ exam.
Jump to a section
Imagine building a skyscraper. In traditional construction, you dig the foundation, frame the structure, and add plumbing and electrical work. Only after the building is nearly complete do you bring in a safety inspector, who finds that a critical support beam is misaligned and several floors must be torn down to fix it—massive cost and delay. Shifting security left is like hiring the safety inspector to sit in on every blueprint meeting from day one. Before a single shovel hits the ground, the inspector flags that the beam design is weak and the electrical layout violates code. The architect revises the blueprints instantly—cost: a few hours of redrawing, not millions in demolition. In software, 'shifting left' means integrating security testing and reviews into the earliest phases of development—requirements, design, and coding—rather than waiting until after deployment. Just as the inspector's input is cheap and fast when applied to plans, security flaws found in design or code are exponentially cheaper to fix than vulnerabilities discovered in production. The mechanism is the same: move the feedback loop as close to the point of creation as possible, reducing rework and risk.
What Is DevSecOps and Shifting Security Left?
DevSecOps is an extension of the DevOps philosophy that integrates security practices into every phase of the software development lifecycle (SDLC). The core principle is 'shifting security left'—moving security testing and controls earlier in the development process, ideally to the design and coding stages, rather than performing security checks only at the end (or after deployment). This approach reduces the cost and effort of fixing vulnerabilities because defects are caught when they are easiest and cheapest to remediate.
The SDLC Stages and Where Security Fits
Traditional SDLC: Requirements → Design → Development → Testing → Deployment → Operations. Security often only appeared during a final penetration test or after a breach. DevSecOps injects security at every stage:
Requirements: Security requirements (e.g., authentication, encryption) are defined alongside functional requirements.
Design: Threat modeling (e.g., STRIDE, PASTA) identifies potential threats and mitigations before code is written.
Development: Developers use secure coding practices, static application security testing (SAST) tools scan code as it is written, and IDE plugins (e.g., SonarLint, Checkmarx) provide real-time feedback.
Testing: Dynamic application security testing (DAST), interactive application security testing (IAST), software composition analysis (SCA) for third-party libraries, and fuzzing are run automatically in CI/CD pipelines.
Deployment: Infrastructure as code (IaC) scanning (e.g., Checkov, tfsec) validates cloud configurations, and container image scanning (e.g., Trivy, Clair) checks for known vulnerabilities.
Operations: Continuous monitoring, runtime application self-protection (RASP), and incident response playbooks are in place.
Key Components and Tools
CI/CD Pipeline Integration: Security tools are automated stages in the pipeline (Jenkins, GitLab CI, GitHub Actions). A build may include SAST, SCA, and IaC scanning steps. If any step fails (e.g., critical vulnerability found), the pipeline halts, preventing insecure code from reaching production.
SAST (Static Application Security Testing): Analyzes source code without executing it. Tools: Fortify, Checkmarx, SonarQube. Default thresholds: fail build if any 'Critical' or 'High' severity issue is found.
DAST (Dynamic Application Security Testing): Tests running applications by simulating attacks. Tools: OWASP ZAP, Burp Suite. Typically run in a staging environment after deployment.
IAST (Interactive Application Security Testing): Combines SAST and DAST by instrumenting the application to detect vulnerabilities during automated tests. Tools: Contrast Assess, HCL AppScan.
SCA (Software Composition Analysis): Scans open-source libraries for known vulnerabilities (CVEs). Tools: Snyk, Black Duck, OWASP Dependency-Check. Default behavior: fail build if library has a CVE with CVSS score ≥ 7.0.
Container Security: Image scanning for OS-level vulnerabilities (e.g., Alpine packages) and misconfigurations. Tools: Trivy, Anchore, Aqua. Common threshold: fail if any 'Critical' CVE exists.
IaC Scanning: Checks Terraform, CloudFormation, Kubernetes manifests for insecure defaults (e.g., S3 bucket public access, security group overly permissive). Tools: Checkov, tfsec, Terrascan.
Cost of Fixing Vulnerabilities Over Time
The 'cost of change' curve shows that fixing a bug during requirements costs ~1x; during design ~6x; during coding ~15x; during testing ~40x; during production ~100x+. Shifting security left capitalizes on this by catching issues early. For example, a SQL injection vulnerability caught via SAST during coding costs a developer 10 minutes to fix; the same flaw found in production may require emergency patching, data breach notification, and legal costs.
Practical Implementation Steps
Embed Security Champions: Train developers in secure coding and have them act as liaisons between security and dev teams.
Automate Security Gates: Integrate SAST, SCA, and IaC scanning into CI/CD pipelines. Use threshold policies to fail builds on critical/high findings.
Threat Model Early: Conduct threat modeling sessions during design reviews. Use the STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
Use Pre-Commit Hooks: Tools like Git Hooks or pre-commit frameworks can run quick scans (e.g., secret detection) before code is pushed.
Shift Left on Secrets Management: Use vault solutions (HashiCorp Vault, AWS Secrets Manager) and never hardcode secrets. Scan repositories for secrets using tools like GitLeaks or TruffleHog.
Verification and Monitoring
Pipeline Logs: Review CI/CD logs to confirm security stages ran and passed. Example GitLab CI job:
sast:
stage: test
script:
- sast-scanner scan .
allow_failure: falseDashboard: Tools like SonarQube provide dashboards showing code quality and security hotspots.
Metrics: Track 'mean time to remediate' (MTTR) and 'vulnerability escape rate' (vulnerabilities found in production vs. pre-production).
Relationship with Other Security Practices
DevSecOps complements: - Vulnerability Management: Shifting left reduces the number of vulnerabilities that reach production, easing the burden on patch management. - Security Awareness Training: Developers must understand secure coding to effectively use SAST results. - Incident Response: With fewer vulnerabilities in production, incident response teams focus on real threats rather than self-inflicted flaws.
Common Pipeline Stage Order
A typical DevSecOps pipeline might have the following stages: 1. Source: Code commit triggers pipeline. 2. Build: Compile code, run unit tests. 3. SAST: Static analysis on source code. 4. SCA: Scan dependencies for known vulnerabilities. 5. Container Build & Scan: Build Docker image, scan for OS vulnerabilities. 6. IaC Scan: Validate Terraform/CloudFormation templates. 7. Deploy to Staging: Deploy to a non-production environment. 8. DAST: Run dynamic tests against the staging instance. 9. Acceptance Tests: Functional and integration tests. 10. Deploy to Production: If all gates pass.
Default Values and Thresholds
SAST: Many tools default to failing on 'Critical' and 'High' severity. Some allow custom thresholds (e.g., fail if >5 medium issues).
SCA: Fail if any library has a CVE with CVSS ≥ 7.0 (High) or if the library is end-of-life.
Container Scan: Fail if any 'Critical' CVE is found; often also block if 'High' CVEs exceed a count (e.g., 10).
IaC Scan: Fail if any 'Critical' misconfiguration (e.g., S3 bucket public read).
Exam-Relevant Terms
Shift Left: Moving security earlier in SDLC.
CI/CD Pipeline: Automated build, test, deployment process.
SAST / DAST / IAST / SCA: Types of security testing.
Threat Modeling: Structured approach to identifying threats (STRIDE, PASTA, ATT&CK).
Secure Coding: Writing code to avoid vulnerabilities (e.g., input validation, output encoding).
Infrastructure as Code (IaC): Managing infrastructure via machine-readable definition files.
Container Security: Securing container images and runtime.
Secrets Management: Handling API keys, passwords, certificates securely.
Security Champions: Developers with security expertise who advocate for security in their teams.
Pre-Commit Hooks: Scripts that run before a commit is finalized, often used to detect secrets or run quick scans.
Integrate SAST into CI Pipeline
Add a static application security testing (SAST) stage to the CI/CD pipeline configuration. For example, in a GitHub Actions workflow, you define a job that runs a SAST tool like CodeQL. The tool analyzes the source code for patterns that indicate vulnerabilities (e.g., SQL injection, XSS). If the tool finds any issue with severity 'Critical' or 'High', the job fails, and the pipeline stops. The developer receives immediate feedback in the pull request, allowing them to fix the issue before merging. This step shifts security left by catching vulnerabilities at the code commit stage, preventing them from entering the build.
Run SCA on Dependencies
After the build stage, execute a software composition analysis (SCA) scan on the project's dependencies (e.g., npm packages, Maven dependencies). The tool compares each dependency against databases of known vulnerabilities (e.g., NVD, GitHub Advisory Database). If a library with a CVE scoring CVSS >= 7.0 is found, the pipeline fails. This step is critical because open-source components often introduce vulnerabilities that are not in the application code itself. By failing the build, the team is forced to update or replace the vulnerable library before deployment.
Scan Container Images for Vulnerabilities
Once the application is built into a container image (e.g., Docker), the image is scanned using a tool like Trivy or Clair. The scan checks the OS packages (e.g., apt, yum) and application dependencies within the image against CVE databases. If any 'Critical' vulnerability is detected, the pipeline halts. This prevents images with known flaws from being pushed to the container registry. The scan also checks for misconfigurations (e.g., running as root, unnecessary packages). The output includes the CVE ID, severity, and fix version, enabling developers to rebuild with patched base images.
Perform IaC Security Validation
Before deploying infrastructure, validate Infrastructure as Code (IaC) templates (e.g., Terraform, CloudFormation) using tools like Checkov or tfsec. These tools parse the configuration files and apply hundreds of policies (e.g., 'S3 bucket should not be publicly accessible', 'EC2 security group should not allow SSH from 0.0.0.0/0'). If a 'Critical' policy violation is found, the pipeline fails. This step ensures that the cloud environment is provisioned securely from the start, preventing misconfigurations that could lead to data exposure.
Run DAST in Staging Environment
After deploying the application to a staging environment, execute dynamic application security testing (DAST) using a tool like OWASP ZAP. DAST simulates attacks against the running application (e.g., sending malicious payloads, testing for SQL injection, XSS, CSRF). It does not require access to source code. The tool crawls the application and then attacks each endpoint. Findings are reported with severity levels. If any 'High' or 'Critical' vulnerability is found, the pipeline can be configured to fail, preventing the build from promoting to production. This step catches runtime vulnerabilities that SAST might miss, such as those caused by misconfigurations or third-party integrations.
Enterprise Scenario 1: Financial Services Firm Automating Security Gates
A large bank adopted DevSecOps to comply with PCI DSS and reduce security debt. They integrated SAST (Checkmarx) and SCA (Snyk) into their Jenkins pipeline. Every code commit triggers a build; if SAST finds a 'Critical' SQL injection or SCA detects a library with a known remote code execution vulnerability, the pipeline fails and notifies the security team. The bank also uses Checkov to scan Terraform templates for misconfigurations, such as open S3 buckets or overly permissive IAM roles. In production, they saw a 70% reduction in vulnerabilities reaching staging within six months. Common issues: developers initially bypassed gates by marking findings as false positives without review, so the bank enforced a policy that only security champions could override gates. Performance consideration: SAST scanning added 5 minutes to build times, which was acceptable given the risk reduction.
Enterprise Scenario 2: E-Commerce Company Shifting Left on Container Security
An online retailer uses Kubernetes and Docker. They integrated Trivy into their GitLab CI pipeline to scan container images. The pipeline fails if any 'Critical' CVE is found, and the team must rebuild the image with a patched base image (e.g., Alpine 3.14 → 3.15). They also use GitLeaks as a pre-commit hook to prevent secrets (e.g., AWS keys) from being committed. Common misconfiguration: developers often pinned their base images to a specific digest, but Trivy still flagged CVEs in packages within that digest. The solution was to use a daily cron job to rebuild images with the latest base image patches. Scale: they run 500+ builds per day; scanning each image takes ~30 seconds. Without shifting left, they would have had to patch running containers, causing downtime.
Enterprise Scenario 3: Healthcare SaaS Provider Integrating Threat Modeling
A healthcare SaaS company uses threat modeling (STRIDE) during design sprints. Before coding a new feature, the team identifies threats like spoofing (weak authentication) or information disclosure (unencrypted PHI). They document mitigations in the design document. During development, SAST (SonarQube) enforces secure coding rules (e.g., no hardcoded secrets). The CI pipeline also runs OWASP Dependency-Check for SCA. The result: zero critical vulnerabilities found in production during the last audit. The biggest challenge was getting developers to adopt threat modeling—they initially saw it as overhead. The company solved this by making threat modeling a 30-minute session at the start of each sprint and tying it to acceptance criteria. Exam tip: The CS0-003 may ask which SDLC phase is most cost-effective for fixing vulnerabilities. The answer is 'design' because changes at that stage are cheapest.
What CS0-003 Tests on DevSecOps (Objective 2.4)
The exam expects you to understand the concept of shifting security left and how to integrate security into the development process. Specific topics include:
The difference between SAST, DAST, IAST, and SCA and when each is used.
The role of CI/CD pipelines in automating security checks.
Threat modeling methodologies (STRIDE, PASTA, ATT&CK).
Secure coding practices (input validation, output encoding, least privilege).
Container and IaC security scanning.
The cost of fixing vulnerabilities at different SDLC stages.
Common Wrong Answers and Why Candidates Choose Them
Confusing SAST and DAST: Many candidates think DAST is run on source code and SAST on running apps. Wrong. SAST is static (source code), DAST is dynamic (running app). The exam may present a scenario: 'Which tool should be used to identify SQL injection during development?' Answer: SAST (since it scans code). Candidates who pick DAST miss that DAST requires a running application.
Believing shifting left eliminates all vulnerabilities: No—it reduces them but cannot catch everything (e.g., business logic flaws). The exam may test that shifting left is a preventive measure, not a silver bullet.
Thinking SCA scans only proprietary code: SCA scans open-source dependencies, not custom code. Candidates might confuse SCA with SAST.
Ignoring IaC scanning: Some candidates think security scanning applies only to application code. The exam may present a scenario with a misconfigured S3 bucket and ask which tool would catch it—Checkov (IaC scanner) versus SAST.
Specific Numbers and Terms That Appear on the Exam
CVSS score thresholds: Often 7.0 (High) as the fail threshold for SCA.
STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
Cost curve: Fixing in production vs. design is ~100x more expensive.
Tools: Know that SonarQube is SAST, OWASP ZAP is DAST, Snyk is SCA, Checkov is IaC, Trivy is container scanning.
Pipeline stages: SAST runs before DAST; container scan runs after build.
Edge Cases and Exceptions
False positives: SAST tools can produce false positives. The exam may ask how to handle them—triage and mark as 'false positive' with justification, not simply ignore.
Third-party libraries: If a vulnerable library has no patch, the team may need to implement a virtual patch (e.g., WAF rule) or accept the risk.
Secrets scanning: Pre-commit hooks catch secrets before they reach the repository, but if a secret is accidentally committed, it must be revoked immediately.
How to Eliminate Wrong Answers
If the question asks about 'testing source code without executing it,' the answer must be SAST, not DAST or IAST.
If the question mentions 'open-source libraries,' the answer is SCA.
If the question is about 'design phase,' the answer is threat modeling.
If the question mentions 'container image,' the answer is container scanning (e.g., Trivy).
If the question mentions 'infrastructure as code,' the answer is IaC scanning (e.g., Checkov).
Shifting security left means integrating security testing into the earliest phases of the SDLC to reduce cost and effort of fixes.
SAST scans source code statically; DAST scans running applications dynamically; SCA scans open-source dependencies; IAST combines both.
CI/CD pipelines automate security gates; a typical pipeline includes SAST, SCA, container scan, IaC scan, and DAST stages.
Threat modeling (STRIDE, PASTA) is performed during the design phase to identify and mitigate threats before coding.
Fixing a vulnerability in production is approximately 100 times more expensive than fixing it during design.
Common tools: SonarQube (SAST), OWASP ZAP (DAST), Snyk (SCA), Checkov (IaC), Trivy (container).
Pre-commit hooks can detect secrets (e.g., API keys) before they are committed to the repository.
DevSecOps is a cultural shift that requires collaboration between development, security, and operations teams.
Pipeline failure thresholds: typically fail on 'Critical' and 'High' severity findings; some allow custom thresholds.
Container security involves scanning images for OS-level CVEs and misconfigurations, and using minimal base images.
IaC scanning ensures cloud resources are provisioned with secure defaults (e.g., no public S3 buckets).
Security champions are developers with security training who advocate for secure practices within their teams.
These come up on the exam all the time. Here's how to tell them apart.
SAST (Static Application Security Testing)
Analyzes source code without execution.
Finds vulnerabilities early in development (coding phase).
Low false positive rate for certain issues (e.g., SQL injection).
Requires access to source code.
Cannot find runtime or configuration issues.
DAST (Dynamic Application Security Testing)
Tests running application by simulating attacks.
Finds vulnerabilities late in SDLC (testing/staging).
Can find runtime issues like misconfigurations.
Does not require source code.
Higher false positive rate; may miss some code-level flaws.
SCA (Software Composition Analysis)
Scans open-source libraries for known CVEs.
Focuses on third-party dependencies.
Fails build if library has CVE with CVSS >= 7.0.
Does not analyze custom code logic.
Tools: Snyk, OWASP Dependency-Check.
SAST (Static Application Security Testing)
Analyzes custom application code for security flaws.
Focuses on coding errors (e.g., XSS, injection).
Fails build on critical/high severity issues in custom code.
Does not check third-party libraries.
Tools: SonarQube, Checkmarx.
Mistake
Shifting security left means security is only done at the start of the SDLC.
Correct
Shifting left means integrating security early, but it does not replace later stages. Security activities continue throughout the SDLC—DAST, monitoring, and incident response are still essential. The goal is to catch issues as early as possible, not to stop testing after coding.
Mistake
SAST and DAST are interchangeable and find the same vulnerabilities.
Correct
SAST analyzes source code and finds vulnerabilities like SQL injection in code paths; DAST tests the running application and can find runtime issues like misconfigurations or business logic flaws. They complement each other—SAST catches coding errors, DAST catches environment-specific issues.
Mistake
DevSecOps requires buying expensive commercial tools.
Correct
Many effective tools are open-source: SonarQube (SAST), OWASP ZAP (DAST), OWASP Dependency-Check (SCA), Checkov (IaC), Trivy (container scanning). The exam focuses on concepts, not specific vendors, but you should know common open-source tools.
Mistake
If the pipeline passes all security stages, the application is completely secure.
Correct
No tool can catch every vulnerability. Business logic flaws, zero-day exploits, and misconfigurations in production may still exist. Shifting left reduces risk but does not eliminate it. Defense in depth remains necessary.
Mistake
Threat modeling is only for security experts.
Correct
Threat modeling should involve developers, architects, and security teams. Tools like STRIDE are designed to be used by non-security professionals. The exam may ask who should participate—the answer includes developers and architects, not just security staff.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
SAST (Static Application Security Testing) analyzes source code without executing it, finding vulnerabilities like SQL injection early in development. DAST (Dynamic Application Security Testing) tests the running application by simulating attacks, catching runtime issues. SAST is used in the coding phase; DAST is used after deployment. The exam may ask which tool to use in a given scenario—e.g., during coding, choose SAST; during staging, choose DAST.
The design phase is the most cost-effective because changes at this stage require only updating documents and plans, not rewriting code or patching production. The cost of fixing a vulnerability increases exponentially as you move through the SDLC: design (1x), coding (6x), testing (40x), production (100x). The exam may present a cost curve and ask which phase yields the lowest remediation cost.
A pre-commit hook is a script that runs automatically before a commit is finalized. It can perform quick checks like scanning for hardcoded secrets (e.g., API keys, passwords), running a linter, or checking file size. If the hook fails, the commit is blocked. This shifts security left by preventing insecure code from entering the repository. Common tools: GitLeaks, TruffleHog.
After a container image is built, a scanner (e.g., Trivy) compares the packages inside the image against CVE databases. It reports vulnerabilities with severity levels. The pipeline can be configured to fail if any 'Critical' or 'High' CVE is found. The developer then rebuilds the image with a patched base image or updates the affected packages. This ensures that only secure images are pushed to the registry.
STRIDE is a threat modeling methodology that categorizes threats into six types: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. It is used during the design phase to systematically identify potential threats to a system. For each component, the team asks how an attacker could exploit each STRIDE category and then designs mitigations. The exam may ask you to identify which STRIDE category applies to a given threat.
When a security tool in the CI/CD pipeline finds a vulnerability that meets the defined threshold (e.g., 'Critical' severity), the pipeline stops and marks the build as failed. This prevents the code or artifact from proceeding to the next stage (e.g., deployment). The developer must fix the issue and recommit. This enforces security gates and ensures vulnerabilities are addressed before reaching production.
A security champion is a developer who has additional security training and acts as a bridge between the development team and the security team. They help their team adopt secure coding practices, triage security findings, and promote security awareness. They also participate in threat modeling and code reviews. The exam may ask about this role in the context of fostering a security culture.
You've just covered DevSecOps and Shifting Security Left — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?