EXERCISE 3 — Manual config is the root of recurring misconfiguration
=====================================================================

WHY MANUAL, PER-SERVER CONFIGURATION IS THE ROOT CAUSE:
  - When configuration is done by hand, environment by environment, it
    inevitably DIVERGES and DRIFTS:
      * One server gets hardened; the next is set up slightly differently or by
        a different person who misses a step.
      * A setting is changed "temporarily" for debugging (debug mode on, a port
        opened, a permission loosened) and never reverted.
      * Over time, "secure" and "insecure" environments drift apart, and nobody
        has a single source of truth for what the correct, hardened state is.
  - Humans are inconsistent and forgetful, and there's no automatic check that a
    given box matches the intended secure baseline. So misconfigurations get
    RE-INTRODUCED: a config you can change by hand is one you will eventually
    change by hand and forget. The same vulnerabilities recur across servers and
    over time.

HOW "CONFIGURATION AS CODE" + AUTOMATED SCANNING FIXES IT:
  - CONFIGURATION AS CODE (Infrastructure as Code): define the hardened state
    declaratively in version control — Terraform/Ansible/CloudFormation for
    infra, hardened container BASE IMAGES, framework/server config files
    committed to the repo. Every environment is PROVISIONED FROM THE SAME
    DEFINITION, so dev/staging/prod are identical and reproducibly secure. There
    is one authoritative, reviewable, diff-able source of truth; changes go
    through code review.
  - DRIFT DETECTION & SCANNING: automated tools continuously check reality
    against the definition and flag deviations — cloud security posture
    management (CSPM), IaC scanners, container/image scanners, and HTTP header
    checkers (securityheaders.com/Observatory) wired into CI. A regression
    (debug left on, a bucket made public, a missing header) is caught
    automatically before/at deploy, not after a breach.
  - Net effect: the SECURE STATE becomes the DEFAULT, REPRODUCIBLE state, and
    drift is visible and correctable. You harden once (in code) and get it
    everywhere, every time.

A CONCRETE DRIFT EXAMPLE, AND HOW IaC PREVENTS IT:
  - DRIFT: an engineer enables a framework's DEBUG mode on the production server
    to diagnose an incident, intending to turn it off later — but forgets. Weeks
    later, production is leaking stack traces (env vars, paths, queries) to every
    visitor. A purely manual setup has no mechanism to notice.
  - WITH IaC: production config (debug=false) is defined in code and applied by
    the pipeline. A manual change either (a) gets OVERWRITTEN on the next
    deploy/converge back to debug=false, and/or (b) is flagged as DRIFT by the
    config scanner ("running state != declared state"), alerting the team. The
    insecure change can't silently persist because the declared secure state is
    authoritative and enforced.

CONNECTION TO SECURE DEFAULTS (A04) AND PIPELINE INTEGRITY (A08):
  - SECURE DEFAULTS (A04): configuration-as-code is how you MAKE the secure
    configuration the default. Instead of hoping each deploy is hardened, the
    baseline definition IS hardened, so every new environment starts secure by
    design. A05 is largely "failure to apply secure defaults consistently"; IaC
    operationalizes the A04 principle.
  - PIPELINE INTEGRITY (A08): this all depends on a trustworthy build/deploy
    PIPELINE. If the CI/CD pipeline or IaC definitions can be tampered with, the
    "secure config" can be subverted at the source (A08 — software & data
    integrity failures: unsigned/poisoned build steps, compromised dependencies
    in the toolchain). So you must also protect the pipeline itself — signed
    commits/artifacts, least-privilege CI, integrity checks — so the hardened
    config you ship is the config that actually runs.

ONE-LINE TAKEAWAY:
  Hand-configured systems drift and re-acquire misconfigurations; define the
  hardened state as code (IaC, hardened images, versioned config) with automated
  drift/config scanning so every environment is identically secure-by-default
  (A04) — and protect the pipeline that delivers it (A08).