A clean result with missing coverage

Start with what was actually inspected

A detector reports on the input it processed. If a package contains a file it did not see, could not parse, or chose to skip, the verdict cannot silently cover that file. The useful first question is not only “what did the scanner find?” but “what did this run analyze?”

The omnicogg case file connects this question to a published package investigation. Historical findings belong to the reported tools and configuration; this guide does not claim that their current releases behave identically.

Make a coverage manifest

Synthetic comparison: zero findings is not zero uncertainty

Run A processes every supported file and reports no findings. Run B processes the entry file, skips the helper directory, and reports no findings. Both can display a zero. Their coverage records should lead to different review conclusions.

Compare the package inventory with the analysis input. Count errors and skipped files without pretending they are malicious by default. The point is to preserve uncertainty, not turn every processing problem into an attack verdict.

Decide how incomplete analysis affects use

For an unreviewed executable or influential resource, hold the workflow or remove the unsupported capability from scope. A manually reviewed exception needs an owner and evidence. If a large file is split for inspection, preserve its original identity and ordering; a convenient excerpt is not the whole artifact.

Keep the coverage record with the detector configuration, revision, and outcome. Later comparisons can then distinguish a change in detection from a change in what the tool managed to read.