git.stella-ops.org/docs/marketing/hybrid-reachability.md

Hybrid Reachability — Static + Runtime Analysis

Status: Marketing Bridge Document · December 2025 Audience: Technical buyers, security architects, compliance teams

Executive Summary

Stella Ops isn't just another scanner—it's a different product category: deterministic, evidence-linked vulnerability decisions that survive auditors, regulators, and supply-chain propagation.

Hybrid Reachability is how we achieve accurate impact analysis: combining static call-graph analysis with runtime process tracing to determine whether vulnerable code is actually reachable. Both edge types are separately attestable with DSSE signatures, providing true hybrid analysis with cryptographic proof.

Key message: "True hybrid reachability—static and runtime signals share one verdict."

---

What is Hybrid Reachability?

Traditional reachability analysis uses either:

• Static analysis: Examines code without executing it (call graphs, data flow)
• Runtime analysis: Observes actual execution (method hits, stack traces)

Stella Ops uses both and reconciles them into a unified reachability decision:

┌─────────────────────────────────────────────────────────────┐
│                   Hybrid Reachability                        │
├────────────────────────┬────────────────────────────────────┤
│    Static Analysis     │       Runtime Analysis              │
├────────────────────────┼────────────────────────────────────┤
│ • IL/bytecode walkers  │ • .NET EventPipe                    │
│ • ASP.NET routing      │ • JVM JFR                           │
│ • Call-graph edges     │ • Node inspector                    │
│ • Entry-point prox.    │ • Go/Rust probes                    │
├────────────────────────┴────────────────────────────────────┤
│                                                              │
│                    Lattice Engine                            │
│         ┌─────────────────────────────────────┐             │
│         │ Merge signals → Score → VEX status  │             │
│         └─────────────────────────────────────┘             │
│                                                              │
│         ┌─────────────────────────────────────┐             │
│         │ DSSE Attestation (Graph + Edges)    │             │
│         └─────────────────────────────────────┘             │
└─────────────────────────────────────────────────────────────┘

---

Why Hybrid Matters

Limitations of Static-Only Analysis

Issue	Description	Impact
Over-reporting	Reports paths that never execute	Alert fatigue
Dynamic dispatch	Misses reflection, DI, runtime binding	False negatives
Framework magic	ASP.NET/Spring routing not fully modeled	Incomplete coverage
Configuration	Doesn't account for runtime config	Context-blind

Limitations of Runtime-Only Analysis

Issue	Description	Impact
Coverage gaps	Only sees executed paths	Misses rare paths
Environment-specific	Results vary by test coverage	Non-deterministic
No proactive detection	Requires traffic to observe	Reactive, not preventive
Attack surface	May miss dormant vulnerabilities	Security risk

Hybrid Solution

Signal Type	Strength	Weakness	Hybrid Benefit
Static	Comprehensive coverage	Over-reports	Runtime filters false positives
Runtime	Ground truth	Incomplete	Static catches unexercised paths

Result: Higher confidence with lower false positive/negative rates.

---

Reachability Lattice

Stella Ops uses a confidence lattice with explicit states:

UNOBSERVED (0–9)
    < POSSIBLE (10–29)
        < STATIC_PATH (30–59)
            < DYNAMIC_SEEN (60–79)
                < DYNAMIC_USER_TAINTED (80–99)
                    < EXPLOIT_CONSTRAINTS_REMOVED (100)

State	Evidence Required	VEX Mapping
UNOBSERVED	None	under_investigation
POSSIBLE	Lockfile-only	under_investigation
STATIC_PATH	Static call-graph edge	under_investigation
DYNAMIC_SEEN	Runtime method hit	affected
DYNAMIC_USER_TAINTED	User input reaches vuln	affected
EXPLOIT_CONSTRAINTS_REMOVED	Full exploit chain	affected

Key feature: The under_investigation state explicitly handles incomplete data—Stella never marks something "safe" without sufficient evidence.

---

Attestation Model

Both static and runtime edges are attestable:

Graph-Level Attestation (Required)

level: 0
payload: richgraph-v1
signature: DSSE
storage: cas://reachability/graphs/{blake3}
rekor: always

Edge-Bundle Attestation (Selective)

level: 1
payload: edge-bundle (≤512 edges)
criteria:
  - source: runtime
  - source: init_array/constructors
  - status: contested/quarantined
signature: DSSE
storage: cas://reachability/edges/{graph_hash}/{bundle_id}
rekor: configurable

This enables:

• Prove specific paths: Attest individual runtime-observed edges
• Dispute resolution: Quarantine/revoke specific edges
• Offline verification: Verify without network access

---

Competitive Differentiation

Capability	Stella Ops	Competitors
Analysis type	Hybrid (static + runtime)	Usually one or the other
Attestation	DSSE for both edge types	None or graph-only
Unknown handling	Explicit under_investigation	Binary yes/no
Edge-level proof	Selective edge-bundle DSSE	Not available

Battlecard one-liner: "Static analysis sees code paths; runtime sees execution. Stella sees both—and proves it."

---

Signal Sources

Static Analysis Signals

Signal	Source	Evidence Kind
Call-graph edges	Roslyn/IL walkers	StaticCallEdge
Entry-point proximity	Framework routing models	StaticEntryPointProximity
Package declarations	Lockfile/manifest	StaticPackageDeclaredOnly

Runtime Analysis Signals

Signal	Source	Evidence Kind
Method hits	.NET EventPipe	RuntimeMethodHit
Stack samples	JVM JFR	RuntimeStackSample
HTTP routes	ASP.NET/Spring routing	RuntimeHttpRouteHit
User input	Taint analysis	UserInputSource

Mitigation Signals

Signal	Source	Effect
WAF rules	WAF connectors	Score reduction
Config flags	Config snapshot	Score reduction
Network isolation	Container policy	Score reduction

---

Integration with Four Capabilities

Hybrid Reachability is Capability #1 of four:

1. Signed Reachability ← This document
2. Deterministic Replay → Reachability evidence in Decision Capsules
3. Explainable Policy → Reachability feeds the lattice VEX engine
4. Sovereign Offline → All analysis verifiable without network

---

Customer Scenarios

Scenario 1: False Positive Reduction

"We're drowning in vulnerability alerts." → Hybrid analysis shows 70% of reported CVEs have no reachable path; focus on the 30% that matter.

Scenario 2: Runtime Validation

"Static analysis says this is reachable—is it really?" → Runtime probes observed 0 hits over 30 days; downgrade to under_investigation.

Scenario 3: Audit Proof

"Prove the vulnerable code path is not reachable." → Show the signed reachability graph with static call-graph (no path) + runtime traces (no hits).

Scenario 4: Contested Edge

"We disagree with this reachability finding." → Mark the edge as disputed; policy excludes it; recompute reachability; surface the delta.

---

CLI Integration

# Scan with hybrid reachability
stella scan --image reg/app@sha256:... --reachability hybrid

# Verify reachability graph
stella graph verify --graph blake3:abc123

# Show reachability decision for a CVE
stella reach show --cve CVE-2025-1234 --component pkg:nuget/Example@1.2.3

# Export edge bundles for audit
stella reach export --graph blake3:abc123 --bundles-only

---

Related Documentation

• docs/reachability/hybrid-attestation.md — Attestation technical details
• docs/reachability/lattice.md — Scoring model
• docs/marketing/decision-capsules.md — Decision Capsules overview
• docs/marketing/evidence-linked-vex.md — Evidence-linked VEX