Triaging Findings

​

The Review Workspace

This is where the work happens. The Review Workspace is built so a reviewer can go through a backlog quickly without losing the evidence trail. It’s arranged into three panels: what to review, the evidence, and the record.

​

Three Ways to Work

The toggle at the top switches how the backlog is organised. Use Components to clear volume, and drop to Files when you need to see a match in context. A Crypto family filter stays on when you switch between Findings and Components, so a dashboard lens isn’t silently dropped.

​

Reading the Evidence

The middle panel shows the actual matched source with the match percentage, 100% for a whole-file match, lower for a snippet. The match you have selected is washed in its family colour, green for open source, red for cryptography, so you work one match at a time; other matches in the same file keep a coloured rail in the gutter without washing the rest of the file. Hovering another match previews it only when that match doesn’t already cover the selection. When a file holds several matches, opening it selects the first one by line, and the toolbar list names each finding with a small family icon after the name. The right-hand panel identifies the component (name, vendor, package identifier) with its licence, known vulnerabilities, and how far behind the current release it is.

​

Cryptographic Findings

A cryptographic finding highlights the exact lines where the algorithm is used, in the same source panel, there’s no separate view to learn. A finding inside a dependency names that package; a finding in your own code that calls a known cryptography library names that library; plain standard-library usage carries no package. When a file holds several cryptographic findings, the toolbar list names each one by its algorithm, not the library package, since many algorithms can share one package. The right-hand evidence card names the algorithm and the facts the scanner reported for it (primitive, mode, padding, key size) instead of “Code match.” When the scanner didn’t name an algorithm, that card names the matched API or the asset type, never the internal rule id. When the finding also names a package, that same card adds the licence, known vulnerabilities, and how far behind the current release, the same groups OSS uses. The panel also adds a reachability pill and one line explaining it:

• Reachable means Earnie traced a call path from an entry point to that code.
• Not reached means it looked and found none.
• Unknown means the analysis couldn’t decide.

When there’s a path, View call trace opens the retained paths, entry point first. The first path is expanded and the rest are collapsed; Earnie keeps the shortest distinct paths rather than everything the scanner walked, and when it kept fewer than the scanner found, the sheet says so at the top, as in Truncated — 128 paths found, 20 shown. For new scans, every hop is a small excerpt of the real scanned source around the retained invocation line, syntax highlighted, and selecting the excerpt opens that file and line in the middle panel without changing the finding under review. The terminal card is the payoff: the highlighted crypto invocation and matched API sit beside statements built from the scanner’s persisted argument evidence, such as algorithm resolved statically to "SHA-256". A parameter without a proven value says not statically resolved. Hops whose archived source is no longer available say Archived source unavailable for this frame and remain readable as compact function-and-file rows instead of showing an empty excerpt. When the finding sits inside a dependency, its code lives in that package’s own source, which isn’t among your scanned files. Earnie shows the real file anyway when it resolved that package’s source during the scan, today Java projects built with Maven or Gradle, opened at the line where the algorithm is used, in the same source panel as your own code. Otherwise the panel shows the single matched line instead of the whole file, syntax-highlighted, with its real line number in the gutter. If even that is unavailable it says Code not available, rather than showing what looks like an empty file. The decision controls stay available in every case.

​

Where the Severity Comes From

Under the reachability line, the panel names which curated dataset judged this finding, for example Assessed under nist-2026-08. Severity is anchored to the scan that produced it, so the curation travels with the verdict instead of being implied by whatever ships today. When a newer curation has since replaced it, the line names both and carries a Retired curation marker: Assessed under nist-2026-08 — current is nist-2026-11. That’s provenance, never a severity, it names a dataset and never sits inside the severity pill. A retired verdict is still auditable, it was correct under the tables that produced it, and re-scanning brings the finding onto the current curation. How this severity is decided opens Settings → Crypto Assessment in a new tab, so a half-finished decision survives the detour. That page publishes what a curation actually says, rather than what it decided about one finding: the three curated risk tables, Algorithms, Protocols, and Key material, with each row’s base severity, the key-size variants that override it, the producer spellings that resolve onto it, and the document each row cites; the reachability escalation applied on top of a base severity; the post-quantum verdict per family; and the export-control thresholds. The page is read-only, these datasets ship with Earnie and aren’t editable. Every role can open it wherever Cryptography is enabled. Where the finding carries export-control evidence, an Export evidence block lists each cited regime test with the answer the dataset computed for it, Met, Not met, Unknown, or Not evaluated, the regime identity it was computed from (ear-2026-08), and the citation you can look up. It’s evidence only; no ECCN is stated or implied. Unknown means the test applies but the occurrence evidence can’t decide it; Not evaluated means the occurrence carries no evidence applicable to that test. After an export-regime update, rows computed under the superseded version are kept and marked Retired, sorted below the current ones, rather than deleted, an empty list would read as “nothing was ever measured.” The remedy is a re-scan, never a triage decision.

​

Making a Decision

Use Decide, and pick the answer that’s true: For a declared dependency the pair is Accept into SBOM or Dismiss. Earnie moves you to the next open finding automatically after each decision, and every decision offers Undo. A cryptographic finding has its own three decisions: All three close the finding and keep its row, so an accepted risk stays visible instead of quietly disappearing. The Decide menu states the gate effect on each verb before you choose. Whether the algorithm is reachable changes what you decide, never which decisions you’re offered.

​

How a Decision Moves the Dashboard

False Positive and Accepted Risk take the finding out of the Cryptography Dashboard’s reachable-and-weak headline, the post-quantum migration counts, and the algorithm ranking, those numbers answer what’s left to do, and a finding you’ve dispositioned isn’t left to do. It doesn’t vanish: the same cards report the decided population beside the headline, split by the verb that closed it, so a decision moves a number instead of deleting one. Every action is written to the finding’s Audit Trail: what was decided, by whom, when, and what the state was before. That record is what makes the decision defensible later.

​

Keyboard Shortcuts

Triage is the one screen worth learning the keys for. Press ? anywhere in the Review Workspace for the live list.

​

Finding States

In the workspace these collapse to three practical buckets: pending (needs you), identified (decided), and original (your own code).

​

What’s Next

With findings triaged, the next step is turning the judgement calls you keep repeating into a policy that applies itself.