Security used to be the gate at the end of the pipeline — the review that happened after the code was written, shortly before someone discovered it needed rewriting. DevSecOps exists because that model stopped working the moment teams started deploying several times a day, and the EC-Council ECDE certification is built around what replaced it.
The structure of the exam tells you most of what you need to know about its philosophy. Five of its seven modules march through the pipeline in order — plan, code, build and test, release and deploy, operate and monitor — because the whole premise is that security is not a stage but something present at every stage. This guide covers all seven modules, why the pipeline sequence matters, and how to prepare for a four-hour exam that publishes no domain weightings.
What Is the EC-Council ECDE Certification?
ECDE is the EC-Council Certified DevSecOps Engineer credential, exam code 312-97. It validates your ability to embed security throughout the DevOps lifecycle — from threat modelling during planning, through secure coding and automated testing, to container security at deployment and continuous monitoring in production. It certifies practice rather than philosophy.
The role it describes is a genuine hybrid. A DevSecOps engineer is not a security reviewer attached to a delivery team, nor a developer who has read a security book. It is someone who builds security controls into the automation itself, so that the pipeline enforces standards without a person remembering to check.
| Attribute | Detail |
|---|---|
| Exam code | 312-97 |
| Exam name | EC-Council Certified DevSecOps Engineer (ECDE) |
| Number of questions | 100 |
| Duration | 240 minutes (4 hours) |
| Passing score | 70% |
| Price | $550 USD |
Four hours for 100 questions is unusually generous — nearly two and a half minutes each. That duration is a signal about question complexity rather than volume, and it makes stamina a real factor. The 70% threshold means 70 correct answers with 30 to spare, which is a workable margin on a broad syllabus.
What Does the 312-97 Exam Cover?
The exam spans seven modules: DevOps culture, an introduction to DevSecOps, and then five pipeline stages — plan, code, build and test, release and deploy, and operate and monitor. EC-Council does not publish percentage weightings for these modules, which shapes how you should plan your study.
| Module | What it covers |
|---|---|
| Understanding DevOps Culture | Collaboration between development and operations, automation, continuous improvement |
| Introduction to DevSecOps | Integrating security into the lifecycle; culture, automation, monitoring, feedback |
| Pipeline — Plan Stage | Security requirements, threat modelling, cross-team alignment on objectives |
| Pipeline — Code Stage | Secure coding practices, static analysis, IDE-level security controls |
| Pipeline — Build and Test Stage | Automated security testing; SAST and DAST in continuous integration |
| Pipeline — Release and Deploy Stage | Secure deployment, infrastructure-as-code security, container security |
| Pipeline — Operate and Monitor Stage | Logging, monitoring, incident detection and response, SIEM usage |
The absence of published weightings has a practical consequence: you cannot identify where the marks concentrate, so you cannot safely under-prepare any module on the assumption it is minor. Even coverage is the only defensible strategy.
The one structural clue worth using is that five of the seven modules are pipeline stages. If the weighting is roughly proportional to module count, the pipeline stages collectively carry the large majority of the exam, and the two introductory modules are context rather than the main event.
Why Is the Exam Organised Around the Pipeline?
Five of the seven ECDE modules follow the DevSecOps pipeline in sequence — plan, code, build and test, release and deploy, operate and monitor. That structure is deliberate: it encodes the central claim of DevSecOps, which is that security is a property of every stage rather than a checkpoint at the end.
The older model put a security review between “finished” and “shipped.” It worked when releases were quarterly and failed when they became daily, because a gate that takes three days cannot sit in a pipeline that runs in twenty minutes. The response was to distribute security across the pipeline so each stage carries its own controls.
What that means for the exam is that each stage has characteristic security activities you need to know by stage. Threat modelling belongs to planning, static analysis to coding, dynamic testing to build and test, container hardening to deployment, and log-based detection to operations. Questions frequently describe an activity and expect you to place it correctly.
This is also why studying the pipeline in order works better than studying by topic. The stages build on each other — a threat model produced during planning informs which static analysis rules matter during coding — and that dependency is easier to absorb sequentially. The OWASP DevSecOps guideline follows a comparable structure and makes a useful companion reference.
What Do the Plan and Code Stages Test?
The Plan Stage covers identifying security requirements, threat modelling, and aligning teams on security objectives. The Code Stage covers secure coding practices, static analysis, and security controls inside the development environment. Together they are where security becomes cheapest to address — a point the exam returns to repeatedly.
Threat modelling is the plan stage’s central skill. The examinable idea is that reasoning about what could go wrong, before code exists, is dramatically cheaper than discovering it in production. You should understand what a threat model produces and how its output feeds the stages downstream.
On the code stage, static application security testing is the headline. SAST analyses source code without executing it, catching categories of flaw — injection risks, unsafe functions, hardcoded secrets — early enough that fixing them is a small edit rather than an incident. Knowing what SAST can and cannot detect is examinable.
Secure coding practice underpins both, and the OWASP Top Ten is the vocabulary the industry uses for the vulnerability classes involved. Developers moving toward this space from a software security background will find the comparison in this CSSLP versus CISSP guide a useful way to position ECDE against secure-development credentials.
How Are SAST and DAST Tested?
The Build and Test module covers automated security testing integrated into continuous integration, with SAST and DAST named explicitly. The examinable distinction between them is one of the most reliably tested concepts on the entire exam.
The difference is fundamental. SAST is static — it inspects source code without running it, so it can see everything the code contains but cannot observe behaviour. DAST is dynamic — it tests a running application from the outside, so it observes real behaviour but cannot see the code producing it. Neither replaces the other, and knowing which finds which class of problem is the core skill.
The integration question matters as much as the definition. Security testing that runs outside the pipeline gets skipped under deadline pressure; testing that runs automatically on every commit does not. Understanding where each test type belongs in a CI pipeline, and what happens when one fails, is what this module assesses.
Build-stage failure policy is worth thinking through, because it is a genuine engineering trade-off. Failing a build on every finding produces a pipeline nobody trusts and everyone bypasses; failing on none produces theatre. Severity-based gating is the practical answer, and the guidance in NIST SP 800-218 on secure software development frames this well.
What Do Release, Deploy, and Monitor Cover?
The Release and Deploy module covers secure deployment techniques, infrastructure-as-code security, and container security. The Operate and Monitor module covers logging, monitoring, incident detection and response, and SIEM usage. Together they cover everything after the code is judged good enough to ship.
Container security is the most concrete content here. Images can carry vulnerable dependencies, run with excessive privilege, or embed secrets, and each is a distinct problem with a distinct control. Image scanning, minimal base images, and least-privilege runtime configuration are all examinable, and the Docker security documentation covers the underlying model.
Infrastructure as code introduces a security surface that surprises people. When infrastructure is defined in files, a misconfiguration is a code defect — a template with an over-permissive rule provisions that mistake everywhere it is applied. The upside is that IaC can be scanned like any other code, and the exam expects you to see both halves.
Operate and Monitor closes the loop. Logging and SIEM-based detection matter because no pipeline catches everything, and production is where the remaining problems surface. This module overlaps naturally with security operations practice — the reasoning in this Palo Alto SecOps architect guide covers similar detection and response ground from an operations perspective.
Who Should Take the 312-97 Exam?
ECDE suits DevOps engineers moving toward security, application security engineers working with delivery pipelines, and developers with security responsibility. It assumes practical familiarity with CI/CD tooling and the software delivery lifecycle rather than deep security theory.
DevOps engineers are the most natural fit. You already understand pipelines, automation, and infrastructure as code; the new material is the security layer — threat modelling, SAST and DAST, container hardening. That is a genuine but tractable extension of what you do.
Application security specialists come from the other side, understanding vulnerability classes and testing deeply but sometimes lacking pipeline fluency. For them the work is learning how security controls are automated rather than performed, which is a real shift in mindset.
The group who will find it hardest are security professionals with no delivery-pipeline exposure. The exam is thoroughly practical and assumes you know what a build stage does. General security knowledge will not carry the pipeline-specific questions without that grounding.
How Should You Prepare for ECDE?
The most effective ECDE preparation follows the pipeline in order and covers all seven modules evenly, because no weightings are published. Most candidates need six to ten weeks. Building an actual pipeline with security controls in it teaches more than any amount of reading.
| Phase | Focus | Goal |
|---|---|---|
| 1 | DevOps culture and DevSecOps principles | Explain why the security gate model failed |
| 2 | Plan stage — security requirements and threat modelling | Produce a threat model and derive requirements from it |
| 3 | Code stage — secure coding, SAST, IDE controls | Know what static analysis can and cannot find |
| 4 | Build and test — SAST vs DAST in CI | Place each test type correctly and set failure policy |
| 5 | Release and deploy — IaC security, container hardening | Scan an image and fix what it reports |
| 6 | Operate and monitor — logging, SIEM, detection | Explain what production monitoring catches that CI cannot |
| 7 | Timed practice across all seven modules | Sustain accuracy across a four-hour sitting |
Build the pipeline rather than reading about it. Wire a SAST scan into a CI job, add an image scan before deployment, and watch a build fail on a real finding — that sequence makes the integration questions obvious in a way documentation never manages.
Practise at full length before exam day. Four hours is a long sitting, and candidates who have only done short question sets often find their accuracy falling away in the final hour. That is far better discovered in practice than on the day.
Because no weightings are published, resist the urge to guess at priorities. Work through a realistic ECDE practice exam and treat whichever module produces inconsistent results as your priority, regardless of where it sits in the syllabus. The official EC-Council ECDE page is worth checking for current exam status before booking.
Is the ECDE Certification Worth Earning?
ECDE is worth most to engineers working at the intersection of delivery and security — DevOps practitioners taking on security ownership, and application security professionals embedding into delivery teams. Its value comes from certifying a combination that remains genuinely scarce.
The scarcity argument is the strongest one. Organisations have no shortage of people who can build pipelines, and no shortage of people who understand vulnerabilities. People who can express security requirements as pipeline automation are rarer, and that is precisely the profile the exam describes.
Being vendor-neutral helps too. Because ECDE covers DevSecOps practice rather than one vendor’s toolchain, the knowledge transfers across environments — the SAST-versus-DAST reasoning and container hardening principles apply whichever specific tools your employer has chosen.
The honest caveats are cost and breadth. At $550 it is among the more expensive certifications at this level, and because the syllabus spans culture through operations, it certifies working competence across the pipeline rather than deep expertise in any one stage. Treat it as evidence of credible range rather than specialist depth.
Frequently Asked Questions
How many questions are on the ECDE 312-97 exam?
The exam contains 100 questions with a 240-minute limit — four hours, or nearly two and a half minutes per question. That generous duration reflects question complexity, and it makes sustained concentration a genuine factor on exam day.
What is the passing score for 312-97?
The passing score is 70%, meaning 70 correct answers out of 100 with 30 to spare. That is a reasonable margin, though the breadth of the syllabus means weakness across several modules can consume it faster than expected.
How much does the ECDE exam cost?
The exam costs $550 USD, which is toward the higher end for a certification at this level. Third-party practice test products are priced separately and cost considerably less.
Are domain weightings published for ECDE?
No. EC-Council lists seven modules without percentage weightings, so you cannot identify where the marks concentrate. Even coverage across all seven is the only defensible strategy, with extra attention wherever your practice results are inconsistent.
What is the difference between SAST and DAST?
SAST is static analysis — it inspects source code without executing it, seeing everything the code contains but not its runtime behaviour. DAST is dynamic — it tests a running application from outside, observing real behaviour but not the underlying code. They find different classes of problem.
Do you need programming experience for ECDE?
Some development familiarity helps considerably, particularly for the code stage and secure coding content. You do not need to be a professional developer, but you should understand how code moves through a build pipeline and what static analysis is examining.
Is ECDE vendor neutral?
Yes. It covers DevSecOps practice and principles rather than one vendor’s toolchain, so the knowledge transfers across environments. The SAST and DAST reasoning, container hardening, and IaC security concepts apply whichever specific tools an organisation uses.
How does ECDE differ from a general security certification?
ECDE is thoroughly practical and pipeline-specific, assuming you understand CI/CD and the delivery lifecycle. General security credentials cover breadth across domains such as governance and risk. ECDE certifies embedding security into automated delivery rather than security management.
How long should you study for the 312-97 exam?
Six to ten weeks suits most candidates with existing DevOps or application security experience. Follow the pipeline in order rather than jumping between modules, and build a real pipeline with security controls rather than studying the integration theoretically.
Conclusion
ECDE is a pipeline exam. Five of its seven modules walk through plan, code, build and test, release and deploy, and operate and monitor in sequence, because the entire premise of DevSecOps is that security belongs at every stage rather than at a gate before release.
Study it in that order, since each stage informs the next. Learn the SAST-versus-DAST distinction properly — it is the most reliably tested concept on the paper. Build a pipeline, wire security controls into it, and watch a build fail on a real finding. And because no weightings are published, cover all seven modules evenly and let your practice results, not the syllabus order, tell you where to spend extra time.
