ECDE flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Three Ways of DevOps

Gene Kim's principles: flow of work from development to operations, fast feedback loops from right to left, and a culture of continual experimentation and learning.

CALMS framework

An assessment model for DevOps maturity covering Culture, Automation, Lean, Measurement, and Sharing. Culture and Sharing cannot be supplied by tooling alone.

Blameless postmortem

A structured review after an incident that examines contributing conditions in systems and processes rather than assigning individual fault, producing owned, dated countermeasures.

DORA four key metrics

Deployment frequency, lead time for changes, change failure rate, and time to restore service. The first two measure throughput; the last two measure stability.

Conway's Law

The principle that a system's architecture mirrors the communication structure of the organization that built it, which is why team topology design affects system design.

Shift left

Moving security activities earlier into design and coding so defects are found when remediation is cheapest, typically by automating controls into the pipeline.

Policy as code

Expressing security and compliance rules in versioned, testable files such as OPA Rego or Checkov policies, evaluated automatically during pipeline stages.

STRIDE threat categories

Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege - a mnemonic for systematically enumerating design threats.

Paved road

A centrally maintained, secure-by-default toolchain and template set that delivery teams are encouraged to adopt, making the compliant path the easiest path.

Risk-based vulnerability triage

Prioritizing findings by exploitability and reachability in the deployed system rather than by raw severity count, so internet-facing exploitable issues come first.

Threat modeling inputs

Data-flow diagrams, trust boundaries, entry points, assets, and attacker capabilities. Outputs are ranked threats, each mapped to a mitigation or acceptance decision.

Abuse case

A backlog item describing how an attacker could misuse a feature, written so it has a verifiable acceptance criterion that can later be automated as a test.

Data classification in planning

Assigning data to tiers such as public, internal, confidential, or restricted at design time, which then determines encryption, retention, and access requirements.

Architecture decision record

A short versioned document capturing a significant design choice, its context, alternatives considered, and consequences, including security-relevant decisions like authentication model.

Security acceptance criteria

Testable conditions attached to a user story that define when a security requirement is satisfied, enabling automated verification later in the pipeline.

SAST

Static application security testing analyzes source or bytecode without executing it, finding injection, unsafe deserialization, and crypto misuse, with false positives requiring triage and baselining.

Secret scanning response order

First revoke and rotate the exposed credential, then purge it from repository history. Removing it from the latest commit alone leaves it in history.

Pre-commit hooks

Client-side checks such as linting, formatting, and secret pattern detection run before a commit is created. They give fast feedback but are bypassable, so CI must repeat them.

Branch protection rules

Server-side repository settings requiring reviews, passing status checks, and signed commits while blocking direct pushes to protected branches, turning review policy into enforcement.

IaC scanning

Linting infrastructure definitions such as Terraform or Kubernetes manifests for insecure configuration before provisioning, using tools like Checkov, tfsec, or kube-linter.

SBOM

A software bill of materials listing components and versions in an artifact, commonly in SPDX or CycloneDX format, regenerated per build and stored alongside the artifact.

SLSA provenance levels

A graded scale of build integrity from level 1, documented build, to level 4, hermetic and reproducible builds with two-party review on a hardened platform.

Artifact signing and verification

Cryptographically signing build outputs, for example with Sigstore cosign or in-toto attestations, and verifying signatures at admission time so tampered images are rejected.

DAST

Dynamic application security testing probes a running application from outside, detecting runtime misconfiguration and authentication flaws that static analysis cannot see. Run against non-production.

Ephemeral build agents

Short-lived, freshly provisioned build environments destroyed after each job, preventing persistence of malware or credentials between builds.

Blue-green deployment

Running two identical environments and switching traffic from the live one to the newly deployed one, enabling near-instant rollback by switching back.

Canary release

Routing a small percentage of production traffic to a new version and expanding exposure only if error rate, latency, and saturation metrics stay within thresholds.

Release versus deploy

Deployment is the technical act of installing a version; release is the business decision to expose it to users, decoupled via feature flags.

Admission control

A cluster-side gate such as OPA Gatekeeper or Kyverno that rejects workloads violating policy, including unsigned images or non-compliant manifests, before they start.

Expand-contract migration

A backward-compatible database change pattern that adds new structures before removing old ones, so the previous application version keeps working during rollback.

Four golden signals

Latency, traffic, errors, and saturation - the minimum metric set for monitoring a service and the basis for defining service level objectives.

Error budget

One minus the service level objective. Exhausting it conventionally triggers a feature-release freeze until reliability work restores the budget.