Static analysis tools are very good at producing statements that look certain: a rule name, a severity, a line number, and a red icon. The underlying evidence is often less absolute.
A pattern may be security-relevant in one data flow and harmless in another. A dangerous sink may be protected by a validation step the rule did not model. A file may not have been analyzed at all because a run reached its limit.
Treating every result as a verdict creates busywork. Treating every result as noise wastes useful evidence. The productive middle is to present a finding as a claim that can be reviewed.
Preserve the Evidence Chain
A developer should be able to distinguish three layers:
- Signal — what matcher or analyzer observed in the source.
- Revalidation — whether a second, evidence-focused pass confirmed, rejected, or adjusted the interpretation.
- Normalized finding — the stable record presented for triage and lifecycle tracking.
Combining the layers into one rewritten explanation makes the result sound cleaner but removes accountability. Reviewers need to know which parts came from deterministic matching, which came from model-assisted reasoning, and which normalization rules changed severity or classification.
Rorix keeps the original signal and DeepSec revalidation outcome distinguishable before producing the customer-facing finding.
Coverage Changes the Meaning of “Clean”
A complete run with no findings and a partial run with no findings are not equivalent.
The result should include:
- eligible files discovered;
- files actually analyzed;
- skipped files and reasons;
- whether all waves completed;
- budget, timeout, cancellation, and runtime outcomes.
Only a fully completed baseline should become canonical. Only comparable complete coverage can support the conclusion that a previous finding disappeared.
Rorix's GitHub check is successful only for complete, clean coverage. Findings and every incomplete outcome remain neutral during the beta. Neutral does not mean irrelevant; it means the system refuses to turn uncertainty into an enforcement verdict.
Stable Identity Matters More Than a Stable Line Number
Line numbers move whenever developers add imports, comments, or unrelated functions. If a finding's identity includes its exact line, ordinary refactoring can make the same issue appear “fixed” and “new” in consecutive runs.
Use a fingerprint based on the security-relevant structure while excluding volatile location details. Keep the current source location as evidence, not identity.
Stable fingerprints enable useful lifecycle states:
- new — first observed;
- recurring — observed again in comparable code;
- resolved — absent after complete analysis;
- regressed — returned after resolution.
That history helps teams separate a persistent architectural issue from a newly introduced one.
Pull Requests Need a Different Analysis Shape
A full repository baseline and a pull-request check answer different questions. The baseline establishes the canonical state. The PR check asks how eligible changed files affect that state.
Rorix analyzes same-repository pull requests only after explicit opt-in and only against a completed baseline. It caps changed files, uses smaller waves and lower concurrency, skips unsupported and fork-based cases, and supersedes earlier work when a new head commit arrives.
These constraints keep feedback tied to the code under review and prevent stale results from winning a race against a newer commit.
Give Reviewers Better Questions
A useful finding should help the developer ask:
- What untrusted value enters this path?
- Which validation or authorization boundary is missing?
- What sink or sensitive operation can be reached?
- Does framework behavior mitigate the path?
- Is the evidence tied to the exact commit under review?
- What small code change would disprove or remove the claim?
Confidence is helpful, but it should not replace these questions. A score without inspectable evidence is just another severity label.
Export the Reviewed Model
Normalized JSON and SARIF let findings move into existing engineering workflows. Exported results should carry stable identity, source location, severity, description, and remediation without exposing raw prompts or retained source state.
The Code Analysis documentation explains how Rorix creates baselines, analyzes pull requests, reconciles finding lifecycles, and handles incomplete outcomes.
The goal of analysis is not to maximize the number of warnings. It is to make each claim cheap enough to evaluate, specific enough to fix, and honest enough to trust.