security(ci): two pre-existing false positives block legitimate steps in the Kubescape guard #3585

🤖 Generated by the Agentic Engineer

Two false positives on the UNCONDITIONAL path

Both block legitimate workflow steps, and both are pre-existing — the two functions involved are byte-identical between main and #3546, verified by extracting each and diffing. They surfaced during review of that PR but are not caused by it.

1. A standalone scan token beside any expansion — undecidableScanCandidate

- run: echo scan "$STATUS"

The literal echo cannot invoke KSail, but a bare scan word plus an expanding argument is treated as a possible invocation, and the guard fails. Adding this diagnostic line to either validated workflow breaks it. Unrelated tools with a scan subcommand and a variable argument are blocked the same way.

The rule needs the scan evidence scoped to an actual candidate — a command position that could be ksail — rather than to any scan token anywhere on the line.

2. A statically quoted option value — spelled

- run: ksail workload scan --framework="nsa,mitre" -o kubescape.sarif

Valid shell, and it produces exactly the same --framework=nsa,mitre argument as the accepted unquoted spelling. The quoting is deterministic — there is no runtime expansion — but it routes to the constructed-option refusal and blocks both workflows.

The rule needs to distinguish deterministic quoting, which resolves at parse time, from a genuinely constructed option word.

Why these are filed rather than fixed in #3546

That PR closes thirteen bypasses in the conditional screen. These are false positives in two untouched functions on the unconditional path, so fixing them there would mix an unrelated correction into a diff that is already large, against this repository's one-concern rule — and neither is a regression it introduced.

Both are worth fixing: a guard that blocks a legitimate echo diagnostic or a normal quoting style is a DevEx tax that trains people to route around it.

Acceptance criteria:

• Both reproductions above are ACCEPTED, with the framework set still read correctly from the real invocation.
• The existing refusals for genuinely constructed option words and genuinely undecidable candidates still fire — each with a control, since "accept more" would otherwise pass by accepting everything.