Class Hierarchy Analysis is a static analysis technique used to resolve method calls by examining inheritance relationships. It helps approximate which method implementations may be invoked at runtime in object oriented code, especially when direct call targets are not obvious from the source alone.
What Class Hierarchy Analysis Actually Does
Class Hierarchy Analysis, or CHA, is a static approximation technique for object oriented programs. It inspects inheritance relationships to determine which concrete implementations a virtual or interface call could resolve to, which makes it useful when source code alone does not reveal a single target.
The key value of CHA is that it gives developers, auditors, and tooling a conservative call-target set without executing the program. That makes it useful for program understanding, call graph construction, optimization, and security review of reachable code paths, especially in languages with polymorphism and late binding.
Why It Matters for Security Analysis
From a security perspective, CHA helps analysts reason about reachability. If a sensitive method can be invoked through multiple subclasses, the analysis can surface unexpected execution paths, hidden attack surface, or logic that becomes reachable through inheritance rather than direct invocation.
That matters most when security decisions depend on understanding what code can actually run, not just what appears in the source at a single call site. A conservative call graph can reveal dead code, overly broad trust in inherited behavior, and places where code review or control validation should look beyond the apparent target.
For readers comparing broader software assurance practices, OWASP SAMM provides a maturity lens for building analysis and review practices into software delivery, while OWASP Cheat Sheet Series offers practical implementation guidance across secure coding topics that often benefit from call-graph awareness.
Limits, Trade-Offs, and Common Misreads
CHA is intentionally approximate. It is fast and broadly applicable, but it can overestimate the set of possible targets because it typically includes any method that could be reached through the inheritance tree, even when runtime conditions would eliminate most of them.
That over-approximation is the trade-off. It improves safety for static reasoning, but it also creates noise, especially in large codebases with deep class trees, dynamic dispatch, or frameworks that rely on reflection, proxies, or dependency injection. In those environments, CHA may be a starting point rather than the final answer.
A common mistake is treating CHA output as proof of actual runtime execution. It is better understood as a bounded possibility set, useful for prioritisation and analysis, not as evidence that every listed target will run in production.
Where It Is Used in Practice
CHA appears in compilers, program analysis tools, security scanners, and research workflows that need a call graph for object oriented code. It is especially helpful when the question is, “What methods could this call possibly reach?” rather than “What method will definitely execute?”
In security work, that makes it useful for identifying reachable sinks, tracing taint propagation, and locating methods that become interesting only because of inheritance relationships. It also helps reviewers focus on override points, abstract base classes, and framework callbacks that are easy to miss in manual inspection.
When the subject is software assurance at a broader level, the same call-reachability thinking complements NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls around secure configuration, access control, auditability, and integrity of software behavior.
Risk and Threat Considerations
Static call-target approximation can miss or obscure risky code paths when developers assume a call is safe because it appears indirect. Attackers and defenders both care about the same blind spot: inherited or overridden methods may expose behaviour that is not obvious from the local call site, especially in extensible frameworks and plugin-heavy systems.
Failure mechanism: Overly broad or overly narrow call-graph reasoning can hide reachable dangerous functionality, skew reachability analysis, or leave reviewers blind to code paths introduced through subclassing, proxies, or framework dispatch.
Impact: Security analysis may miss exploitable sinks, mis-rank remediation effort, or incorrectly assume that a sensitive method is unreachable when it is in fact accessible through polymorphic dispatch.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 16 — Application Software Security | CHA supports understanding reachable code paths in application software. |
| Recommendation — Apply secure coding review to validate polymorphic call paths and reachable sinks. | ||
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | CHA informs software assurance procedures used to analyze code behavior and reachability. |
| Recommendation — Use information protection procedures to review code paths that static analysis marks as reachable. | ||
| OWASP Agentic AI Top 10 | AGENT-UNKNOWN — Software Behavior and Tool-Use Governance | Call-target reasoning helps assess autonomous or tool-using code paths when software can dispatch actions indirectly. |
| Recommendation — Review delegated execution paths before allowing code to trigger sensitive operations. | ||
Practitioner Guidance
What to watch for: Use CHA as a conservative first pass, then validate any security-sensitive conclusion against the actual runtime model when inheritance, reflection, or framework indirection is present. The technique is strongest when it improves triage, not when it is treated as a complete execution oracle.
Practitioner takeaway: CHA is valuable when you need a safe superset of possible call targets, but it should not be the only basis for deciding whether a code path is truly reachable.
Related resources from NHI Mgmt Group
- How can organisations decide between segmentation, ground truth analysis, and weighting for rare-class monitoring?
- Why is behavioral analysis important for AI identity management?
- What is the difference between AI-enabled identity analysis and identity governance?
- What is the difference between SAST and semantic AI code analysis?
