Accessibilité comme preuve

Prouvez si le code vulnérable est réellement appelé

Analyse à trois couches : graphiques d'appels statiques, correspondance de symboles binaires, sondes eBPF d'exécution – produit des DSSE signés. des preuves qui réduisent nettement des faux positifs.

Commencer Voir toutes les fonctionnalités

Analyse à trois couches

Chaque couche fournit des preuves progressivement plus solides qu'une fonction vulnérable est (ou n'est pas) accessible depuis votre application code.

Couche 1

Analyse des graphiques d'appels statiques

Extraire les graphiques d'appels du bytecode, de l'AST et du code source. Tracez les chemins depuis les points d'entrée jusqu'aux symboles vulnérables.

  • • Prise en charge des langues : Go, Rust, C#, Java, Python, JavaScript, C/C++
  • • Gère la répartition virtuelle, les appels d'interface et la réflexion avec une approximation conservatrice
  • • Produit un DAG avec un état d'accessibilité par nœud
Couche 2

Analyse des symboles binaires

Faites correspondre les symboles vulnérables aux exportations binaires compilées. Confirme que le code est réellement lié.

  • • Extraction de table de symboles à partir d'ELF, PE, Mach-O
  • • Références croisées des informations de débogage DWARF/PDB lorsqu'elles sont disponibles
Couche 3

Sondes eBPF d'exécution

Profilage de production facultatif. Capture les appels de fonction réels pendant l'exécution.

  • • Instrumentation eBPF basée sur Tetragon
  • • Enregistrements symbol_id, code_id, hit_count, loader_base
  • • Préservation de la confidentialité : aucune valeur d'argument capturée

Résultat : nettement de faux positifs en moins. Concentrez-vous sur 12 CVE accessibles au lieu de 487 théoriques.

Rejointures de hachage de nœud

Les preuves d'accessibilité sont adressées par contenu pour la déduplication et la vérification. Les hachages de nœuds permettent une comparaison efficace entre les versions.

Hash de nœud

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

Hash de chemin

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

Les chemins significatifs Top-K sont conservés dans le groupe de preuves. Les chemins sont classés par fréquence d'exécution (à partir de l'exécution) ou par profondeur d'appel (à partir de la statique).

Inconnus en tant qu'état de première classe

Lorsque l'analyse ne peut pas déterminer l'accessibilité, l'incertitude est suivie explicitement, et non cachée ou supposée sûre.

Seau d'accessibilitéPoids par défaut
Point d’entrée1.0
Appel direct0.85
Confirmé en runtime0.45
Inconnu0.5
Inatteignable0.0

Score final = max(bucket_weights) sur tous les chemins. Les nœuds inconnus contribuent à l'évaluation des risques plutôt que d'être ignorés.

DSSE Signé Preuves

Chaque analyse d'accessibilité produit une preuve signée cryptographiquement et stockée dans un stockage adressé par contenu.

  • DSSE enveloppe avec le format de prédicat in-toto SLSA
  • Vérifiable par des auditeurs sans accès au réseau
  • La relecture déterministe produit des résultats identiques en termes de bits
  • Graphique et traces archivées pour le mode hors ligne vérification

Chemins de stockage adressés par contenu

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

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

eBPF Runtime Sondes

L'instrumentation optionnelle basée sur Tetragon capture les exécutions réelles de fonctions en production, fournissant ainsi des preuves d'accessibilité de la plus haute fiabilité.

Données de sonde capturées

symbol_id: identifiant canonique de symbole

code_id: identifiant de section de code

hit_count: fréquence d’exécution

loader_base: adresse de base mémoire

cas_uri: référence adressée par contenu

Soumission des sondes observations vers /api/v1/observations par lots. Chaque observation inclut l'URI CAS de l'artefact sous-jacent.

Prêt à éliminer les faux positifs en nettement ?

Installez Stella Ops et commencez à produire des preuves d'accessibilité signées avec une analyse à trois couches.

Commencer Voir la documentation