ReachabilityAnalyse qui prouve si le code vulnérable est réellement appelé par votre application — filtrant les faux positifs du bruit des scanners comme preuve

Ce qui bloque l’expédition : une exposition accessible, non corrigée et pertinente en premier lieu.

La longue queue est à un filtre.

~85 % des vulnérabilités critiques des conteneurs se trouvent dans du code inactif (rapport Sysdig 2024 sur la sécurité des conteneurs). L'analyse d'accessibilité demande si un chemin dans votre image atteint la fonction vulnérable, et signe une preuve pour chaque verdict – conservée ou supprimée.

L'ensemble de travail

Sept résultats entrent dans l’ensemble de travail dans l’écran ci-dessous. One bloque : il est accessible et non fixé. Les six autres ne sont pas corrigés mais ne sont pas accessibles – ils restent dans l’ensemble, classés plus bas, jamais cachés.

blocking = reachable × unfixed × policy-relevant

Écran d'exposition Stella Ops : un ensemble de travail de sept résultats, un blocage marqué avec un état REACHABLE, le reste détenu avec des états NOT OBSERVED
Écran d'exposition, console v1.0-RC1 avec parc d'exemple. NOT OBSERVED n'est pas « non vulnérable » : les inconnues restent visibles jusqu'à ce que des preuves indiquent le contraire.

REACHABLE

Un chemin exécutable depuis un point d'entrée vers le symbole vulnérable est mis en évidence — par un graphique d'appel statique, une correspondance de symbole binaire ou un résultat de sonde d'exécution.

NOT OBSERVED

Aucun chemin exécutable n'a été trouvé avec les preuves collectées jusqu'à présent. Il s’agit d’une déclaration sur les preuves, pas sur la vulnérabilité. La découverte garde sa place dans l’ensemble de travail.

Deux classements, un ensemble de données

Le même ensemble de travail sert deux tâches. Basculer entre eux modifie le tri vers le haut : rien n'entre ni ne sort.

Bateau

Classement en fonction de ce qui bloque cette version : exposition accessible, non corrigée et pertinente pour la politique en premier.

Sécurisé

Classement par exposition totale à travers le domaine, y compris les découvertes qui ne donneront jamais lieu à une publication.

Cela change le classement et l'accent, jamais les données.

D'où vient la preuve

L'analyse statique produit le verdict à chaque scan. Les symboles binaires et les faits d'exécution ajoutent de la profondeur quand vous le souhaitez. CVECommon Vulnerabilities and Exposures – un identifiant unique pour une vulnérabilité de sécurité publiquement connue

Couche 1

Analyse des graphiques d'appels statiques

Construit un graphe d'appels depuis le bytecode compilé et depuis les sources, puis trace les chemins de vos points d'entrée vers les fonctions nommées par un avis.

  • • Langages avec graphe d'appels : Go, Java, C#/.NET, JavaScript et TypeScript, Python, Rust, PHP, Ruby. Un seul langage est analysé par image. Les autres écosystèmes vont dans la catégorie unknown – notés, pas ignorés.
  • • L'extraction hors ligne est plus étroite : la construction d'un graphe d'appels depuis un arbre de sources dans la CLI ne prend en charge que Go et Rust, et utilise le niveau lexical – la chaîne SSA est embarquée dans le scanner worker. Les autres langages sont analysés par le pipeline de scan, dont la CLI consomme le graphe déjà extrait.
  • • Python, JavaScript/TypeScript, Rust, PHP et Ruby sont analysés depuis le texte source, et chaque arête porte sa confiance : vous voyez quel niveau a produit un verdict
  • • La réflexion, l'invocation dynamique et la répartition virtuelle au-delà des implémentations connues ne sont pas modélisées – chaque résultat énonce cette limite
Couche 2

Analyse des symboles binaires

Une voie CLI pour le code natif sans sources à lire : tables de symboles ELF et noms de fonctions DWARF, x86, x64 et ARM64. Ses résultats valent pour eux-mêmes, distincts du verdict de scan.

  • • Tables de symboles ELF et noms de fonctions DWARF
  • • Désassemblage x86, x64 et ARM64. Les informations de débogage ne sont lues que depuis DWARF – pas de PDB
Couche 3

Sondes 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 d'exécution

Injectez de vraies données d'exécution : Stella Ops les vérifie et les scelle comme la preuve d'accessibilité la plus forte qui existe. Vous exploitez les sondes ; RC1 fournit le chemin d'ingestion.

  • • Instrumentation 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 Tetragon
  • • Enregistrements symbol_id, code_id, hit_count, loader_base
  • • Préservation de la confidentialité : aucune valeur d'argument capturée

Chaque verdict est présenté sous la forme d'une preuve signée DSSE qui lie le résultat au chemin exécutable sur lequel il a été jugé. Lorsqu'aucun chemin n'a pu être analysé, le résultat est signalé comme inconnu plutôt que déclaré sans risque. DSSEDead Simple Signing Envelope – un standard simple et flexible pour signer des données arbitraires avec des signatures cryptographiques

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

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 de ReachabilityAnalyse qui prouve si le code vulnérable est réellement appelé par votre application — filtrant les faux positifs du bruit des scannersPoids par défaut
reachable:proven1.0
reachable:likely0.85
not-observed0.0

Plus élevé signifie plus de risque, pas plus de confiance : le poids met à l'échelle le score de risque d'un résultat. La confirmation à l'exécution ne remplace pas la preuve du chemin — elle augmente la confiance attachée au verdict. Là où l'analyseur n'a observé aucun chemin, Stella Ops indique non observé avec une déclaration de couverture signée, jamais « inatteignable » : n'observer aucun chemin ne prouve pas qu'il n'en existe aucun.

Recommandation politique : traitez unknown comme un verdict de première classe, définissez des seuils explicites par gravité et consignez les raisons de remplacement du réviseur dans l'ensemble des preuves.

Où les instructions VEX entrent

Les déclarations VEX des émetteurs rejoignent le même graphe de preuves, normalisées en cinq statuts — not_affected, affected, fixed, under_investigation, unknown — de sorte que « en cours d’investigation » est un état avec des conséquences, pas une note de bas de page. VEXVulnerability Exploitability eXchange – déclarations lisibles par machine indiquant si les vulnérabilités sont réellement exploitables dans votre contexte

not_affected affected fixed under_investigation unknown

Plusieurs émetteurs peuvent parler du même composant. Lorsqu'ils ne sont pas d'accord, la résolution des conflits enregistre le désaccord comme un conflit : rien n'est calculé en moyenne et aucun émetteur ne gagne en silence.

Comment les preuves SBOM et VEX sont fusionnées →

KEV et EPSS participent – ​​ils ne décident pas

Les listes CISA KEV et les scores EPSS sont des signaux d’exploitation de niveau consultatif. Ils augmentent le rang et l'urgence d'une découverte au sein de l'ensemble de travail. KEVKnown Exploited Vulnerabilities – catalogue de CISA des vulnérabilités activement exploitées EPSSExploit Prediction Scoring System – un score de probabilité (0–100 %) prédisant la probabilité qu'une vulnérabilité soit exploitée

Exploit signals attach at the advisory level, not at the finding level. Open a CVECommon Vulnerabilities and Exposures – un identifiant unique pour une vulnérabilité de sécurité publiquement connue to read its advisory-level exploit data: the KEVKnown Exploited Vulnerabilities – catalogue de CISA des vulnérabilités activement exploitées listing and the EPSSExploit Prediction Scoring System – un score de probabilité (0–100 %) prédisant la probabilité qu'une vulnérabilité soit exploitée score belong to the advisory, and they read the same for every service that carries the affected component.

Ce ne sont pas des preuves d’accessibilité. Une entrée KEV sur le code de votre service ne charge jamais l'accent sur les modifications, pas le verdict - à moins que votre politique n'indique que les résultats connus sont bloqués malgré tout. Deux classes de règles peuvent bloquer, et elles sont indépendantes : une liste de blocage de CVE ignore entièrement la reachability, tandis qu'une règle de reachability ne bloque que sur un chemin prouvé — reachable:likely et unknown ne bloquent jamais par ce biais, quels que soient les états listés par la politique.

A policy gate can combine both kinds of answer in one rule: reachability state together with EPSSExploit Prediction Scoring System – un score de probabilité (0–100 %) prédisant la probabilité qu'une vulnérabilité soit exploitée, KEVKnown Exploited Vulnerabilities – catalogue de CISA des vulnérabilités activement exploitées, and CVSSCommon Vulnerability Scoring System – une note de gravité de 0 à 10 indiquant la criticité d'une vulnérabilité thresholds. "Known-exploited and reachable" and "known-exploited regardless of reachability" are both expressible; which one you enforce is your policy, not a default we pick for you.

Par rapport à un scanner en CI

Un scanner répond « ce qu'il y a dans cette image en ce moment ». Nécessaire — et pas suffisant pour une décision de mise en liberté.

Ce qu'un scanner vous apporte

  • • Une liste de résultats par image, régénérée à partir de zéro à chaque exécution
  • • Gravité tirée de l'avis, pas de votre graphique d'appel
  • • Suppressions dans les fichiers ignorés, sans enregistrement signé indiquant qui a accepté quoi

Ce que Stella Ops ajoute

  • • Résultats regroupés à travers les sources de conseil actives 38, puis classés par accessibilité
  • • Une épreuve rejouable signée DSSE pour chaque verdict, y compris ceux supprimés
  • • Le verdict alimente la porte de publication et Watch continue de comparer le résumé en cours avec celui approuvé après le déploiement.

Ce que Stella Ops ne fait pas

Trivy couvre les référentiels Git, les machines virtuelles et les cibles Kubernetes, ainsi que les erreurs de configuration et l'analyse des secrets. Ce n’est pas le cas de Stella Ops. Sa portée est constituée d'images de conteneurs et d'instantanés de système de fichiers, avec des preuves signées et rejouables pour chaque verdict.

Comparaisons complètes : Stella Ops contre Trivy | Stella Ops contre Grype

Implémentation : jointures par hachage de nœud

Les preuves de ReachabilityAnalyse qui prouve si le code vulnérable est réellement appelé par votre application — filtrant les faux positifs du bruit des scanners 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).
Read more

Les preuves de ReachabilityAnalyse qui prouve si le code vulnérable est réellement appelé par votre application — filtrant les faux positifs du bruit des scanners 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).

Mise en œuvre : épreuves signées

Chaque analyse d'atteignabilité produit une preuve signée cryptographiquement et stockée dans un stockage adressé par contenu. DSSE?Dead 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'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.zst
Read more

Chaque 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'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.zst

Mesuré contre une vérité de référence publiée

Le classifieur d'atteignabilité est mesuré contre un corpus étiqueté livré dans l'arbre source public : huit services minimaux en Java, Node.js, Python, Go, .NET, Ruby, Rust et PHP, chacun avec un fichier d'étiquettes indiquant, par CVE, le niveau attendu — de R0, non atteignable dans ce service, à R4, atteignable depuis le point d'entrée — et sa justification.

Le même arbre contient le harnais qui note les classifications par niveau — précision et rappel, pas un chiffre unique mélangé. Le corpus, les étiquettes et le contrat de niveaux étant publics, vous n'avez pas à croire notre lecture : scannez la même vérité de référence avec votre propre installation et comparez ce qu'elle rapporte aux réponses attendues publiées.

Comment mener cette comparaison est l'étape 2.1 du pilote d'évaluation →

Implémentation : sondes eBPF

Stella Ops accepte les faits d'exécution via un point d'ingestion en flux et les traite comme la preuve d'atteignabilité la plus forte qui existe. RC1 ne fournit pas le collecteur : les sondes basées sur Tetragon sont une instrumentation que vous exploitez, et l'atteignabilité fonctionne sans elles à partir des couches statique et binaire. 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 Les sondes envoient les faits d'exécution à POST /signals/runtime-facts/ndjson sous forme de flux NDJSON. Chaque observation contient l'URI CAS de l'artefact sous-jacent.
Read more

Stella Ops accepte les faits d'exécution via un point d'ingestion en flux et les traite comme la preuve d'atteignabilité la plus forte qui existe. RC1 ne fournit pas le collecteur : les sondes basées sur Tetragon sont une instrumentation que vous exploitez, et l'atteignabilité fonctionne sans elles à partir des couches statique et binaire.

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

Les sondes envoient les faits d'exécution à POST /signals/runtime-facts/ndjson sous forme de flux NDJSON. Chaque observation contient l'URI CAS de l'artefact sous-jacent.

Commencez avec votre propre ensemble de travail

Pointez Stella Ops sur une image que vous expédiez aujourd’hui et lisez les verdicts qu’elle signe. Si l'accessibilité supprime moins qu'elle ne le prétend, vous le verrez également : chaque suppression comporte sa preuve.

Offre gratuite : 3 environnements et jusqu’à 100 analyses de nouveaux digests par période glissante de 24 h, auto-hébergée. v1.0-RC1, version candidate.