Skip to main content

vulkro-sf why-not

Explain why the scanner did not report a finding at a given file and line.

Command reference​

Generated from vulkro-sf why-not --help (vulkro-sf 0.28.0). Run scripts/gen-docs.sh in the product repository to refresh it; do not edit this section by hand.

Explain why the scanner did not report a finding at a given file and line.

vulkro-sf why-not [OPTIONS] <TARGET>

Arguments​

ArgumentDescription
<TARGET>Target as <path[:line]>. path is a .cls file (or a project path); the optional :line narrows the analysis to the method that owns that line.

Options​

FlagDescription
-f, --format <FORMAT>Output format: table (default) or json. Default: table.
-v, --verbose...Bump stderr log verbosity. -v enables debug-level tracing for the vulkro + vulkro_sf targets; -vv enables trace. Honoured only when RUST_LOG is unset (an explicit RUST_LOG always wins)
-q, --quietPrint only warnings and errors on stderr: no progress, tips or next-step hints. Results on stdout and exit codes are unchanged.
--no-colorTurn off coloured output. Colour is also off when NO_COLOR is set to a non-empty value or TERM=dumb.
-h, --helpPrint help (see a summary with '-h')
Full vulkro-sf why-not --help
Explain why the scanner did not report a finding at a given file and line.

Explain why the scanner did NOT report an Apex taint finding at a location: `vulkro-sf why-not <path[:line]>`.

This is the "ask why the scanner stayed silent" primitive. It runs the deterministic scan as an oracle: if a finding WAS reported at the location, it prints that finding (the honest answer is "it did"). If not, and the location is a recognised SOQL / DML / callout sink inside an entry-point method, it reports the concrete gate(s) that would have suppressed a taint finding, drawn from the SAME gates the detectors use: no attacker-controlled source; a sanitiser (`String.escapeSingleQuotes`, `Id.valueOf`, a bind variable, `Security.stripInaccessible`); a `WITH SECURITY_ENFORCED` / `WITH USER_MODE` runtime downgrade; a `@AuraEnabled(cacheable=true)` getter; guest-exposure absent; or the cross-method hop bound (`MAX_TAINT_DEPTH`).

This is a BEST-EFFORT explainer: it does not re-run the full taint lattice in a candidate-emitting mode, and it says so in its output. It reports the gate reasons it can determine and no more.

Exit codes: 0 = clean / answered (no reported finding and no near-miss sink to suppress at the location); 1 = a reported finding or a near-miss with a suppression reason was shown; 2 = error (bad target, unreadable file, unscannable project, unknown --format).

Usage: vulkro-sf why-not [OPTIONS] <TARGET>

Arguments:
  <TARGET>
          Target as `<path[:line]>`. `path` is a `.cls` file (or a project path); the optional `:line` narrows the analysis to the method that owns that line

Options:
  -f, --format <FORMAT>
          Output format: table (default) or json
          
          [default: table]

  -v, --verbose...
          Bump stderr log verbosity. `-v` enables debug-level tracing for the `vulkro` + `vulkro_sf` targets; `-vv` enables trace. Honoured only when `RUST_LOG` is unset (an explicit `RUST_LOG` always wins)

  -q, --quiet
          Print only warnings and errors on stderr: no progress, tips or next-step hints. Results on stdout and exit codes are unchanged

      --no-color
          Turn off coloured output. Colour is also off when NO_COLOR is set to a non-empty value or TERM=dumb

  -h, --help
          Print help (see a summary with '-h')
Last updated on