This chapter covers DevSecOps—the integration of security practices into DevOps pipelines. For the SY0-701 exam, this maps to Objective 4.2 (Security Operations) and tests your understanding of how to implement security automation, continuous monitoring, and compliance as code. You'll learn the specific tools, processes, and culture shifts that make DevSecOps effective, and how to avoid common pitfalls that lead to vulnerabilities in CI/CD pipelines.
Jump to a section
Imagine a car assembly line where robots and workers install parts sequentially. Traditionally, security would be a final inspection station at the end of the line—if a car fails, it's sent back, costing time and money. In DevSecOps, we embed quality gates (security checks) at every station: the moment a weld is made, a camera checks its strength; when a wire is connected, a continuity test runs. Each gate automatically stops the line if a defect is found, and the defect is logged with the exact station and time. Developers (the assembly workers) get immediate feedback—they can fix the issue right then, not after 100 more cars have passed. The assembly line also uses a digital twin (a virtual model) to simulate the entire build before physical production starts, catching design flaws early. This mirrors DevSecOps: code is built in small increments, each commit triggers automated security tests (static analysis, dependency scanning), and if a vulnerability is found, the pipeline halts. The developer sees the failure in their pull request and fixes it before it merges. The digital twin is the pre-commit security scan or the integration test environment. The key is that security is not a separate phase—it's a built-in function of every step, just like the quality gates on the assembly line.
What is DevSecOps?
DevSecOps (Development, Security, and Operations) is a philosophy that integrates security practices into the DevOps lifecycle. Instead of security being a separate phase at the end of development (a 'security gate'), it is embedded from the start—'shifting left'. This means security checks happen as early as possible, ideally at the code commit stage. The goal is to automate security testing and compliance validation so that vulnerabilities are detected and remediated quickly, without slowing down the delivery pipeline.
How DevSecOps Works Mechanically
A typical DevSecOps pipeline includes several stages: plan, code, build, test, release, deploy, operate, and monitor. Security is injected at each stage:
Plan: Threat modeling and security requirements are defined. Tools like OWASP Threat Dragon help create threat models.
Code: Developers use IDE plugins (e.g., SonarLint) for real-time static analysis. Secrets scanning (e.g., GitLeaks) prevents credentials from being committed.
Build: The code is compiled, and dependency scanning (e.g., OWASP Dependency-Check) checks for known vulnerabilities (CVEs) in libraries. Software Bill of Materials (SBOM) is generated.
Test: Automated security tests run: SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and interactive tests (IAST). Fuzzing may be used for input validation.
Release: Signing and verification of artifacts. Container images are scanned (e.g., Trivy, Clair). Policy enforcement (e.g., Open Policy Agent) ensures compliance.
Deploy: Infrastructure as Code (IaC) scanning (e.g., Checkov, tfsec) validates that cloud templates are secure. Deployment is done with least privilege.
Operate: Continuous monitoring with SIEM (e.g., Splunk, ELK) and runtime security (e.g., Falco for containers).
Monitor: Feedback loops send security findings back to developers.
Key Components and Tools
SAST (Static Application Security Testing): Analyzes source code for vulnerabilities without executing it. Tools: SonarQube, Checkmarx, Fortify. SAST is fast and can be integrated into CI pipelines. It finds issues like SQL injection, XSS, and buffer overflows early.
DAST (Dynamic Application Security Testing): Tests running applications by sending malicious payloads. Tools: OWASP ZAP, Burp Suite, Acunetix. DAST catches runtime issues but is slower and may require staging environments.
IAST (Interactive Application Security Testing): Combines SAST and DAST by instrumenting the application to monitor interactions. Tools: Contrast Security, Seeker. IAST runs during functional tests and provides accurate results.
Dependency Scanning: Checks open-source libraries for known CVEs. Tools: Snyk, GitHub Dependabot, OWASP Dependency-Check. The National Vulnerability Database (NVD) is the reference.
Container Scanning: Scans Docker images for vulnerabilities in base images and installed packages. Tools: Trivy, Clair, Anchore. Scans should check both OS packages and application dependencies.
IaC Scanning: Analyzes Terraform, CloudFormation, Ansible scripts for misconfigurations. Tools: Checkov, tfsec, Terrascan. Common issues: open security groups, unencrypted storage, overly permissive IAM roles.
Secrets Management: Tools like HashiCorp Vault, AWS Secrets Manager, or CyberArk store credentials securely. Secrets are injected at runtime, never hardcoded.
Policy as Code: Tools like Open Policy Agent (OPA) or HashiCorp Sentinel enforce security policies declaratively. For example, "All S3 buckets must have encryption enabled."
Compliance as Code: Automates compliance checks (e.g., PCI DSS, HIPAA) using tools like InSpec or Chef Compliance.
How Attackers Exploit Weak DevSecOps
Supply Chain Attacks: Malicious code injected into dependencies. Example: SolarWinds (2020) where attackers compromised the build pipeline and inserted a backdoor. Countermeasure: Use signed commits, verify checksums, and scan dependencies with SBOM.
CI/CD Pipeline Poisoning: Attackers gain access to CI server (e.g., Jenkins) and modify build scripts to exfiltrate secrets or deploy malicious code. Countermeasure: Least privilege for CI runners, use short-lived tokens, and audit pipeline changes.
Credential Leakage: Developers accidentally commit API keys or passwords to public repos. Countermeasure: Pre-commit hooks (e.g., GitLeaks), secret scanning in pipeline, and revoke leaked secrets immediately.
Insecure Artifact Storage: Unprotected artifact repositories (e.g., Docker Hub, Nexus) allow tampering. Countermeasure: Sign artifacts, use private registries, and scan images.
Real Command/Tool Examples
SAST with SonarQube: sonar-scanner -Dsonar.projectKey=myproject -Dsonar.sources=.
Dependency check: dependency-check --scan ./target/myapp.jar --format HTML
Container scan with Trivy: trivy image myapp:latest --severity HIGH,CRITICAL
IaC scan with Checkov: checkov -d . --framework terraform
Secrets scan with GitLeaks: gitleaks detect -v
Policy enforcement with OPA: opa eval --data policy.rego --input input.json "data.terraform.deny"
Standards and Frameworks
NIST SP 800-204 (Secure DevOps)
OWASP DevSecOps Maturity Model
CIS Benchmarks for CI/CD tools
SLSA (Supply-chain Levels for Software Artifacts) for supply chain security
Variants
GitOps: Git as single source of truth; changes are made via pull requests, and security checks are enforced before merge.
Shift Left vs. Shift Right: Shift left pushes security earlier; shift right involves runtime monitoring and feedback.
DevSecOps vs. SecDevOps: Same concept; order emphasizes security first.
Plan: Threat Modeling and Requirements
In the planning phase, the security team conducts threat modeling using frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) or PASTA. They identify assets, trust boundaries, and potential attack vectors. Security requirements are documented (e.g., 'All API endpoints must authenticate using OAuth 2.0'). These requirements become acceptance criteria for user stories. Tools like OWASP Threat Dragon or Microsoft Threat Modeling Tool are used. The output is a threat model diagram and a list of security controls to implement. This step ensures security is considered before any code is written, reducing costly rework.
Code: Secure Coding and Pre-commit Hooks
Developers write code with IDE plugins that provide real-time static analysis (e.g., SonarLint). Pre-commit hooks (using tools like pre-commit or GitLeaks) run local checks before code is committed: they scan for secrets, enforce code style, and run linters. If a secret is detected, the commit is rejected. Developers also use signed commits (GPG) to ensure integrity. The code is pushed to a feature branch in a version control system (e.g., GitHub, GitLab). At this point, no automated security tests have run on the server yet—only local checks.
Build: Compilation and Dependency Scanning
When a pull request is created, the CI server (e.g., Jenkins, GitHub Actions) triggers a build. The code is compiled, and dependencies are downloaded. Dependency scanning tools (e.g., OWASP Dependency-Check, Snyk) check each library against the National Vulnerability Database (NVD). If a critical vulnerability (CVSS >= 9.0) is found, the build fails. A Software Bill of Materials (SBOM) in CycloneDX or SPDX format is generated. The build artifacts (JAR, Docker image) are signed using GPG or Sigstore. Logs show: 'Dependency check found 2 CVEs (CVE-2024-1234, CVE-2024-5678). Build failed.'
Test: SAST, DAST, and Unit Tests
After a successful build, automated security tests run. SAST scans source code for vulnerabilities (e.g., SQL injection, XSS). Tools like SonarQube analyze the code and report issues with severity. DAST scans the running application in a staging environment by sending malicious payloads (e.g., OWASP ZAP). IAST agents instrument the application to detect vulnerabilities during functional tests. Unit tests with security assertions (e.g., 'should reject invalid input') also run. If any SAST/DAST issue is high severity, the pipeline stops. Test results are published to the developer's pull request as comments.
Release: Artifact Signing and Policy Check
Before release, the build artifact (e.g., Docker image) is scanned again with Trivy or Clair for vulnerabilities. The image is signed using Docker Content Trust or Notary. Policy as code (OPA) checks if the image meets compliance rules (e.g., 'Must not run as root'). The SBOM is attached to the release. If all checks pass, the artifact is promoted to a release repository (e.g., Docker Hub, Nexus). A release ticket is automatically created with all scan results. This step ensures only verified, compliant artifacts are deployed.
Deploy: IaC Scanning and Infrastructure Provisioning
Infrastructure as Code (Terraform, CloudFormation) is scanned with Checkov or tfsec before apply. Common misconfigurations like open security groups (0.0.0.0/0), unencrypted S3 buckets, or overly permissive IAM roles are flagged. If violations are found, the deployment is blocked. The CI/CD pipeline uses a service account with least privilege to provision resources. Secrets are injected from Vault at runtime, not hardcoded. Deployment is done in a blue/green or canary pattern to minimize impact. Logs show: 'Checkov failed on rule CKV_AWS_21 (S3 bucket ACL allows public access). Deployment aborted.'
Operate: Runtime Monitoring and Incident Response
Once deployed, runtime security tools monitor the application. Falco detects anomalous syscalls (e.g., reverse shell). A SIEM (Splunk, ELK) aggregates logs from the application, host, and network. Intrusion detection (Snort, Suricata) monitors traffic. If an alert fires (e.g., 'Crypto miner detected'), the incident response playbook is triggered: the pipeline may automatically rollback to the last known good version. Feedback loops send security findings to the development team via ticketing systems (Jira) or dashboards. This step ensures continuous security even after deployment.
Scenario 1: E-commerce Platform Dependency Vulnerability A large e-commerce company uses a CI/CD pipeline with Jenkins. A developer commits code that pulls a new version of a logging library. The dependency scan (Snyk) finds CVE-2024-1234 in that library (a remote code execution vulnerability). The build fails. The developer sees the error in the pull request and reverts to the previous version. The security team is notified via Slack. The SBOM is updated. The incident is logged in Jira. Common mistake: A developer might ignore the warning and force merge, saying 'It's just a logging library.' The correct response is to block the merge and find a patched version or alternative library.
Scenario 2: Misconfigured S3 Bucket in IaC A startup uses Terraform to deploy AWS infrastructure. A junior engineer writes a Terraform script that sets an S3 bucket ACL to 'public-read'. The IaC scan (Checkov) flags this as a critical violation (CKV_AWS_21). The pipeline stops before deployment. The engineer receives a detailed error message explaining the risk. They change the ACL to 'private' and re-run the pipeline. Common mistake: The engineer might think 'It's just a test bucket' and bypass the scan. The correct response is to enforce the scan as a mandatory gate, and educate the engineer on least privilege.
Scenario 3: Secrets Leaked in Public Repo A developer accidentally commits AWS access keys to a public GitHub repository. A pre-commit hook (GitLeaks) catches the secret and rejects the commit. The developer is alerted immediately and removes the keys. However, if the hook was not installed, the keys would be exposed. In that case, the organization would need to rotate the keys immediately and scan the repo for any other secrets. Common mistake: Relying only on pre-commit hooks without a server-side scan. The correct approach is to have both pre-commit hooks and a CI pipeline scan (e.g., GitLeaks in CI) to catch secrets that bypass local hooks.
What SY0-701 Tests on DevSecOps
Objective 4.2 explicitly covers 'Secure DevOps' and 'Continuous security monitoring'.
Sub-objectives include: Integrating security into CI/CD pipelines, automating security testing (SAST, DAST, IAST), implementing infrastructure as code security, and managing secrets.
Know the difference between SAST (static, before execution) and DAST (dynamic, during execution).
Understand the purpose of a Software Bill of Materials (SBOM) in supply chain security.
Recognize tools: SonarQube (SAST), OWASP ZAP (DAST), Trivy (container scan), Checkov (IaC scan), GitLeaks (secrets).
Be familiar with policy as code (OPA) and compliance as code (InSpec).
Common Wrong Answers and Why
'SAST and DAST are interchangeable.' – Wrong. SAST analyzes source code without running it; DAST tests a running application. They find different vulnerabilities.
'DevSecOps means the security team does all testing at the end.' – Wrong. DevSecOps shifts security left, embedding it throughout the pipeline.
'Dependency scanning is only needed for production releases.' – Wrong. It should be done at every build, especially in CI/CD.
'Secrets management is not part of DevSecOps.' – Wrong. Managing secrets (API keys, passwords) is critical to prevent leaks.
Specific Terms and Values
CVSS: Common Vulnerability Scoring System (0-10). Critical >=9.0.
NVD: National Vulnerability Database.
SBOM: Software Bill of Materials (format: CycloneDX, SPDX).
SLSA: Supply-chain Levels for Software Artifacts (levels 1-4).
OWASP: Open Web Application Security Project.
CVE: Common Vulnerabilities and Exposures.
RFC 2119: Defines MUST, SHOULD, MAY for requirements.
Trick Questions
'Which tool would you use to find an SQL injection vulnerability in source code?' → SAST (SonarQube), not DAST (ZAP).
'Which tool checks for misconfigurations in Terraform?' → Checkov, not Trivy (container scan).
'What is the purpose of a pre-commit hook?' → To catch issues (like secrets) before they are committed, not after.
Decision Rule for Eliminating Wrong Answers
On scenario questions, ask: (1) Is the check happening before or after code execution? If before, it's SAST; if after, it's DAST. (2) Is the tool scanning code, dependencies, containers, or infrastructure? Match the tool to the artifact. (3) Is the security control automated? If yes, it's DevSecOps; if manual, it's not. (4) Does the scenario mention 'shifting left'? That means earlier in the pipeline.
DevSecOps integrates security into every stage of the CI/CD pipeline, not as a final gate.
SAST analyzes source code statically; DAST tests running applications dynamically.
Dependency scanning checks libraries against the NVD for known CVEs.
Container scanning (Trivy, Clair) finds vulnerabilities in Docker images.
IaC scanning (Checkov, tfsec) prevents misconfigurations in cloud templates.
Secrets management tools (Vault, AWS Secrets Manager) prevent credential leaks.
Policy as code (OPA) enforces security rules automatically in the pipeline.
SBOM (Software Bill of Materials) provides visibility into software components.
Pre-commit hooks catch secrets and code quality issues before commit.
Shift left means performing security checks as early as possible in development.
These come up on the exam all the time. Here's how to tell them apart.
SAST (Static Application Security Testing)
Analyzes source code or binary without execution
Finds vulnerabilities early in development (shift left)
Fast and can be integrated into CI/CD pipeline
Cannot detect runtime configuration issues
Examples: SonarQube, Checkmarx, Fortify
DAST (Dynamic Application Security Testing)
Tests a running application by sending payloads
Finds vulnerabilities that appear only at runtime
Slower and requires a running environment
Can detect misconfigurations and authentication flaws
Examples: OWASP ZAP, Burp Suite, Acunetix
Container Image Scanning (Trivy)
Scans Docker/OCI images for vulnerabilities in packages
Checks for known CVEs in OS and application dependencies
Used after build, before deployment
Output: list of vulnerable packages with CVSS scores
Integrates with registry and CI pipeline
IaC Scanning (Checkov)
Scans Terraform, CloudFormation, etc. for misconfigurations
Checks for security best practices (e.g., open ports, encryption)
Used before applying infrastructure changes
Output: policy violations with remediation guidance
Integrates with CI pipeline and policy engines
Mistake
DevSecOps means adding a security team to the DevOps team.
Correct
DevSecOps is a cultural and technical shift where security practices are automated and integrated into the pipeline, not just adding people. It's about shared responsibility.
Mistake
SAST and DAST find the same vulnerabilities.
Correct
SAST finds vulnerabilities in source code (e.g., SQL injection in string concatenation) without execution. DAST finds runtime vulnerabilities (e.g., XSS in a live app). They complement each other.
Mistake
Dependency scanning is only needed for open-source libraries.
Correct
Dependency scanning should cover all third-party components, including commercial libraries and container base images. All dependencies can have vulnerabilities.
Mistake
Policy as code is only for compliance audits.
Correct
Policy as code (OPA) enforces security policies in real-time during the pipeline, preventing non-compliant deployments before they happen.
Mistake
Secrets management is optional if you trust your developers.
Correct
Secrets management is essential even with trusted developers because mistakes happen (e.g., committing to a public repo) and secrets can be stolen from compromised systems.
SAST (Static Application Security Testing) analyzes source code or binaries without executing them, finding vulnerabilities like SQL injection in code. It is fast and runs early in the pipeline. DAST (Dynamic Application Security Testing) tests a running application by sending malicious requests, finding runtime issues like XSS. DAST is slower but catches configuration and authentication flaws. For the exam, remember that SAST is 'white-box' (code) and DAST is 'black-box' (runtime). Both are needed for comprehensive coverage.
An SBOM is a formal record of all components (libraries, dependencies, versions) used in a software product. It is important for supply chain security because it allows organizations to quickly identify if they are affected by a newly disclosed vulnerability (e.g., Log4Shell). The SBOM is generated during the build phase and should be stored and updated with each release. On the exam, know that SBOM formats include CycloneDX and SPDX, and that SBOMs are a key part of securing the software supply chain.
Policy as code (e.g., Open Policy Agent - OPA) allows security policies to be written as code and enforced automatically in the CI/CD pipeline. For example, a policy can require that all S3 buckets have encryption enabled. If a Terraform script violates this policy, the pipeline fails before deployment. This ensures consistent, auditable, and automated compliance. On the exam, remember that policy as code is part of 'compliance as code' and helps enforce security requirements without manual review.
Immediately revoke the secret (e.g., rotate API keys, change passwords). Then, remove the secret from the repository history (e.g., using git filter-branch or BFG Repo-Cleaner). Scan the repository for any other secrets. Notify affected systems and users. Finally, implement preventive measures: pre-commit hooks (GitLeaks), server-side scanning in CI, and secrets management tools (Vault). On the exam, the correct answer is always to revoke the secret first, then remove it from history.
A pre-commit hook is a script that runs automatically before a commit is accepted by Git. It can check for secrets (e.g., GitLeaks), enforce code formatting, run linters, or perform simple static analysis. If the hook fails, the commit is rejected. This catches issues early, before they reach the repository. On the exam, pre-commit hooks are an example of 'shifting left'—catching problems as early as possible in the development process.
Continuous monitoring involves observing the production environment for security threats using tools like SIEM (Splunk, ELK), intrusion detection (Snort), and runtime security (Falco). It provides feedback to the development team about vulnerabilities that were missed or introduced at runtime. This is part of 'shift right'—improving security based on operational data. On the exam, continuous monitoring is part of the 'operate' phase and feeds into the 'plan' phase for future improvements.
A CI/CD pipeline automates building, testing, and deploying code. A DevSecOps pipeline adds security checks at every stage: SAST, DAST, dependency scanning, container scanning, IaC scanning, secrets management, and policy enforcement. The key difference is that security is integrated, not bolted on at the end. On the exam, DevSecOps is the practice of 'baking in' security, not 'frosting it on'.
You've just covered DevSecOps — Security in DevOps Pipelines — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?