A Rego advisory rule warns 'TLS policy is not approved' with no resource name — how do you find which listeners matched?

## The situation An advisory rule is running in warn mode over a CloudFormation template. It emits a single unadorned string — `TLS policy is not approved` — once per matching resource. The template has a dozen listeners. Nobody can act on the output: it does not say which listener, and it does not say what the rule saw. Somebody has to reproduce the result and explain which expressions did and did not evaluate. ## Step 1: get the same input A reproduction that uses a different document proves nothing. Take the template the job evaluated, as it was evaluated — the same file, the same rendering step ahead of it if there was one. Then run the rule directly: ``` opa eval -i template.json -d policy.rego --format=pretty 'data.cfn.tls.warn' ``` Query the specific rule, not the whole package: a package-wide query drags every other rule's evaluation into anything you trace afterwards. If the local run does not reproduce the warning, stop and fix that first. The likely causes are a different input shape (a template rendered by another step, or JSON versus YAML) or different data loaded alongside it. ## Step 2: make the rule say what it sees The rule's message tells you nothing, so make the body tell you instead. Put a `print` immediately above the expression you suspect, dumping both the identifier and the value being read: ``` print("listener:", name, "policy:", res.Properties.SslPolicy) ``` Read it with `--explain=notes`, which filters the trace down to exactly those messages. You now have one line per resource the body reached, in evaluation order. This is where most of these end: the printed value is `<undefined>` because the field lives somewhere other than where the author assumed, or it is a string whose form the comparison never matches — a named security policy such as `ELBSecurityPolicy-TLS13-1-2-2021-06` rather than a bare version number. Note what the `<undefined>` case means for an advisory rule written with a negation. If the body says *not approved* and the value it checks is missing, the inner check is undefined, the negation succeeds, and every listener warns — including the ones that are perfectly configured. An advisory rule that fires on everything is worse than one that fires on nothing, because it trains the team to skim past it. ## Step 3: narrow until the behaviour is isolated For the resources you expected to match but that produced nothing, switch to `--explain=fails`, which shows the expressions that did not hold. On the whole template that output is unreadable, and not because anything is wrong: a body that iterates over resources fails on every resource it does not match, which is how filtering works. So cut the template down — one listener, the properties the rule touches, nothing else — and re-run. The trace collapses to a handful of lines and the answer is usually visible at a glance: either the expression you suspected failed, or evaluation never reached it, which relocates the problem earlier in the body. Work by bisection if the minimal case still misbehaves: remove properties until the behaviour flips, and the last thing you removed is implicated. ## Step 4: fix the thing that sent you here The missing field is the bug of the hour. The message is the bug of the year. An advisory finding that names no resource and quotes no value costs somebody this entire exercise every time it fires. Rewrite it to carry its own evidence: ``` msg := sprintf("listener %v uses TLS policy %v, which is not approved", [name, res.Properties.SslPolicy]) ``` Now the warning is self-contained: the developer who receives it can see which resource and what value, and can decide without opening a policy repository they have never read. ## Step 5: keep the fixture The narrowed template is the most valuable artefact of the session. Save it as a test case — the input, plus the expectation that the rule now produces the message with the right resource named — so the fix is pinned and the next change to the rule cannot silently reintroduce the same blind spot. ## A note on the hosted playground The browser playground is excellent for sharing a reduced reproduction with a colleague or with someone on another team who does not have OPA installed: a link, a rule, a fixture, evaluated in front of both of you. It is not the place to paste a real infrastructure template. By the time you have narrowed the input to a handful of lines you can usually anonymise it trivially — replace identifiers, keep the shape — and share that instead.