About how findings are ordered
A scan of a real codebase turns up more findings than you will fix today, so the order they arrive
in is the first thing b8e tells you about what to do next. Two things decide it.
Severity first
Section titled “Severity first”The primary sort is severity: critical before serious, serious before moderate, and so on. Nothing overrides it. A serious finding on a component rendered by ninety files still sorts below a critical finding on a page nobody else touches, so you can always trust that the top of the list is the worst thing in your codebase.
Reach breaks ties
Section titled “Reach breaks ties”Among findings of the same severity, b8e puts the ones with the widest reach first — where reach
means how many files render the component the defect lives in, directly or through other components.
The reason is practical. A missing label on a shared <Button> that forty screens render is one edit
that clears the defect in forty places. The same missing label on a one-off page is one edit that
clears it once. Both are equally severe; one is a much better use of the next ten minutes.
Reach is context on a finding, not a score to drive down. In pretty output it appears on the file
header:
src/Button.tsx — rendered across 40 file(s)A file rendered by nothing else prints the bare header. Reach does not appear in json or sarif
output.
Why the order can differ between two machines
Section titled “Why the order can differ between two machines”Reach is only knowable when b8e can work out which components render which, which needs a
resolvable project — a tsconfig it can read and the files it points at. On a cold or shallow CI
clone, that often is not available.
When it is not, every finding has the same reach and the list falls back to severity order alone. You do not lose findings and nothing is skipped; equally-severe findings simply come back in a different order than on your laptop, because the tiebreak had nothing to work with. If you want the richer ordering in CI, make sure the checkout gives the scanner a resolvable project.
For how components are traced in the first place, see About components the scanner can and cannot see.