Erreichbarkeit als Beweis

Beweisen Sie, ob anfälliger Code tatsächlich aufgerufen wird

Dreischichtige Analyse – statische Aufrufdiagramme, Binärsymbolabgleich, Laufzeit-eBPF-Probes – erzeugt signierte DSSE Beweise, die Fehlalarme deutlich reduzieren.

Dreischichtige Analyse

Jede Ebene liefert zunehmend stärkere Beweise dafür, dass eine anfällige Funktion von Ihrer Anwendung aus erreichbar ist (oder nicht). Code.

Layer 1

Statische Aufrufdiagrammanalyse

Aufrufdiagramme aus Bytecode, AST und Quellcode extrahieren. Verfolgen Sie Pfade von Einstiegspunkten zu anfälligen Symbolen.

  • • Sprachunterstützung: Go, Rust, C#, Java, Python, JavaScript, C/C++
  • • Verarbeitet virtuellen Versand, Schnittstellenaufrufe und Reflexion mit konservativer Näherung
  • • Erstellt DAG mit Erreichbarkeitsstatus pro Knoten
Layer 2

Binärsymbolanalyse

Anfällige Symbole mit kompilierten Binärexporten abgleichen. Bestätigt, dass der Code tatsächlich verknüpft ist.

  • • Extraktion von Symboltabellen aus ELF, PE, Mach-O
  • • Querverweise DWARF/PDB-Debug-Informationen, sofern verfügbar
Layer 3

Laufzeit-eBPF-Probes

Optionale Produktionsprofilierung. Erfasst tatsächliche Funktionsaufrufe während der Ausführung.

  • • Tetragon-basierte eBPF-Instrumentierung
  • • Zeichnet symbol_id, code_id, hit_count, loader_base auf
  • • Datenschutz: Keine Argumentwerte erfasst

Ergebnis: deutlich weniger Fehlalarme. Konzentrieren Sie sich auf 12 erreichbare CVEs anstelle von 487 theoretischen.

Knoten-Hash-Joins

Erreichbarkeitsnachweise werden zur Deduplizierung und Überprüfung inhaltsadressiert. Knoten-Hashes ermöglichen eine effiziente Differenzierung zwischen Versionen.

Knoten Hash

SHA256(normalize(purl) + ":" + normalize(symbol))

Pfad-Hash

SHA256(entryNodeHash + ":" + joinedIntermediateHashes + ":" + sinkNodeHash)

Top-K-signifikante Pfade bleiben im Beweisbündel erhalten. Pfade werden nach Ausführungshäufigkeit (von Laufzeit) oder Aufruftiefe (von statisch) geordnet.

Unbekannte als First-Class-Status

Wenn die Analyse die Erreichbarkeit nicht ermitteln kann, wird die Unsicherheit explizit nachverfolgt – nicht versteckt oder stillschweigend als sicher angenommen.

Erreichbarkeits-BucketStandardgewichtung
Einstiegspunkt1.0
Direkter Aufruf0.85
Runtime bestätigt0.45
Unbekannt0.5
Nicht erreichbar0.0

Endergebnis = max(bucket_weights) über alle Pfade hinweg. Unbekannte Knoten tragen zur Risikobewertung bei, anstatt ignoriert zu werden.

DSSE Signiert Proofs

Jede Erreichbarkeitsanalyse erzeugt einen kryptografisch signierten Beweis, der im inhaltsadressierten Speicher gespeichert wird.

  • DSSE-Umschlag mit in-toto SLSA-Prädikatformat
  • Von Prüfern ohne Netzwerkzugriff überprüfbar
  • Deterministische Wiedergabe erzeugt bitidentische Ergebnisse
  • Grafik und Traces für Offline archiviert Verifizierung

Inhaltsadressierte Speicherpfade

cas://reachability_graphs/<hh>/<sha>.tar.zst

cas://runtime_traces/<hh>/<sha>.tar.zst

eBPF-Laufzeit Probes

Optionale Tetragon-basierte Instrumentierung erfasst tatsächliche Funktionsausführungen in der Produktion und liefert den höchstzuverlässigen Nachweis der Erreichbarkeit.

Erfasste Sondendaten

symbol_id: kanonischer Symbol-Identifikator

code_id: Identifikator des Code-Abschnitts

hit_count: Ausführungshäufigkeit

loader_base: Basisadresse im Speicher

cas_uri: inhaltsadressierte Referenz

Probes Senden Sie Beobachtungen stapelweise an /api/v1/observations. Jede Beobachtung enthält den CAS-URI für das zugrunde liegende Artefakt.

Bereit, Fehlalarme deutlich zu reduzieren?

Installieren Sie Stella Ops und beginnen Sie mit der Erstellung signierter Erreichbarkeitsnachweise mit dreischichtiger Analyse.