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.
At a glance
What this is: Nullify argues that reachability triage should be grounded in deterministic language-server analysis, with AI used only for ambiguous cases that static tooling cannot resolve.
Why it matters: This matters because security teams need verdicts they can inspect, defend, and automate without burning analyst time or trusting opaque model guesses.
Context
Reachability triage is a security governance problem as much as a tooling problem. Teams need to know whether a vulnerable function is actually callable from first-party code, but static analysis often gets diluted when vendors treat AI as a substitute for semantic resolution. In practice, the issue is not whether a model can describe code, but whether it can prove call paths with evidence.
The article’s core identity-security angle is indirect but real: the same control logic that governs trustworthy access decisions also applies to code and dependency reachability decisions. When a system cannot explain why a vulnerable symbol is reachable, the decision becomes hard to audit, hard to delegate, and hard to use in a disciplined triage workflow.
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. That produces expensive re-derivation on every query and can turn a confident guess into a false verdict. The safer pattern is to let deterministic semantic tooling establish the call graph and reserve AI for the cases where the code itself is genuinely ambiguous.
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. If teams collapse those states, tool failure becomes a false negative. A separate unknown state preserves auditability and forces human review only where the evidence is incomplete.
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. In practice, scan volume can increase while confidence falls if the programme cannot prioritise exploitable findings, control release gates, and reduce risk before deployment.
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.
Technical breakdown
Why source text alone cannot prove call reachability
A model reading repository text as plain strings cannot see the semantic structures that determine whether a vulnerable function is actually invoked. It lacks type information, cross-file symbol resolution, and reliable binding between a call site and the correct definition when names overlap across app code, libraries, and dependencies. That makes it useful for judgment in ambiguous cases, but unreliable as the primary source of truth. Deterministic analysis is still required to establish whether the relevant symbol is imported, resolved, and called in the first place.
Practical implication: Use deterministic code navigation to establish the call graph before asking AI to interpret any residual ambiguity.
How language servers establish ground truth for reachability
Language Server Protocol tooling performs semantic resolution that goes beyond search or syntax parsing. Functions such as go-to-definition, find references, and call hierarchy allow a triage system to resolve which symbol is being called, where it is defined, and whether the call originates in first-party code. This matters because the same function name can exist in application code, third-party libraries, or generated files. A language-aware resolver can separate those cases precisely, while a generic parser cannot reliably do so at scale.
Practical implication: Anchor reachability verdicts in language-server resolution and reject any workflow that treats plain text matches as equivalent evidence.
Why confidence ladders matter in triage automation
Reachability analysis must distinguish between a negative result and an unresolved result. If a language server times out, lacks call-hierarchy support, or cannot resolve a symbol cleanly, that is not the same as proving the function is unreached. A confidence ladder preserves that distinction by labeling verdicts according to their evidentiary strength, from resolved symbol-based calls down to low-confidence AI judgment. That prevents operational teams from mistaking tool failure for safety and keeps the review queue focused on the truly uncertain cases.
Practical implication: Treat unresolved analysis as a separate state so that tool gaps never collapse into false negatives.
NHI Mgmt Group analysis
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.
Ambiguity handling is the real AI use case here, not primary analysis. The article correctly separates deterministic questions from context-sensitive ones, such as framework-mediated calls or dynamic dispatch. That split matters because it prevents model confidence from being mistaken for evidence, which is one of the most common failure modes in AI-assisted security workflows. The practitioner conclusion is to constrain AI to the residue after semantic tooling has done the heavy lifting.
Reachability triage exposes a broader governance problem: evidence quality. Security teams increasingly need machine-generated verdicts that can be inspected, challenged, and replayed. A system that records the method behind each result creates a defensible audit trail, while a system that only returns a conclusion creates operational debt. The practitioner conclusion is to prefer tooling that preserves evidence provenance at verdict time.
Confidence labeling is a governance control, not a user-interface detail. A resolved symbol, an unresolved package import, and an AI guess are materially different states and should be handled differently in workflow design. This is the named concept worth carrying forward: verdict provenance: the evidentiary path behind a reachability decision, and the reason it can or cannot be trusted. The practitioner conclusion is to route low-confidence outcomes into human review and keep high-confidence semantic results machine-actionable.
What this signals
Verdict provenance: reachability analysis should preserve not just the answer but the evidentiary path that produced it. When teams can see whether a result came from resolved semantic navigation, package-level inference, or model judgment, they can route uncertainty to humans without slowing the whole workflow.
The broader programme implication is that AI belongs after deterministic control points, not before them. That sequencing matters for code review, vulnerability triage, and any security decision where a machine can prove part of the answer but not the whole thing.
For practitioners
- 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.
- Bound AI to ambiguous cases only Use the model for dynamic dispatch, framework-mediated calls, and other cases where semantic tooling cannot settle the question, then keep deterministic output as the reference point.
Key takeaways
- Reachability triage fails when model output is treated as evidence instead of interpretation, because semantic resolution is what proves the call path.
- The article’s operational value is in its separation of resolved, unresolved, and AI-judged outcomes, which keeps false precision out of the workflow.
- Security teams should use deterministic tooling first, then apply AI only where code semantics genuinely leave ambiguity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Reachability triage is a detection and analysis workflow that depends on trustworthy monitoring signals. |
| Recommendation — Use DE.CM-01 to ensure reachability signals come from verifiable semantic analysis rather than opaque model output. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The article stresses evidence provenance and reviewability for every verdict. |
| Recommendation — Apply AU-6 to retain verdict evidence, confidence class, and caller detail for analyst review. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | AI is used as a bounded decision layer and must be governed, not treated as the control itself. |
| Recommendation — Use GOVERN to define when AI may adjudicate ambiguous reachability and when deterministic tooling must decide first. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The topic centers on code-level correctness, dependency usage, and architecture-aware analysis. |
| Recommendation — Apply V15 to align reachability analysis with code structure, semantic binding, and architecture-aware validation. | ||
Key terms
- Reachability-Informed Triage: Reachability-informed triage is a prioritisation method that checks whether a vulnerable function is actually accessible in a live application path. Findings that exist in code but cannot be reached by an attacker can be deprioritised. This helps teams focus remediation on issues that are both real and practically exploitable.
- Call Hierarchy: Call hierarchy is a language-server capability that shows which functions call a symbol and which symbols it calls. It is more trustworthy than text matching because it resolves the underlying definitions and call relationships across files, packages, and modules.
- Confidence Ladder: A confidence ladder is a structured way to label security verdicts according to the strength of the evidence behind them. It separates definitive semantic results from partial inference and AI judgment, which helps teams avoid treating tool failure as proof of safety.
- Verdict Provenance: Verdict provenance is the evidentiary path that explains how a security decision was produced. In reachability analysis, it captures whether the result came from semantic tooling, package-level inference, or model reasoning, which makes the output auditable and easier to challenge.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org