v0.4.10: keep SARIF pass outcomes out of vulnerability gates — feedback wanted

[CAOShurong]

VulnFuse v0.4.10 is available: https://github.com/CAOShurong/vulnfuse/releases/tag/v0.4.10

This release fixes a concrete SARIF interoperability problem: results[] can contain rule outcomes, not only vulnerabilities. VulnFuse previously counted every result as active. On Microsoft BinSkim's pinned gcc.fortified.sarif fixture, five valid kind: pass, level: none records were therefore mixed into the active queue alongside two failures.

v0.4.10 now keeps three explicit dispositions:

• active findings;
• effectively suppressed findings;
• non-finding evidence (pass, informational, or notApplicable).

A cluster becomes non-finding only when every member is valid non-finding evidence. Missing kind still defaults to fail; open and review remain active. Unknown, non-string, or contradictory kind/level values warn and remain active, and an active corroborating record always wins.

GitHub code scanning does not document result.kind in its supported SARIF subset. To avoid turning pass outcomes into hosted alerts, VulnFuse omits non-finding clusters from exported results[] but retains their complete audit records in run.properties.nonFindingClusters (or nonFindingItems for baseline exports).

Observed checks before release:

• the public BinSkim fixture is reported as 2 active + 5 non-finding;
• the full fixture still fails a critical gate, while the pass-only subset exits 0 under an info gate;
• a historical public contradictory kind/level fixture remains active and emits warnings;
• core, CLI, bundled Action, fresh release install, desktop/mobile browser flows, SBOM contents, and public release downloads were exercised;
• all PR, main, Pages, CodeQL, and release workflows completed successfully.

Important limit: VulnFuse trusts the producer's result.kind. It does not rerun a rule, prove a check passed, or establish that a rule was applicable. Protect report inputs and retain scanner execution logs for consequential decisions.

Feedback wanted: if a real scanner emits result.kind in a shape that v0.4.10 classifies incorrectly, please open a sanitized format issue and include the producer/version, the smallest safe SARIF fragment, the expected disposition, and whether the report targets GitHub code scanning or another consumer: https://github.com/CAOShurong/vulnfuse/issues/new?template=format.yml