Red-team challenge: make an honest scan claim a skill that isn't there

[jpbelmo]

Standing challenge: make redential scan claim a capability that the scanned repo does not actually demonstrate, and tell us how you did it.

The README says the contribution we want most is red-teaming the signals. This issue is the concrete place to do it. Fair game includes: crafting diffs that trigger Tier 2 patterns without real usage, exploiting import-extractor normalization to smuggle a package name, abusing the structural tier's anchor/inference rules, or anything else that produces a misleading detected_skills entry from an honest local run. (Forging the whole bundle by hand is out of scope: local evidence is declared forgeable by design and labeled Attested for exactly that reason. The interesting attacks are the ones that make an HONEST scan lie.)

How to report

Comment here or open an issue referencing this one, with: the minimal repro (a diff or tiny repo recipe), what the scan claimed, and why that claim is misleading. If it's a pattern-tightening fix, a PR with the fix plus the repro as a permanent negative fixture is the gold standard (see the companion negative-fixture issue).

Found something that leaks data rather than just mislabeling a skill? That's a security issue: follow SECURITY.md instead of posting it publicly.

[rudi193-cmd]

Taking this on from the Willow / orchestrator seat — same bench that weighed in on #13.

Plan: hunt for honest-scan lies (not bundle forgery) — starting with Tier 1 import normalization smuggling and Tier 2 pattern near-misses, then structural anchor/inference if those don't bite. Will report back here with a minimal repro (diff or tiny repo recipe), what detected_skills claimed, and why it's misleading. If we find a tighten-able pattern, we'll pair the report with a negative fixture per #27.

Will post findings in-thread before opening any PR.

[rudi193-cmd]

Fix: #30 — sanitizeForPatternMatching() shared into Tier 2; negative fixtures per #27.

---

Finding: Tier 2 apiPatterns fire on line comments (honest scan lie)

Attack class: Tier 2 near-miss — not bundle forgery.

Minimal repro (single added line in a .ts file, no Supabase dependency):

// rejected: supabase.from("legacy_profiles") — we query Postgres directly instead

What scan claims: db/supabase (via apiPatterns supabase\.from\()

Why misleading: The line is a deprecation/rejection note. No import, no client, no query — but matches() in skill-detect.ts ran Tier 2 regexes on raw added lines without the comment/block stripping Tier 1 already applies (import-detect.ts).

Same shape hits ai/whisper via ["']whisper-1["'] in a // evaluated model "whisper-1" … comment.

Fix: #30 — sanitizeForPatternMatching() shared into Tier 2; negative fixtures per #27.

Residual (not fixed here):* API-shaped text inside string literals (e.g. const doc = "no supabase.from()";) still matches Tier 2 regex — Tier 1 has isInsideStringLiteral; Tier 2 does not yet. Separate tighten if you want parity.

[jpbelmo]

Reopening: this is a standing challenge, not a one-shot task. PR #30 fixed the first finding (comment-based false positives); the hunt itself stays open. Current known residual: Tier 2 apiPatterns still match API-shaped text inside string literals, by design tension (they need quoted content), documented in docs/signatures.md.