Accessibilité comme preuve
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.
Ce que cela signifie pour votre entreprise
Ne corrigez que les vulnérabilités que votre application peut réellement atteindre — ignorez le reste. Stella prouve quels CVE sont atteignables pour que votre équipe se concentre sur les risques réels, pas sur le bruit des scanners. ReachabilityAnalyse qui prouve si le code vulnérable est réellement appelé par votre application — filtrant les faux positifs du bruit des scanners
Jusqu’à 70–90 %
Réduction typique du bruit
La plage observée varie selon la stack et la couverture.
3
Couches d’analyse
Graphes d’appels statiques, symboles binaires, sondes eBPF en exécution
100%
Signé & rejouable
Chaque verdict d’atteignabilité est une preuve signée DSSE
Chaque couche fournit des preuves progressivement plus solides qu'une fonction vulnérable est (ou n'est pas) accessible depuis votre application code. CVECommon Vulnerabilities and Exposures – un identifiant unique pour une vulnérabilité de sécurité publiquement connue
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.
Faites correspondre les symboles vulnérables aux exportations binaires compilées. Confirme que le code est réellement lié.
Profilage de production facultatif. Capture les appels de fonction réels pendant l'exécution.
eBPFExtended Berkeley Packet Filter — une technologie du noyau Linux qui exécute des programmes isolés pour une observabilité haute performance et l'analyse en temps d'exécution sans modules noyau basée sur TetragonRésultat : nettement de faux positifs en moins. Concentrez-vous sur 12 CVE accessibles au lieu de 487 théoriques.
Les preuves d'atteignabilité 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).
Lorsque l'analyse ne peut pas déterminer l'atteignabilité, l'incertitude est suivie explicitement, et non cachée ou supposée sûre.
| Seau d'atteignabilité | Poids par défaut |
|---|---|
| Point d’entrée | 1.0 |
| Appel direct | 0.85 |
| Confirmé en runtime | 0.45 |
| Inconnu | 0.5 |
| Inatteignable | 0.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.
Before enabling hard blocking in production, validate coverage on your own code corpus. The matrix below describes how to evaluate each language/runtime path and how unknowns should be treated.
| Language/runtime | Static call path | Binary/symbol evidence | Runtime evidence | Default gate when unknown |
|---|---|---|---|---|
| Go, Rust, C/C++ | Validate direct and transitive call-path extraction | Validate symbol/build-id matching accuracy | Optional eBPF confirmation for high-risk services | Review or block on critical findings by policy |
| Java and JVM languages | Validate method-level reachability and dynamic dispatch cases | Validate bytecode/jar symbol mapping | Runtime traces recommended for reflective paths | Route unknowns to manual review lane |
| .NET | Validate IL call graph and package lineage | Validate PDB/symbol resolution in release builds | Runtime confirmation for trimmed/AOT scenarios | Review unknowns before allow decision |
| Node, Python, Ruby, PHP | Validate framework entrypoints and dynamic import boundaries | Symbol evidence is partial by design for dynamic dispatch | Runtime traces strongly recommended | Keep unknown as explicit state and require approval |
Policy recommendation: treat unknown as a first-class verdict, set explicit thresholds per severity, and log reviewer override reasons in the evidence bundle.
DSSEDead Simple Signing Envelope – un standard simple et flexible pour signer des données arbitraires avec des signatures cryptographiques enveloppe avec le format de prédicat in-totoUn cadre pour sécuriser la chaîne d'approvisionnement logicielle en vérifiant que chaque étape a été exécutée comme prévu et par des acteurs autorisés SLSASupply-chain Levels for Software Artifacts — un cadre garantissant l'intégrité des artefacts logiciels tout au long de la chaîne d'approvisionnement Vérifiable par des auditeurs sans accès au réseau Le rejeu déterministe produit des résultats identiques au niveau binaire 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.zstChaque analyse d'atteignabilité produit une preuve signée cryptographiquement et stockée dans un stockage adressé par contenu. DSSEDead Simple Signing Envelope – un standard simple et flexible pour signer des données arbitraires avec des signatures cryptographiques
DSSEDead Simple Signing Envelope – un standard simple et flexible pour signer des données arbitraires avec des signatures cryptographiques enveloppe avec le format de prédicat in-totoUn cadre pour sécuriser la chaîne d'approvisionnement logicielle en vérifiant que chaque étape a été exécutée comme prévu et par des acteurs autorisés SLSASupply-chain Levels for Software Artifacts — un cadre garantissant l'intégrité des artefacts logiciels tout au long de la chaîne d'approvisionnementChemins de stockage adressés par contenu
cas://reachability_graphs/<hh>/<sha>.tar.zst
cas://runtime_traces/<hh>/<sha>.tar.zst
L'instrumentation optionnelle basée sur Tetragon capture les exécutions réelles de fonctions en production, fournissant ainsi des preuves d'atteignabilité 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.
Installez Stella Ops et commencez à produire des preuves d'atteignabilité signées avec une analyse à trois couches.