OWASP / OWASP/cve-lite-cli

fix(output): compact mode truncates findings and fix groups without saying so

Open
#1,151 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug good first issue help wanted
Dominant language
TypeScript
Stars
715
Forks
145
Avg merge
21h 39m
Merged PRs (30d)
66

Description

Compact output truncates in two places and announces neither.

1. Finding blocks, capped at three

src/output/finding-display.ts:16-19:

const urgentLimit = options?.urgentLimit ?? 3;
const urgent = findings
  .filter(finding => finding.severity === "critical" || finding.severity === "high")
  .slice(0, urgentLimit);

On examples/juice-shop that prints 3 finding blocks out of 54. The selection is
also narrower than a plain "top 3": only critical and high are eligible, plus every
unknown-severity direct finding, so medium and low findings never appear as blocks at
all no matter how many there are.

The footer on that same run reports "34 urgent issues found", so the output states a
number and then shows three, with nothing connecting the two.

2. Fix-command groups, capped at three

src/output/printers.ts:918:

for (const section of plan.sections.slice(0, 3)) {

On examples/juice-shop the plan has six sections. Compact prints three and silently drops:

Medium severity parent updates within range
Low severity validated chain upgrades
Low severity parent upgrades

The only hint is the generic footer at src/output/printers.ts:1039, "Run with --verbose for fix plan, paths, and full table." That reads as an offer of more detail about what you have already seen, not as notice that three command groups were withheld. Nothing in the output distinguishes "this is the whole plan" from "this is the first half of the plan".

It is worse in combination with the summary line above it, which reports the full finding count. A reader sees the true total, sees two or three command groups, and has no reason to think the two do not correspond.

The truncation itself is right. Sections are ordered by severity, so what gets cut is always the least urgent, and compact output should stay compact. The problem is only that the cut is undisclosed.

Suggested fix

Both caps need a line saying what was withheld.

For findings, after the last block when more were suppressed:

Showing 3 of 54 findings. Run --verbose --all to see them all.

For command groups, after the last shown section when plan.sections.length > 3:

3 more command groups (medium, low). Run --verbose to see them.

Derive the counts and severities from what was actually hidden rather than hardcoding
them, so the message stays honest when the mix differs.

Worth deciding at the same time

Whether three is still the right cap. It predates several section kinds being added (validated-chain-upgrade, parent-update), so a plan that once produced three sections can now produce six for the same project. The cap has not moved with it.

Found while checking compact-mode behaviour ahead of the Open Source Friday demo on 2026-09-18. Not a regression from v1.35.0; the cap has been there for some time.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with src/output/finding-display.ts:16-19 and src/output/printers.ts:918, then run compact output against examples/juice-shop to reproduce both undisclosed caps. Add notices that report the hidden finding count and command-group count or severities, using the actual truncated data; verify the output distinguishes withheld content from the complete compact result.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.