Blog
Security decisions, and what changes them.
We're starting with scanner triage. Here we explain the evidence behind today's decisions and explore what it would take to keep those decisions useful as software changes.
Start here
8 postsWhat happens to a security decision after the code changes?
Our next question after scanner triage: how to preserve the reasoning behind a security decision and know when it needs another review.
Keycloak scanner triage: results, a worked example, and limitations
A Keycloak sample run: verdict counts, one finding explained, and the scan coverage and reproducibility gaps.
More from the team
ICTX and Semgrep Assistant: two approaches to scanner triage
What Semgrep documents about Assistant and what ICTX currently does with evidence, local execution, and narrower coverage.
Where Spring SAST findings go to die: sanitizers, config, and framework context
Three Spring finding patterns and the evidence needed to close each one: a validated binder, a config-gated sink, and a test-only path.
Deterministic triage: rules first, agent for ambiguous cases
How ICTX uses extracted evidence and deterministic rules, where an agent may help, and why coverage limits still matter.
Reachability analysis explained: what it proves, and what it can't
Sources, sinks, taint, and sanitizers in practitioner terms, plus partial indexing, dynamic dispatch, and framework limits.
What SARIF triage actually means (and why your scanner doesn't do it)
A working glossary: finding, triage, false positive, LFP, noise, decision record. The words your queue already runs on, defined so two engineers mean the same thing.
A verdict you cannot check needs more than a confidence score
Why a confidence score is not enough for the person responsible for a finding, and what evidence belongs beside the decision.