Skip to content

Configuration Baseline Diff

Configuration diff — instantiates Substrate Lineage Risk Audit

Compares an inherited system's live configuration against a known-good baseline and flags every setting that differs — surfacing inherited defaults and drift that no one on the current team consciously chose.

An inherited system's configuration is the archetype's purest blind spot: it works, so nobody reads it, and inside it sit defaults and settings the current team never chose. Configuration Baseline Diff makes that invisible layer visible by contrast — it captures the live configuration and subtracts a known-good baseline, so what's left is exactly the set of settings that differ from what should be. Its defining move is that it reasons about settings, not code or provenance, and it produces a delta rather than a judgment: every line of output is a place where the inherited state diverges from an intended one, waiting to be classified as a deliberate choice, an inherited default, or silent drift.

Example

A team inherits a production PostgreSQL instance handed down from a group that has since disbanded. It runs fine, so no one has opened its configuration in a year. A configuration baseline diff compares its live settings against a hardened reference — say, a CIS PostgreSQL benchmark. The delta is telling: connection logging is off, an old superuser role still exists, TLS isn't enforced, and a permissive host-based-authentication rule survives from some long-gone developer's local setup. Not one of these was a decision the current team made. They are inherited defaults that persisted purely because configuration stays invisible until something diffs it against a standard — and the diff is what pulls them into the open where they can be owned.

How it works

  • Choose an authoritative baseline. A vendor default, a hardening benchmark, or your own golden config — the baseline is what "known-good" means for this diff.
  • Capture the live state. Read the inherited system's effective configuration, resolving includes and overrides.
  • Compute the delta. Produce a setting-by-setting difference from the baseline.
  • Classify each difference. Mark it intended, inherited-default, or drift — so the register distinguishes choices from inheritances from decay.

Tuning parameters

  • Baseline authority — vendor default, hardening benchmark, or in-house golden config; a stricter baseline surfaces more but raises false positives on deliberate deviations.
  • Diff granularity — file-level, key-level, or semantic (the effective value after all includes); finer catches subtle overrides at the cost of noise.
  • Scope of capture — one service's config versus the whole host or cluster; wider finds more inherited settings but produces more to triage.
  • Drift-versus-inheritance labeling — how you separate settings that drifted over time from those inherited whole at handoff; this shifts what the register emphasizes.
  • Suppression list — which known-and-accepted deviations to mute so the real signal stays legible.

When it helps, and when it misleads

Its strength is that it is cheap, repeatable, and aimed straight at the archetype's core blind spot: configuration nobody chose but everybody runs.

Its limits follow from what a diff is. It tells you two states differ, not which one is right — a wrong or stale baseline manufactures noise, or worse, false comfort.[1] It sees only what lives in the configuration, missing risk that hides in behavior or data. And the classic misuse is adopting a baseline uncritically, then "fixing" the system to match a standard that itself encodes bad defaults. The discipline is to treat the baseline as a claim that must be justified, and to route each difference to a decision rather than auto-reverting it.

How it implements the components

Configuration Baseline Diff fills the detection-and-registering slice of the archetype — the part that surfaces inherited conditions and flags where attention never reached:

  • latent_condition_register — the diff is an enumerated register of the inherited and drifted configuration conditions carried in with the substrate.
  • attention_gap_indicator — every "differs, and no one here chose it" line is a measured attention gap: a setting live in production that escaped review.

It does not establish where those inherited settings came from — provenance is Base Image Provenance Attestation's job — nor decide what to do about each deviation; the access-related ones go to Inherited Permission Review, and remediation to mechanisms like Clean-Room Rebuild or Replatforming Pilot.

Notes

A diff is only as trustworthy as its baseline — and baselines get inherited too. A repository of "golden" configurations can carry exactly the unowned-provenance problem this archetype exists to catch, so the baseline itself deserves the same lineage scrutiny as the system it judges. A diff against a compromised standard can quietly certify the wrong thing.

References

[1] Configuration drift is the gradual divergence of a running configuration from its intended baseline as ad-hoc changes accumulate. A diff detects the divergence but cannot by itself say which side is correct — that judgment lives entirely in the authority of the baseline, which is why an unjustified baseline turns the tool into a noise generator. ↩