Why does a "no secrets in plain environment variables" standard need rules at two decision points?

## One standard is not one rule A policy standard is a sentence in English: *secret material must not reach a workload as a plain environment variable.* A policy **rule** is an expression evaluated against a specific document. The moment you try to write the rule, you discover the standard does not map onto a single document. ## What the source-text rule can decide Run early — in the editor, in a pre-commit hook, on a pull request — and the document you are handed is the file as written. That rule finds: - a password or token typed literally as the value of an environment entry - the same thing in a script, a compose file or a deployment definition - credentials embedded in a command line This catch is worth having. It is close to free, it fires within seconds, and it lands on the person who typed the line while the intent is still in their head. It also stops the secret from entering version-control history, which is a separate and expensive problem. ## What it structurally cannot decide The rule's blindness is not a gap in its expression; it is a property of its input. A container can end up with a plaintext environment variable holding a secret through paths that leave no literal in the repository at all: - **A reference expanded by the platform.** The manifest names a secret and a key; the platform reads it and sets a plain environment variable in the container. The source shows a reference; the process shows the value. - **Pipeline injection.** The deploy job supplies the variable from its own secret store. That configuration lives in the pipeline, not in the application repository. - **Start-up injection.** An init container, a sidecar or an operator adds environment entries as the workload comes up, based on an annotation or a controller's own logic. - **A templating layer.** The value is substituted during rendering, so it exists only downstream of the file a scanner reads. Each of these produces exactly the condition the standard forbids, and a source-text rule reports clean on all of them. This is the single most important thing to be able to say out loud: **a green source scan does not prove no secret reaches the environment.** It proves no secret was written down in the place that was scanned. ## The second home So the standard gets a second rule, over a different document: the workload's resolved environment — the object as finally rendered, or the container as it actually runs. That rule does not care where the value came from. It asks a simpler question: does this workload's environment hold something that looks like secret material, or is it fed by a mechanism the standard forbids? Because its input is the end state, it catches all four paths above plus ones you have not thought of. Because its input is the end state, it is also **later** — the feedback is slower and reaches a different audience than the pre-commit rule does. ## Why this is not sloppy duplication An interviewer will push on the duplication, because keeping two rules in step is real maintenance. The defence has three parts. First, the two rules are not copies of each other. They are different expressions over different documents and they will never share an implementation — one matches string patterns in files, the other inspects a structured environment list. What you keep single is the **standard**: one sentence, one owner, one wording that both rules cite, so a developer blocked by either reads the same requirement. Second, the coverage is genuinely disjoint in both directions. The early rule catches a literal secret in a file that never gets deployed at all — the late rule never sees that workload. The late rule catches everything injected downstream. Neither is a subset of the other. Third, deleting the early rule to "avoid duplication" trades a second of feedback for days of it, and deleting the late rule trades completeness for tidiness. Both are bad trades, and both are made regularly. ## If you can only build one Build the late one. It observes the actual condition the standard is about, so it cannot be fooled by a path you did not anticipate. The early rule is an optimisation on top of it — an enormously valuable one for developer experience, but an optimisation. Say that in an interview and you will have answered the question behind the question.