ECDE key terms

A cultural and engineering approach that unites software development and IT operations teams so they share responsibility for building, delivering, and running software, emphasizing collaboration, automation, and rapid feedback over handoffs between silos.

An extension of DevOps that integrates security practices, tooling, and shared ownership into every stage of the delivery pipeline rather than treating security as a final gate before release.

The practice of moving security and quality activities earlier in the development lifecycle, so defects and vulnerabilities are found when they are cheapest and safest to fix.

An automated sequence of stages that builds, tests, and delivers code changes, enabling frequent, reliable releases by replacing manual steps with repeatable, version-controlled automation.

A practice where developers merge small code changes frequently into a shared branch, and each merge triggers automated build and test runs to detect integration problems quickly.

A practice that keeps software in a deployable state at all times by automating build, test, and release steps, so any validated change can be released on demand with low risk.

An extension of continuous delivery in which every change that passes automated checks is released to production automatically, without a human approval step.

The scope of systems, services, and users affected when a change fails or a component breaks. Limiting blast radius guides deployment strategies such as canary releases and progressive rollouts.

A structured analysis performed during planning that identifies assets, potential attackers, attack paths, and mitigations for a system before code is written.

Static Application Security Testing analyzes source code or binaries without executing them to find insecure patterns such as injection flaws or hardcoded secrets, often run automatically in the code stage.

Dynamic Application Security Testing probes a running application from the outside, simulating attacker requests to find runtime vulnerabilities such as misconfigurations and input handling flaws that static analysis may miss.

Software Composition Analysis inventories open-source and third-party dependencies and flags components with known vulnerabilities or unacceptable licenses, producing a dependency risk report.

A Software Bill of Materials is a machine-readable inventory listing the components and versions that make up a software artifact, supporting vulnerability tracking and supply chain transparency.

Automated detection of credentials, API keys, and tokens committed to source repositories or build logs, so exposed secrets can be revoked and prevented from reaching production.

The controlled storage, distribution, rotation, and auditing of sensitive values such as passwords, keys, and certificates, typically through a dedicated vault rather than in code or configuration files.

Managing servers, networks, and cloud resources through versioned, machine-readable definition files that are applied automatically, making environments reproducible and reviewable like application code.

The practice of defining and enforcing the desired state of systems and software settings through automated tooling, reducing drift and making environments consistent and auditable.

A model in which servers and containers are never patched in place; instead, a new image is built and deployed to replace the old one, simplifying rollback and eliminating configuration drift.

Defining build, test, and deployment stages in a version-controlled file stored with the application, so pipeline changes are reviewed, tested, and audited like any other code change.

A system that records changes to files over time, enabling branching, review, and rollback. In DevSecOps it provides the audit trail and trigger point for automated pipelines.

A request to merge a branch of changes into a shared codebase, providing a review checkpoint where peers, automated tests, and security scans can evaluate the change before merge.

A structured examination of code or configuration by another engineer before it is merged, catching defects and design problems early and spreading knowledge across the team.

A control requiring that at least two people review and approve a change before it takes effect, reducing the risk of error or insider misuse in sensitive systems.

A control that divides sensitive responsibilities among different people or roles so no single individual can both introduce and approve a high-risk change without oversight.

The principle that users, services, and pipeline jobs receive only the permissions they need for their specific task, limiting the damage that a compromised account or misconfigured job can cause.

An authorization model that grants permissions according to a person's or service's assigned role rather than individually, simplifying administration and enforcing consistent access boundaries.

Executing test suites through tooling rather than manual effort, including unit, integration, and end-to-end tests, so every code change is validated consistently and quickly.

A measure of how much of the code, requirements, or risk surface is exercised by automated tests, used to judge whether testing is sufficient rather than as a goal in itself.

A defined pass/fail threshold in a pipeline, such as a maximum number of critical vulnerabilities or a minimum test coverage level, that a build must satisfy before proceeding to the next stage.

An automated checkpoint in the delivery pipeline that blocks promotion of an artifact when defined security conditions are violated, such as unresolved critical vulnerabilities or failed policy checks.

Expressing security and compliance rules in machine-readable form so they can be evaluated automatically and consistently across pipelines and infrastructure, with results that are auditable and version-controlled.

Encoding regulatory and organizational controls as automated, testable rules so that compliance evidence is generated continuously from real system state rather than gathered manually after the fact.

A managed store for build outputs such as packages, container images, and binaries, providing versioning, access control, and a single trusted source for deployment.

A packaged, immutable filesystem and metadata bundle containing an application and its dependencies, built once and deployed identically across environments.

Automated inspection of container images and their layers for vulnerable packages, embedded secrets, and misconfigurations before the image is deployed.

A release technique that runs two identical environments and switches traffic from the current one to the new one after validation, enabling near-instant rollback if problems appear.

A deployment strategy that sends a small portion of live traffic to a new version first, monitors its behavior, and expands exposure only if health and error metrics stay acceptable.

The act of reverting a deployed change to a previously known-good version, ideally automated and fast, to restore service when a release causes failures.

A runtime switch that enables or disables functionality without redeploying code, allowing gradual rollout, targeted testing, and rapid disablement of a faulty feature.

The ability to understand a system's internal state from its external outputs, built on logs, metrics, and traces, so teams can detect and diagnose problems in production.

The continuous collection and review of predefined signals such as availability, latency, and error rates to confirm systems are healthy and to alert responders when thresholds are breached.

The automated transmission of measurements and events from running systems, including metrics, logs, and traces, forming the raw data that monitoring and observability rely on.

A Service Level Objective is a measurable reliability target, such as 99.9 percent successful requests over 30 days, used to balance release velocity against user-facing reliability risk.

The amount of unreliability an SLO permits over a period; when the budget is exhausted, teams typically slow releases and prioritize reliability work.

The organized process for detecting, containing, eradicating, and recovering from security or availability incidents, including defined roles, escalation paths, and post-incident review.

A structured review after an incident that focuses on systemic causes and process improvements rather than individual fault, encouraging honest reporting and learning.

A documented, repeatable procedure for handling a specific operational task or alert, reducing recovery time and making response consistent across responders.

A chronological, tamper-evident record of who changed what and when across code, pipelines, and infrastructure, supporting investigation, compliance evidence, and accountability.

The process of identifying assets and threats, estimating likelihood and impact, and prioritizing treatments, used in planning to decide which security controls a change requires.

Defining, deploying, and testing security controls through versioned automation, so protections such as firewalls, scanning rules, and access policies are applied consistently and reviewed like software.

A team habit of measuring outcomes, running retrospectives, and iterating on process and tooling so delivery speed, quality, and security posture improve over time rather than plateau.

Authorized simulated attacks against a system to discover exploitable weaknesses and validate whether existing controls actually resist real adversary techniques.