feat(analyzer): detect untrusted container image pull as SC7

[CharmingGroot]

Summary

The supply_chain analyzer (SC1–SC6) covers package dependencies (PyPI/npm) but has no detection for the container-image supply chain. A skill that pulls images with verification turned off — --disable-content-trust, DOCKER_CONTENT_TRUST=0, --insecure-registry — accepts tampered or unverified images yet scored 9/100 SAFE (#223). This adds SC7, the image-layer counterpart of SC1 (unpinned) / SC6 (typosquatting).

Changes

static_patterns_supply_chain.py gains SC7_PATTERNS (three image-trust bypass flags) and an SC7 pass filtered through the shared is_code_example() helper. pattern_defaults.py registers the SC7 explanation, category, message, and remediation alongside SC1–SC6.

Before / After

A "fast image loader" skill that sets DOCKER_CONTENT_TRUST=0 and pulls with --disable-content-trust / --insecure-registry:

• Before: 9/100 SAFE — only the unrelated --tls-verify=false line is caught (as a generic TM3 verify=False); the image-trust bypass is invisible
• After: 57/100 HIGH, SC7 ×3 on the content-trust and insecure-registry lines

With the LLM layer (Qwen3.6-35B-A3B-FP8 via vLLM) the same skill scores 78/HIGH (SDI-1: "disables Docker Content Trust, TLS verification …"), so --no-llm / air-gapped deployments were the exposed surface this closes.

Design Decisions

Decision	Rationale
Category = supply_chain (not new)	A container image is a supply-chain artifact; SC7 is the image-layer version of SC1/SC6. No new category needed.
--tls-verify=false excluded	TM3's existing verify=False pattern already catches it. SC7 targets only the image-specific bypasses TM3 cannot see (--disable-content-trust, DOCKER_CONTENT_TRUST=0, --insecure-registry) — avoids duplicate findings on the same line.
Severity HIGH, confidence 0.8–0.85	Disabling verification is dangerous regardless of registry. A normal docker pull nginx:1.25 does not fire.

Testing

5 new tests: detection of --disable-content-trust, DOCKER_CONTENT_TRUST=0, and --insecure-registry; a documentation-example exclusion (is_code_example); and a benign-pull negative. make format and make lint pass; uv run pytest -m "not integration and not provider" reports 1003 passed, 0 failed.

Closes #223

[rng1995]

The SC7 patterns and metadata are otherwise well integrated, but the new module-level example filter lets executable code evade the rule with a nearby marker. Please rely on the runner's file-type-aware handling, or only suppress non-executable content, and add an executable-file evasion regression.

[rng1995]

Blocking: this unconditional skip creates an attacker-controlled bypass in executable files. is_code_example() returns true for any nearby 'for example', code fence, and similar marker, so a shell script with '# for example' within three lines of 'docker pull --disable-content-trust ...' produces no SC7 finding. The shared runner already filters examples in non-executable docs and only downweights them in executable files. Remove or scope this early continue and add an executable evasion regression.

[CharmingGroot]

Good catch — my mistake. The runner already applies is_code_example (filtering non-executable docs and only downweighting executables), so calling it again in the SC7 loop with an unconditional continue is redundant and opens exactly the executable-file bypass you flagged: a # for example within a few lines of docker pull --disable-content-trust suppresses the finding entirely.

Fix incoming: drop the is_code_example call from SC7 and rely on the runner's file-type-aware handling, plus a regression test asserting a content-trust bypass in a .sh still fires with an example marker nearby.