fix: the scanner and sweep reported infected repos as clean, in seven different ways

[fabrizzio-dotCMS]

Everything in this repo fails toward "clean". Seven defects were found in a single day — four in the tooling, three introduced while fixing it — and every one reported an infected file or repository as CLEAN. None ever produced a false alarm. That asymmetry is what this PR is written against.

Folded #5 and #6 in here so this is one review, not four.

1. Four ways a poisoned repo was reported clean

• The sweep called rg with no fallback. Where rg is only a shell function — common; command -v rg succeeds in an interactive zsh and fails inside the script's bash — the command failed, $hits came back empty, and every repo printed "HEAD clean".
• Section 1c was silently dead on every host without ripgrep: the grep branch spelled the alternation as ${REGEX_PATS[0]}|…|${REGEX_PATS[3]} against a 3-element array, so under set -u the subshell died before grep ran and the section printed nothing.
• Two false positives were masking a real detection miss.
• The campaign tag is a build number and it has already rotated — 9-3727-2, A9-3727-2, A9-3727-3 across a four-file sample set. A literals-only rule would have missed the third. The marker is now the generalised A?#-####-# pattern, pinned by a test against a build we have never seen.

2. There is no CLEAN verdict any more

The sweep clones with --mirror, which fetches refs. An object reachable from no ref is never looked at, and GitHub keeps serving those objects by SHA long after a squash orphans them. Four payload blobs were retrieved that way from repos this sweep had called CLEAN — ovh-k8s-cluster and support among them, the latter confirmed to be the whole variant C implant.

The scan was not wrong. The word was.

RESULT <repo> INFECTED|NO_REF_HITS|UNKNOWN <hits>

Every non-abort exit path now prints what the run does not cover. --deep does not close the gap either — git rev-list --all still walks only what is reachable. Orphaned objects cannot be enumerated at all, so verifying them is a per-SHA check against the incident catalogue, not a scan.

The caveat is a function called from both the org path and --local. Written inline in the summary it left --local silently without it — the same failure in miniature, a partial result read as a total one. The test caught that, not review.

3. One source of truth for the rules

The rules lived in polinrider_scan.sh, org_sweep.sh, and a third hardcoded copy inside classify_config(). They had drifted: the sweep matched the tag as the literal A9-3727 long after the scanner generalised it, leaving it blind to variant A on every run it ever performed.

Not a flat list — the two tools have different false-positive surfaces and that difference was deliberate:

set	contents	scope
core	rmcej%otb%, wuqktam…	hard everywhere
repo-only	'Sec-V', helloipbot, AUTH_API_KEY, 9-3727-2	hard in a repo sweep
host-only	atob(process.env.AUTH_API_KEY	hard on a workstation

Flattening them would promote 'Sec-V' to a hard indicator on developer machines, where it appears as quoted text in Claude Code transcripts — a recorded FP class that would produce false COMPROMISED verdicts.

4. Neither script will run unless its rules still match malware

The sweep has had an engine self-test since the rg failure. The host scanner never did, and it is the half that runs on developer machines. Both now plant known-positive carrier bytes, run their real rules with their real flags, and abort rather than report anything clean if a rule does not fire. With negative controls: a clean file must not match, and the node_modules exclude must still apply — a rule that fires on everything detects nothing, and that failure is invisible without one.

canaries.sh is a separate file, and that is the whole mechanism. This went through two versions that were both false, and neither failed loudly:

1. Fixtures generated from ${SIGS[@]} — proves the rules match themselves; passes with every signature silently rewritten.
2. Real carrier bytes hardcoded in rules.sh — one find-and-replace rewrote a signature and the sample proving it worked in the same pass.

Evidence that moves whenever the claim moves is not evidence. Both defects were found by the sabotage test, which breaks one rule at a time in a throwaway copy and requires the scanner to refuse to run.

Also fixed: a sourced file that returns does not abort its caller, so a missing canaries.sh let the scan proceed with the canary silently evaporated. Both scripts check on their own side and exit 2.

5. CI

The repo had none. Its suites ran when someone remembered — in a repo whose own history includes a suite that had no assertions and passed for weeks while testing nothing. Suites are discovered, not listed, so a new one cannot be silently skipped. Both engines run, because the grep/ripgrep difference has hidden a real detection failure before.

Validation

Every rule here is checked against four byte-exact carriers supplied by the IR lead on 2026-08-27 (SHA256-verified, held outside any repo). The claims in the comments are measurements, not inferences from a write-up — including two corrections: the padding run is 507 bytes, not the ~5,000 the old comment claimed, and the payload starts at column 510 in two carriers and 536 in the third, so the rule anchors on the run length and never on a column.

Five suites, all passing.

Known gap, recorded rather than solved

rules.sh is the single source for bash consumers. The PR-check service cannot source a bash file. That needs a canonical format both can read, decided once we know what the service is written in. Do not close it by copying the strings — that recreates exactly the drift this PR removes.

[wezell]

Nice fixes