Skip to content

Template or Policy Origin Audit

Origin audit — instantiates Substrate Lineage Risk Audit

Traces an inherited template, policy, or config back to its origin and tests whether the assumptions its author baked in still hold in the context now using it.

Not all inherited substrate is code. Teams also inherit infrastructure templates, policy documents, IAM and access rulesets, config baselines, role models, and operating routines — artifacts copied from a quickstart, a predecessor, or a sister team and then quietly promoted to load-bearing. A Template or Policy Origin Audit reconstructs the conditions under which such an artifact was authored — the scale, threat model, trust assumptions, and defaults its creator took for granted — and then probes whether those conditions still hold where it is being used now. Its defining move is auditing fit to context rather than presence or vulnerability: the risk it hunts is a permissive default or a convenient assumption that made sense there and then and is silently dangerous here and now. It judges whether inherited assumptions survived the move.

Example

An IAM policy template was copied from a cloud vendor's "get started fast" tutorial two years ago and is now attached to production service roles. The origin audit reconstructs its origin conditions: written as an example for a single developer in a sandbox account, no separation of duties assumed, generous defaults chosen deliberately so the tutorial would "just work." Then it probes the current context — multi-team production, real customer data, a compliance scope that did not exist for a tutorial.

The mismatch jumps out: a wildcard Action: "*" grant that was a reasonable convenience in a throwaway sandbox is now sweeping over-privilege on roles that touch production.[1] The audit does not scan for a vulnerability — there is no CVE here — and it does not read the template's custody trail. It asks the one question the copy-paste never did: does the assumption the original author made still fit the place this is running? Here, plainly, it does not.

How it works

  • Reconstruct the origin conditions. Recover — from documentation, comments, or inference — what the author assumed: intended scale, trust model, threat model, and which values were deliberate versus default-for-convenience.
  • Model the current context. Characterize where the artifact runs now: who touches it, what it governs, what the real exposure and compliance surface are.
  • Probe the context shift. Compare origin assumptions against the current context, assumption by assumption, and flag each one that no longer holds.
  • Treat defaults as unreviewed. Presume any inherited default is unfit until shown to fit; a value nobody chose for this context is a finding, not a baseline.

Tuning parameters

  • Assumption classes probed — privilege, scale, trust, compliance, defaults, network posture. Probing more classes catches more drift but lengthens the audit.
  • Origin-evidence depth — how hard to work to recover the original intent (documentation only, versus interviewing predecessors or reading the source tutorial). Deeper recovery sharpens the probe but costs time.
  • Context-model fidelity — how precisely the current environment is characterized. A richer model finds subtler mismatches; a coarse one catches only the glaring ones.
  • Default-strictness — how aggressively to treat an unreviewed default as a defect. Strict settings surface silent over-permission; lenient ones reduce noise but let convenient defaults survive.

When it helps, and when it misleads

Its strength is catching the entire class of inherited risk that no vulnerability scanner can see: permissive examples promoted to production, copy-paste boilerplate, policies that outlived the context they were written for. This is where "trusted background" is most dangerous, because there is no CVE to trip an alarm — only an assumption that stopped being true.

Its failure modes come from the softness of the target. Origin assumptions are usually undocumented and must be inferred, so the audit can misread intent. "Does it still fit?" is a judgment, and a motivated reviewer can rationalize a convenient default as acceptable — the audit run to bless the status quo rather than test it is the classic misuse. And an artifact that fit the context at audit time can be drifted out of fit by a later change of context, not of content. The discipline is to make default equals unreviewed the standing rule, hold each inherited assumption to an explicit yardstick such as least privilege rather than to reviewer comfort, and re-run the probe when the deployment context — not just the template — changes.

How it implements the components

This audit fills the assumption-fit side of the archetype's machinery — the components that interrogate inherited conditions, which a code-oriented scan never touches:

  • origin_condition_profile — it reconstructs the scale, trust model, threat model, and deliberate-versus-default choices the template's author built in.
  • compatibility_and_context_shift_probe — it tests those origin assumptions against the current deployment context and flags every one that no longer holds.

It does NOT record the template's custody trail — that's Provenance Chain-of-Custody Record — nor contain a bad inherited default it finds — that's Sandbox or Adapter Wrapper. This audit judges fit; its siblings trace provenance and contain.

References

[1] The principle of least privilege — a component should hold only the access its task strictly requires — was set out by Saltzer and Schroeder in 1975 and remains the standard yardstick for judging whether an inherited grant fits its context. It is used here as the criterion the probe measures a permissive default against, not as a citation for any specific finding. ↩