Tell us — that is the whole ask

In rough order of how much we want to hear about it

1. A false cleanA repository or sample snare says is fine and is not. This is the worst failure a scanner can have, and the one we most want reported.
2. An evasionA payload shaped so the heuristics miss it, or a way to hide from the guard, the hook or the shield. One such hole let any process hide from the guard simply by having the word snare in its command line.
3. A false positiveNoisy enough that people would learn to ignore the output. That is a real failure too — a scanner nobody reads protects nobody.
4. A variant we do not detectA different config file, a different execution route, a different obfuscation.
5. Anything destructiveA case where fix removes something it should not, or reports success without having done anything.

Open an issue. That is enough.

You do not need a fix, a pull request, or a polished write-up — a repository name, a file, or "this sample is not caught" is plenty. If you would rather not post details publicly, open an issue saying so without the specifics and we will find another way.

https://github.com/nexlabz/snare/issues/new

# helpful, if you have it:
snare selftest          # does detection still work on your machine?
snare version
bash --version          # macOS ships bash 3.2; several bugs were 3.2-specific

Known-good starting points if you want to poke at it: the heuristics live in lib/scan.sh, the process matching in lib/guard.sh, and the history rewriting in lib/fix.sh. snare selftest shows the shape of a test case; adding one that fails is a perfectly good bug report.

There is also an open discussion on the two questions we cannot answer ourselves: how this family actually reaches developer machines, and whether a defence can propagate the way the infection does without becoming a dropper itself. Join it here.