Crossfire¶
Nothing here is implemented. No X-series rule exists in the shipped
ruleset, none is emitted by any code path, and RuleCategory.CROSSFIRE is
the one member whose implemented property is false. This page exists so
the category has a definition and the identifier range has an owner, not
because there is behaviour to document.
See the rule system reference for the field table, the severity weights and the reserved identifier ranges.
What a crossfire rule would claim¶
Every rule TrustSight ships compares a package against one of three things: itself before the diff (the C-series, the Class B and Class C rules), a pattern (the R-series), or the corpus in aggregate (the Class D rules).
A crossfire rule would compare two packages against each other. Not against the corpus mean, which is what corpus behavioral already does, but pairwise: two packages that changed in the same cycle, sharing evidence neither one's own history would make remarkable.
The distinction matters because the corpus rules are cluster-shaped by construction. R100 fires when at least three otherwise unrelated packages share a source repository; R092 fires when one maintainer submits ten packages in a week. Both need a quorum. A pair does not reach one, and a coordinated campaign starts as a pair.
Why the range is reserved and empty¶
X001 to X008 are held for this category. No individual identifier is
assigned, and none should be until the detection it names has been
specified and measured, for the same reason
R015 and R026-R038 are held apart: an id that
appears in a release is an id that appears in user baselines and
overrides.json entries, and reassigning it later silently changes what a
stored suppression means.
Two gates apply before anything lands here, both of which the existing Class D rules already have to pass:
fire_rate(no_baseline) == 0. A pairwise rule with no prior snapshot has every package looking novel against every other, which is the cold-start failure R071 is gated against.- Under 0.30 on the benign corpus, enforced by
scripts/calibration_gates.pyon every push. Pairwise comparison over 3,246 diffs generates a large candidate space, and a rule that fires on a measurable share of it is a census on active maintainers rather than a detection.
What to read instead¶
Until this category has rules, the nearest shipped signals are:
| Question | Rule |
|---|---|
| Do unrelated packages share a source repository? | R100 |
| Did one maintainer submit many packages at once? | R092 |
| Did one maintainer modify many packages at once? | R105 |
| Was a package adopted and then immediately changed? | R126 |
| Did several kill-chain stages co-occur on one package? | R089 |
The limit these share is described in what TrustSight cannot see: each needs either a quorum or a prior observation, so the first package of a campaign is the one they are least able to speak about.