Topic starter
13/10/2026 1:21 pm
TL;DR: Lazy AI reachability is slow, expensive, and often wrong because models re-derive call graphs from raw source without type information or cross-file symbol resolution, according to Nullify. Its approach uses real language-server navigation as ground truth and reserves LLM judgment for genuinely ambiguous cases, cutting review effort and token spend.
Editorial analysis by NHI Mgmt Group, based on content published by Nullify: “Reachability Triage That Scales Without Headcount”.
Key questions
Q: What breaks when reachability triage depends on AI alone?
A: AI-only reachability breaks because a model reading source as text cannot reliably resolve type information, symbol binding, or cross-file call relationships.
Q: Why do unresolved language-server results need their own status?
A: Unresolved results need their own status because a timeout, unsupported language, or indexing race is not the same as proving a vulnerable function is unreachable.
Q: What do security teams get wrong about scanning code faster?
A: They often assume more scanning will close the gap created by faster development.
Practitioner guidance
- Adopt semantic reachability as the primary control Base reachability decisions on language-server call hierarchy, definition resolution, and first-party caller filtering rather than on repository text search or model-only reasoning.
- Separate unresolved from unreached outcomes Treat timeouts, unsupported languages, and indexing failures as unknown states so they cannot be misread as proof that a vulnerable function is safe.
- Record evidentiary method on every verdict Persist whether a result came from resolved symbol navigation, package-level inference, or AI judgment so analysts can review only the low-confidence cases.
Bottom line: Reachability triage fails when model output is treated as evidence instead of interpretation, because semantic resolution is what proves the call path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
13/10/2026 1:22 pm
Static resolution should be the default trust layer for code reachability. Reachability triage only scales when the system can prove what is called, not merely describe what might be called. That makes language-server semantics the control plane and AI the exception handler, which is the right division of labor for auditable security decisions. The practitioner conclusion is simple: if the verdict cannot be traced to resolved code paths, it is not ready for automated trust.
A question worth separating out:
Q: How should teams design an auditable reachability workflow?
A: They should design it so every verdict carries its evidence class, confidence level, and traceable caller data. That allows analysts to trust high-confidence semantic results, review only the uncertain cases, and reproduce the decision later. The workflow should be readable by humans first and automatable second, not the other way around.
👉 Read our full editorial: Reachability triage scales when static analysis leads AI judgment