OWASP/cve-lite-cli

The multi-folder output still spells out two of the gate-class labels, so renaming a class through the shared constant would leave them behind. Context #1274 put the three --fail-on gate-class labels into one shared constant, GATE_CLASS_LABELS in src/utils/severity.ts, and both failingGateSummary call sites now read from it. That shipped in #1288 and did what it set out to do: changing a label in the one place it lives fails exactly one test, where the same change on main used to pass the whole suite. What is left Two subfolder section headers in src/scan/multi-folder-scan.ts print "override hygiene" and "maintenance risk" as string literals rather than reading the constant. #1274 counted those two when it observed that "override hygiene" appeared four times in the source, but its stated ask was scoped to the two call sites, so this is a gap in that issue rather than a miss in the PR that closed it. Why it is worth closing The point of the shared constant is that a gate class has one n

Flag-conflict errors print a corporate SSL proxy hint that has nothing to do with the problem. What happens Running a scan with two mutually exclusive flags prints the conflict, then advises installing a CA certificate: Error: --offline/--offline-db cannot be used with --osv-url. Choose offline mode (local DB) or online mode (custom OSV endpoint), not both. Hint: If your network uses a corporate SSL proxy, a CA certificate may be required. Run: cve-lite config set ca-cert /path/to/corporate-ca.crt The hint is correct advice for a TLS failure and meaningless here. Nothing was fetched, so nothing could have been intercepted. A user following it would configure a certificate and see the same error. Scope Confirmed on --offline with --osv-url. It was previously only noticed on --report with --json, so it is not specific to one pair. src/cli/validate.ts raises seven of these conflicts through a shared path, so the likely cause is that the hint is attached where the error is rendered rather

The --json payload records projectPath as an absolute path, so a scan run on a developer's machine embeds their home directory in a file that gets attached to CI runs and emailed around. What it looks like A scan of examples/direct-fixable from a scratch directory emits a top-level projectPath holding the full absolute path, including /Users/<name>/. Nothing else in the payload is needed to reproduce it: every --json run carries the field. Why this is worth fixing #1271 fixed exactly this class of problem for the HTML report, and the reasoning there applies here with more force. That change stopped embedding a path computed against the working directory, on the grounds that it keeps the generating machine's home directory out of an artefact that gets attached to CI runs and shared. The --json payload is shared more often than the HTML report, not less. It is the file an adopter sends when something looks wrong, which is the exact scenario #1296 was filed about and the reason that issue

The scan JSON does not carry chainResolution, so the artefact cannot explain why a finding received the fix command it did. Finding.chainResolution holds the verified parent-upgrade chain: which direct dependency to move, from which version to which, the hops that were checked, and the safe version that results. It is one of the three remediation shapes a transitive finding can carry, and the only one absent from the serialized output. recommendedNpmTransitiveRemediation and recommendedParentUpgrade are both there. Why it matters A scan JSON is what an adopter attaches when something looks wrong, and what we read when diagnosing. Without this field a reader cannot tell a finding whose chain was resolved from one that had no remediation at all, because both look identical: a parent is named, a fix version is known, and nothing explains the connection between them. That is not hypothetical. Diagnosing #1311 from an adopter's artefact took three wrong turns because of it. One of them was

--debug already exists and writes a log, but it does not carry enough to diagnose a report without access to the reporter's machine. Diagnosing a recent dependency-attribution report meant building a custom instrumented package, sending it to the reporter and asking them to run it, which is not a process that scales or repeats. The goal: when someone reports surprising output, --debug should produce one artefact they can attach to an issue that is sufficient to diagnose it, and safe to attach in public. What it captures today On a two-package project the log has 31 lines. Most are network and cache activity. The rest are single summary lines: CLI version and args, config, the selected lockfile, a parsed package count, graph status, a workspace count, per-package fix validation, a findings-by-severity summary and total duration. What is missing Workspace members are counted but not named. The entry reads Workspace map {"type":"npm","workspaces":2}. Which packages those are is exactly wh