Summary
Users need to narrow large SARIF results down to the findings relevant to the task in front of them instead of reviewing the full output every time. This would make opentaint summary more useful for focused triage, automation, and AI-assisted remediation workflows while giving users a clearer, more controllable CLI experience.
Problem
opentaint summary works for reviewing a full report, but it is much less useful when users need a small, relevant subset of findings. Today, customers often need to inspect one severity, one rule, one path, or a concise grouped view, but the CLI does not support that workflow well.
This creates friction in several common situations:
- A developer wants to review only the findings relevant to the file or service they are fixing.
- A security engineer wants to focus on one rule or severity without scanning the full report.
- An AI agent needs a deterministic subset of findings for remediation or follow-up actions.
- An automation workflow needs concise grouped counts or a stable filtered view instead of a long detailed listing.
As a result, users and agents must either parse SARIF themselves or work through output that is broader than they need. This slows down triage, wastes context, and makes automation harder to trust.
Notes
Expected interaction model:
opentaint summary results.sarif --severity error --rule-id sql-injection-in-spring-app
opentaint summary results.sarif --path "src/main/**" --max-nesting-level 3 --show-code-snippets
opentaint summary results.sarif --group-by severity --count-only
opentaint summary results.sarif --group-by file-path --count-only
Expected options: repeatable filters (--path, --severity, --rule-id, --partial-fingerprint), output shaping (--max-nesting-level), aggregation (--group-by, --count-only). Must remain compatible with existing --show-findings, --verbose-flow, --show-code-snippets.
Filtering dimensions: file path (glob), severity/SARIF level, rule ID, partial fingerprint, code snippet presence, code flow nesting bound. Grouping dimensions: severity, rule ID, file path.
Existing behavior must remain unchanged when no filtering/aggregation flags are used. Document new options in docs/usage.md.
Summary
Users need to narrow large SARIF results down to the findings relevant to the task in front of them instead of reviewing the full output every time. This would make
opentaint summarymore useful for focused triage, automation, and AI-assisted remediation workflows while giving users a clearer, more controllable CLI experience.Problem
opentaint summaryworks for reviewing a full report, but it is much less useful when users need a small, relevant subset of findings. Today, customers often need to inspect one severity, one rule, one path, or a concise grouped view, but the CLI does not support that workflow well.This creates friction in several common situations:
As a result, users and agents must either parse SARIF themselves or work through output that is broader than they need. This slows down triage, wastes context, and makes automation harder to trust.
Notes
Expected interaction model:
opentaint summary results.sarif --severity error --rule-id sql-injection-in-spring-app opentaint summary results.sarif --path "src/main/**" --max-nesting-level 3 --show-code-snippets opentaint summary results.sarif --group-by severity --count-only opentaint summary results.sarif --group-by file-path --count-onlyExpected options: repeatable filters (
--path,--severity,--rule-id,--partial-fingerprint), output shaping (--max-nesting-level), aggregation (--group-by,--count-only). Must remain compatible with existing--show-findings,--verbose-flow,--show-code-snippets.Filtering dimensions: file path (glob), severity/SARIF level, rule ID, partial fingerprint, code snippet presence, code flow nesting bound. Grouping dimensions: severity, rule ID, file path.
Existing behavior must remain unchanged when no filtering/aggregation flags are used. Document new options in
docs/usage.md.