Add an extensible filtering mechanism for reporting

[bradlarsen]

Use case

You are reviewing a bunch of findings from Nosey Parker and want to focus on particular categories of findings, eliminate findings from certain files or repos, etc.

Existing limitations

At present, the only way to do this is to write some postprocessing script. This has a couple downsides:

• If you postprocess the human-readable text-based report, you have to do grungy parsing
• If you postprocess the machine-readable JSON report, you afterwards have to write your own logic to assemble that into a human-readable report from the filtered result
• Any postprocessing you do is strictly "post"; the filtered results cannot be fed back into Nosey Parker. (Example use case: you filter results and want the noseyparker summarize output only on the filtered results.)

Proposal

The report and summarize commands should have an additional --filter CMD option that behaves as follows:

• CMD is the name of a program that takes a JSON array of findings on stdin and emits a JSON array of findings on stdout
• If CMD returns a non-zero exit code, prints unintelligible output, or emits findings that did not appear in the original input, noseyparker exits with an error
• When --filter CMD is given to either the report or summarize commands, the filter program is run on Nosey Parker's findings as soon as they are loaded, but prior to downstream processing within noseyparker

[CameronLonsdale]

One example for this is a case where you might have a risk accepted secret (e.g. it's a token with minimal scopes), you could use the filtering program to remove the secret based on a literal or hash comparison of the secret

[CameronLonsdale]

Another useful category would be whether the finding is for a "secret" like an API key, or something more informational like an s3 bucket name (https://github.com/praetorian-inc/noseyparker/blob/main/crates/noseyparker/data/default/rules/aws.yml#L120-L121)

[munntjlx]

Indeed. I also second this. The 'postprocessing' would be much easier with this kind of logic, its essentially what I did when I created a 'json' file for skips etc.