ECDE cheat sheet

DevOps is a sociotechnical movement: it couples cultural change (shared ownership, blameless learning) with technical practice (automation, CI/CD, observability); tooling alone does not constitute DevOps.

CALMS model - Culture, Automation, Lean, Measurement, Sharing - is a common framing for assessing DevOps maturity; Culture and Sharing are the components that tooling cannot supply.

The Three Ways (Gene Kim): (1) flow of work from Dev to Ops, (2) fast feedback loops, (3) continual experimentation and learning; each Way maps to distinct practices such as small batch sizes, telemetry, and game days.

Blameless postmortem rule: focus on contributing conditions in systems and processes, not individual fault; the output is actionable countermeasures with owners and due dates, not a disciplinary record.

Conway's Law: system architecture mirrors organizational communication structure; team topologies (stream-aligned, platform, enabling, complicated-subsystem) are a deliberate response to it.

DORA's four key metrics - deployment frequency, lead time for changes, change failure rate, time to restore service - separate throughput (first two) from stability (last two); elite performers improve both, not one at the expense of the other.

Silos create handoff queues; value-stream mapping exposes wait states. Reducing batch size and handoffs lowers lead time more reliably than speeding up individual tasks.

Psychological safety (Edmondson) is the precondition for surfacing defects and near-misses; without it, measurement data becomes gaming data (Goodhart's Law).

DevSecOps shifts security left: controls are automated into the pipeline and applied continuously, rather than performed as a gate at the end of the lifecycle.

Shift-left has a limit: some controls (runtime protection, secrets rotation, threat detection) remain right-side; a complete program covers plan through operate and monitor.

Core principle: security is a shared responsibility of delivery teams, with a central security function providing paved-road tooling, policy, and expertise rather than manual approvals.

Policy as code (e.g., OPA/Rego, Checkov, Conftest) makes controls versioned, testable, and reviewable; policies live in Git alongside application code.

Defense in depth layers: identity and least privilege, secure configuration, dependency and artifact integrity, secrets management, network segmentation, logging and detection.

Threat modeling (e.g., STRIDE) at design time is cheaper than remediation; each identified threat should map to a control and, where possible, an automated test.

Compliance as code: map regulatory controls to automated evidence (scan reports, signed attestations, audit logs) so audits draw from continuous telemetry rather than annual screenshots.

Risk-based triage rule: prioritize by exploitability and reachability, not raw CVE count; an unreachable vulnerable function in a dev-only dependency is lower priority than an internet-facing exploitable one.

Plan-stage security activities: security requirements, threat modeling, risk classification, and definition of done that includes security acceptance criteria.

Threat modeling steps: diagram the system and trust boundaries, enumerate threats (STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), rank, then define mitigations.

Security user stories and abuse cases belong in the backlog; each should have a verifiable acceptance criterion so it can be automated later in the pipeline.

Data classification (public, internal, confidential, restricted) drives encryption, retention, and access requirements; classify at design time, not after build.

Compliance mapping: identify applicable controls (e.g., PCI DSS, HIPAA, ISO 27001, GDPR) during planning and link each to backlog items that produce evidence.

Risk register entries are decision records: likelihood, impact, owner, mitigation, and review date; unowned risks are effectively unmanaged.

Architecture decision records (ADRs) capture security-relevant choices (authn model, key management, data residency) with context so later reviewers can audit intent.

Least privilege and zero trust are design decisions made in plan: define identities, roles, and trust boundaries before code exists, since retrofitting them is costly.

Code-stage controls: pre-commit hooks, peer review with security checklist, SAST, secret scanning, and dependency/license checks - all triggered on pull request.

SAST analyzes source or bytecode without executing it; it finds injection, unsafe deserialization, and crypto misuse but produces false positives, so triage and baselining are required.

Secret scanning detects credentials in commits and history; on detection the correct response is revoke and rotate first, then purge history - a commit removed from HEAD still exists in history.

Pre-commit hooks (e.g., lint, format, secret patterns) give the fastest feedback; they are bypassable locally, so the same checks must be enforced server-side in CI.

Branch protection: require reviews, passing status checks, signed commits, and no direct pushes to main; this converts policy into an enforced control.

Dependency scanning at code time flags known-vulnerable and outdated libraries via SCA; it complements, not replaces, artifact scanning at build time.

Infrastructure as code in the repo (Terraform, Kubernetes manifests) must be scanned with IaC linters (e.g., Checkov, tfsec, kube-linter) in the same PR workflow.

Commit signing and provenance: signed commits and verified authors reduce supply-chain risk from impersonation and unauthorized changes.

Build-stage controls: isolated ephemeral build agents, pinned and verified dependencies, artifact signing, SBOM generation, container image scanning, and DAST against a deployed test instance.

SBOM formats: SPDX and CycloneDX are the two common standards; an SBOM is only useful if regenerated per build and stored with the artifact.

SLSA levels describe build provenance integrity, from 1 (documented build) to 4 (hermetic, reproducible, two-party review); higher levels require hardened, isolated build platforms.

Artifact signing and verification (e.g., Sigstore cosign, in-toto attestations) let deploy stages reject unsigned or tampered images; signing without admission-time verification provides little protection.

Image scanning rule: scan before push, fail on policy thresholds (e.g., critical with a fix available), and rescan stored images because new CVEs are disclosed after build.

DAST tests the running application from outside; it detects runtime misconfiguration and auth flaws that SAST misses but cannot see code-level issues; run it against a non-production environment.

Test pyramid: many fast unit tests, fewer integration tests, few end-to-end tests; security tests are layered across all three rather than only at the top.

Build reproducibility: pin base image digests, lock dependency versions, and record toolchain versions so the same commit yields the same artifact.

Release vs deploy: release is the business decision to expose a change; deploy is the technical act of installing it. Feature flags decouple the two.

Deployment strategies: rolling (gradual instance replacement), blue-green (two environments, instant switch and rollback), canary (route a small percentage of traffic, expand on healthy metrics).

Progressive delivery gates on metrics: automated analysis of error rate, latency, and saturation during a canary decides promote or roll back.

Admission control at deploy time (e.g., OPA Gatekeeper, Kyverno, image policy webhooks) rejects unsigned images and non-compliant manifests before workloads start.

Secrets at deploy: inject at runtime from a secrets manager (Vault, cloud KMS-backed stores); never bake secrets into images, manifests, or CI variables visible in logs.

Environment promotion should use the same immutable artifact promoted across stages, with configuration injected per environment - rebuilds per environment break provenance.

Rollback must be rehearsed and fast: keep the previous artifact available, use backward-compatible database migrations (expand-contract), and automate the revert trigger.

Separation of duties: the identity that builds an artifact should not be the identity that approves its production deployment; approvals should be recorded as auditable events.

Observability pillars: metrics (aggregatable numbers), logs (discrete events), traces (request paths across services); security detection needs all three plus an audit trail.

The four golden signals - latency, traffic, errors, saturation - are the minimum service dashboard set; SLOs define the acceptable threshold and error budget.

Error budget: 1 minus SLO. When the budget is exhausted, the standard rule is to freeze feature releases and spend effort on reliability.

Runtime protection (RASP, WAF, eBPF/Falco-style detection) catches exploitation attempts that pre-deployment controls could not predict.

Centralized audit logging of control-plane and API events (who changed what, when) is the primary evidence source for incident investigation and compliance.

Incident response phases: prepare, detect, contain, eradicate, recover, and learn; the postmortem closes the loop with tracked countermeasures.

Mean time to detect and mean time to restore are the operational security metrics; reducing MTTD depends on alert coverage and signal quality, not alert volume.

Alert fatigue is a measurable failure: track false-positive rate per rule and tune or retire noisy detections; unreviewed alerts erode response capability.