Keycloak scanner triage: results, a worked example, and limitations

We ran ICTX over Opengrep OSS output from Keycloak on Sep 2, 2026. The input was SARIF from the scanner. This post explains the sample, the evidence behind the decisions, and the limits of the run.

Limits of the sample

• The scanner reported partial success. The finding set below is scoped to what the scanner emitted, not to a complete scan of the repository.
• 218 parse warnings. Parse failures can hide real paths. Treat every result as conditional on the coverage recorded here.
• Java and Python are indexed; JavaScript and TypeScript are not indexed. Findings in unindexed languages did not receive the same deep evidence.
• The sample is not a dataflow benchmark. The run includes a concentration of workflow, CI, and supply-chain finding classes. The result does not establish dataflow accuracy for application code.

The numbers

454 findings were scanned and 439 investigations were completed in 69 seconds in this sample. 427 findings remained in the output. Agent investigations: 0.

RUN     keycloak/keycloak
SCANNER Opengrep OSS          DATE  Sep 2, 2026
INPUT   454 scanned → 427 after output collapse
WORK    439 investigations / 69s / 0 agent investigations

  likely noise       179   41.9%
  needs review       114   26.7%
  policy queue       103   24.1%
  priority review     16   3.7%
  routed out          15   3.5%
                      ---
                      427

Five queues, five next actions

The output keeps different next actions separate. The percentages use 427 output findings as the denominator.

• Likely noise: 179 (41.9%). Decisive evidence supports closing these findings as likely noise, with the signal stated.
• Needs review: 114 (26.7%). The evidence supports a concern that a reviewer should confirm.
• Policy queue: 103 (24.1%). CI and supply-chain findings stay separate because their owners decide them against a policy.
• Priority review: 16 (3.7%). This is a separate high-confidence review bucket, not part of the 114 promoted findings.
• Routed out: 15 (3.5%). These findings are outside the repository scope. They are not resolved by being routed.

One worked example: why open

The selected finding stayed open because the available evidence did not establish a decisive close signal. Lens records the missing question rather than treating uncertainty as safety.

FINDING  workflow secret reaches a run step
  .github/workflows/*.yml

EVIDENCE
  source        workflow_dispatch input: inputs.admin-password
  path          input → env → run: step (shell interpolation)
  guard         none found in this workflow file
  indexed       yaml + java + python; javascript / typescript not indexed

WHY OPEN
  confirm callers constrain inputs.admin-password, or pass it through
  an environment variable with strict quoting and validation.

Exploitability also depends on repository and organization settings that are not in the checkout. This sample does not claim a confirmed vulnerability. It states the proof obligation for the next reviewer.

What the sample does not prove

• A close is a statement about a scanner finding, not about the safety of the repository.
• 41.9% is the share of this sample's output findings classified as likely noise. It is not an accuracy score or confirmed risk reduction.
• 0 agent investigations describes this sample. It does not establish what every future input will require.

Inspect the workflow

The run summary is on the home page. The screenshots and the two tool steps are on how it works. The directory lists other summaries with their limits. The published summary does not include a complete source-artifact bundle for every verdict, so this sample does not support an exact reproducibility claim.

The useful question is simple: can a reviewer check the evidence and answer the stated gap? That is the first product we are building.