Alcanzabilidad como evidencia

Lo que bloquea el envío: primero la exposición accesible, no fijada y relevante para las políticas.

La cola larga está a un filtro de distancia.

~85% de las vulnerabilidades críticas de los contenedores están en código inactivo (Sysdig 2024 Informe de seguridad del contenedor). El análisis de alcanzabilidad pregunta si una ruta en su imagen alcanza la función vulnerable, y firma una prueba para cada veredicto, conservado o eliminado.

Empieza gratis Ver documentación

El conjunto de trabajo

Siete hallazgos ingresan al conjunto de trabajo en la siguiente pantalla. Uno bloquea: es accesible y no está fijado. Los otros seis no están arreglados pero no se muestran accesibles: permanecen en el conjunto, clasificados en niveles inferiores, nunca ocultos.

blocking = reachable × unfixed × policy-relevant

REACHABLE

Se evidencia una ruta ejecutable desde un punto de entrada hasta el símbolo vulnerable: mediante un gráfico de llamadas estáticas, una coincidencia de símbolos binarios o un resultado de sondeo en tiempo de ejecución.

NOT OBSERVED

No se encontró ninguna ruta ejecutable con las pruebas recopiladas hasta el momento. Ésa es una afirmación sobre la evidencia, no sobre la vulnerabilidad. El hallazgo mantiene su lugar en el conjunto de trabajo.

Dos clasificaciones, un conjunto de datos

El mismo conjunto de trabajo sirve para dos trabajos. Cambiar entre ellos cambia lo que se clasifica en la parte superior: nada entra ni sale.

Barco

Clasifica según lo que bloquea esta publicación: exposición alcanzable, no fijada y relevante para las políticas en primer lugar.

Seguro

Clasificaciones por exposición total en todo el patrimonio, incluidos los hallazgos que nunca darán lugar a una publicación.

Cambia la clasificación y el énfasis, nunca los datos.

De dónde viene la evidencia

El análisis estático produce el veredicto en cada escaneo. Los símbolos binarios y los hechos de ejecución añaden profundidad cuando usted la quiere. CVE?Common Vulnerabilities and Exposures – un identificador único para una vulnerabilidad de seguridad conocida públicamente

Capa 1

Análisis estático de grafos de llamadas

Construye un grafo de llamadas desde el bytecode compilado y desde el código fuente, y traza rutas desde sus puntos de entrada hasta las funciones que nombra un aviso.

• Lenguajes con grafo de llamadas: Go, Java, C#/.NET, JavaScript y TypeScript, Python, Rust, PHP, Ruby. Se analiza un lenguaje por imagen. Otros ecosistemas caen en la categoría unknown: puntuados, no omitidos.
• La extracción offline es más limitada: construir un grafo de llamadas desde un árbol de fuentes en la CLI solo admite Go y Rust, y usa el nivel léxico; la cadena SSA viaja dentro del scanner worker. Los demás lenguajes los analiza el pipeline de escaneo, cuyo grafo ya extraído consume la CLI.
• Python, JavaScript/TypeScript, Rust, PHP y Ruby se analizan desde el texto fuente, y cada arista lleva su confianza: usted ve qué nivel produjo un veredicto
• La reflexión, la invocación dinámica y el despacho virtual más allá de las implementaciones conocidas no se modelan: cada resultado declara este límite

Capa 2

Análisis de símbolos binarios

Una vía por CLI para código nativo sin fuentes que leer: tablas de símbolos ELF y nombres de función DWARF, x86, x64 y ARM64. Sus hallazgos valen por sí mismos, separados del veredicto de un escaneo.

• Tablas de símbolos ELF y nombres de función DWARF
• Desensamblado x86, x64 y ARM64. La información de depuración se lee sólo desde DWARF: sin PDB

Capa 3

Sondas eBPF?Extended Berkeley Packet Filter — una tecnología del kernel de Linux que ejecuta programas aislados para observabilidad y análisis en tiempo de ejecución de alto rendimiento sin módulos del kernel en tiempo de ejecución

Aporte datos de ejecución reales y Stella Ops los verifica y los sella como la evidencia de alcanzabilidad más sólida que existe. Usted opera las sondas; RC1 incluye la vía de ingesta.

• Instrumentación eBPF?Extended Berkeley Packet Filter — una tecnología del kernel de Linux que ejecuta programas aislados para observabilidad y análisis en tiempo de ejecución de alto rendimiento sin módulos del kernel basada en Tetragon
• Registra symbol_id, code_id, hit_count, loader_base
• Preservación de la privacidad: no se capturan valores de argumentos

Cada veredicto se empaqueta como una prueba firmada DSSE que vincula el hallazgo a la ruta ejecutable por la que se juzgó. Cuando no se pudo analizar ninguna ruta, el hallazgo se informa como desconocido en lugar de descartarse. DSSE?Dead Simple Signing Envelope – un estándar simple y flexible para firmar datos arbitrarios con firmas criptográficas

Desconocidos como estado de primera clase

Cuando el análisis no puede determinar la alcanzabilidad, la incertidumbre se rastrea explícitamente; no se oculta ni se asume silenciosamente como segura.

Bucket de alcanzabilidad	Peso predeterminado
reachable:proven	1.0
reachable:likely	0.85
not-observed	0.0

Más alto significa más riesgo, no más confianza: el peso escala la puntuación de riesgo de un hallazgo. La confirmación en ejecución no sustituye la prueba de la ruta: eleva la confianza asociada al veredicto. Donde el analizador no observó ninguna ruta, Stella Ops informa no observado con una declaración de cobertura firmada, nunca «inalcanzable»: no observar una ruta no prueba que no exista.

Recomendación de política: trate unknown como un veredicto de primera clase, establezca umbrales explícitos por gravedad y registre los motivos de anulación del revisor en el paquete de evidencia.

Donde entran las declaraciones VEX

Las declaraciones VEX de los emisores se unen al mismo grafo de evidencia, normalizadas a cinco estados — not_affected, affected, fixed, under_investigation, unknown — de modo que "bajo investigación" es un estado con consecuencias, no una nota a pie de página. VEX?Vulnerability Exploitability eXchange – declaraciones legibles por máquina sobre si las vulnerabilidades son realmente explotables en su contexto

not_affected affected fixed under_investigation unknown

Varios emisores pueden hablar del mismo componente. Cuando no están de acuerdo, la resolución de conflictos registra el desacuerdo como un conflicto: no se promedia nada y ningún emisor gana silenciosamente.

Cómo se combinan las pruebas SBOM y VEX →

KEV y EPSS participan — ellos no deciden

Los listados CISA KEV y las puntuaciones EPSS son señales de explotación a nivel de aviso. Elevan el rango y la urgencia de un hallazgo dentro del conjunto de trabajo. KEV?Known Exploited Vulnerabilities – catálogo de CISA de vulnerabilidades activamente explotadas EPSS?Exploit Prediction Scoring System – una puntuación de probabilidad (0–100%) que predice qué tan probable es que una vulnerabilidad sea explotada

Exploit signals attach at the advisory level, not at the finding level. Open a CVE?Common Vulnerabilities and Exposures – un identificador único para una vulnerabilidad de seguridad conocida públicamente to read its advisory-level exploit data: the KEV?Known Exploited Vulnerabilities – catálogo de CISA de vulnerabilidades activamente explotadas listing and the EPSS?Exploit Prediction Scoring System – una puntuación de probabilidad (0–100%) que predice qué tan probable es que una vulnerabilidad sea explotada score belong to the advisory, and they read the same for every service that carries the affected component.

No son alcanzabilidad evidencia. Una entrada KEV en el código que su servicio nunca carga cambia el énfasis, no el veredicto, a menos que su política indique que los hallazgos explotados conocidos se bloquean de todos modos. Dos clases de reglas pueden bloquear, y son independientes: una lista de bloqueo de CVE ignora la reachability por completo, mientras que una regla de reachability solo bloquea con un camino probado — reachable:likely y unknown nunca bloquean por esa vía, cualesquiera sean los estados que liste la política.

A policy gate can combine both kinds of answer in one rule: reachability state together with EPSS?Exploit Prediction Scoring System – una puntuación de probabilidad (0–100%) que predice qué tan probable es que una vulnerabilidad sea explotada, KEV?Known Exploited Vulnerabilities – catálogo de CISA de vulnerabilidades activamente explotadas, and CVSS?Common Vulnerability Scoring System – una puntuación de gravedad de 0 a 10 que indica qué tan crítica es una vulnerabilidad 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.

Frente a un escáner en CI

Un escáner responde "qué hay en esta imagen ahora mismo". Necesario y no suficiente para tomar una decisión de liberación.

Lo que te ofrece una ejecución de escáner

• Una lista de hallazgos por imagen, regenerada desde cero en cada ejecución
• Gravedad tomada del aviso, no de su gráfico de llamadas
• Supresiones en ficheros ignorados, sin registro firmado de quién aceptó qué

Qué agrega Stella Ops

• Hallazgos combinados de 38 fuentes de asesoramiento activas y luego clasificados por alcanzabilidad
• Una prueba reproducible y firmada por DSSE para cada veredicto, incluidos los eliminados
• El veredicto alimenta la puerta de liberación y Watch sigue comparando el digest en ejecución con el aprobado después del desplegar.

Lo que Stella Ops no hace

Trivy cubre repositorios de Git, máquinas virtuales y destinos Kubernetes, además de configuraciones incorrectas y escaneos secretos. Stella Ops no lo hace. Su alcance son imágenes de contenedores e instantáneas del sistema de archivos, con evidencia firmada y reproducible para cada veredicto.

Comparaciones completas: Stella Ops frente a Trivy | Stella Ops contra Grype

Implementación: uniones hash de nodos

Las pruebas de alcanzabilidad se direccionan por contenido para deduplicación y verificación. Los hashes de nodo permiten diferenciar versiones de forma eficiente. Hash de nodo SHA256(normalize(purl) + ":" + normalize(symbol)) Hash de ruta SHA256(entryNodeHash + ":" + joinedIntermediateHashes + ":" + sinkNodeHash) Se conservan las rutas significativas Top-K en el paquete de evidencia. Las rutas se clasifican por frecuencia de ejecución (desde runtime) o profundidad de llamada (desde estática).

Las pruebas de alcanzabilidad se direccionan por contenido para deduplicación y verificación. Los hashes de nodo permiten diferenciar versiones de forma eficiente.

Hash de nodo

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

Hash de ruta

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

Se conservan las rutas significativas Top-K en el paquete de evidencia. Las rutas se clasifican por frecuencia de ejecución (desde runtime) o profundidad de llamada (desde estática).

Implementación: pruebas firmadas

Cada análisis de alcanzabilidad produce una prueba firmada criptográficamente, almacenada en un almacenamiento direccionado por contenido. DSSE?Dead Simple Signing Envelope – un estándar simple y flexible para firmar datos arbitrarios con firmas criptográficas Sobre con (formato de predicado ) Verificable por auditores sin acceso a la red La reproducción determinista produce resultados idénticos bit a bit Grafos y trazas archivados para verificación sin conexión Rutas de almacenamiento direccionadas por contenido cas://reachability_graphs/<hh>/<sha>.tar.zst cas://runtime_traces/<hh>/<sha>.tar.zst

Cada análisis de alcanzabilidad produce una prueba firmada criptográficamente, almacenada en un almacenamiento direccionado por contenido. DSSE?Dead Simple Signing Envelope – un estándar simple y flexible para firmar datos arbitrarios con firmas criptográficas

Sobre DSSE?Dead Simple Signing Envelope – un estándar simple y flexible para firmar datos arbitrarios con firmas criptográficas con in-toto?Un marco para asegurar la cadena de suministro de software verificando que cada paso fue ejecutado según lo planificado y por actores autorizados (formato de predicado SLSA?Supply-chain Levels for Software Artifacts — un marco para garantizar la integridad de los artefactos de software a lo largo de la cadena de suministro)
Verificable por auditores sin acceso a la red
La reproducción determinista produce resultados idénticos bit a bit
Grafos y trazas archivados para verificación sin conexión

Rutas de almacenamiento direccionadas por contenido

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

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

Medido contra una verdad de referencia publicada

El clasificador de alcanzabilidad se mide contra un corpus etiquetado que se distribuye en el árbol público de código fuente: ocho servicios mínimos en Java, Node.js, Python, Go, .NET, Ruby, Rust y PHP, cada uno con un archivo de etiquetas que declara, por CVE, el nivel esperado — de R0, no alcanzable en ese servicio, a R4, alcanzable desde el punto de entrada — y su justificación.

El mismo árbol contiene el harness que puntúa las clasificaciones por nivel — precisión y exhaustividad, no una única cifra mezclada. Como el corpus, las etiquetas y el contrato de niveles son públicos, no tiene que aceptar nuestra lectura: escanee la misma verdad de referencia con su propia instalación y compare lo que informa con las respuestas esperadas publicadas.

Cómo ejecutar esa comparación es el paso 2.1 del piloto de evaluación →

Implementación: sondas eBPF

Stella Ops acepta hechos de ejecución a través de un endpoint de ingesta en streaming y los trata como la evidencia de alcanzabilidad más sólida que existe. RC1 no incluye el recolector: las sondas basadas en Tetragon son instrumentación que usted opera, y la alcanzabilidad funciona sin ellas a partir de las capas estática y binaria. Datos capturados por la sonda symbol_id: identificador canónico de símbolo code_id: identificador de sección de código hit_count: frecuencia de ejecución loader_base: dirección base en memoria cas_uri: referencia direccionada por contenido Las sondas envían datos de tiempo de ejecución a POST /signals/runtime-facts/ndjson como transmisión NDJSON. Cada observación lleva el CAS URI para el artefacto subyacente.

Datos capturados por la sonda

symbol_id: identificador canónico de símbolo

code_id: identificador de sección de código

hit_count: frecuencia de ejecución

loader_base: dirección base en memoria

cas_uri: referencia direccionada por contenido

Las sondas envían datos de tiempo de ejecución a POST /signals/runtime-facts/ndjson como transmisión NDJSON. Cada observación lleva el CAS URI para el artefacto subyacente.

Comience con su propio conjunto de trabajo

Señale Stella Ops a una imagen que envíe hoy y lea los veredictos que firma. Si alcanzabilidad elimina menos de lo que afirma, usted también lo verá: cada eliminación conlleva su prueba.

Empieza gratis Ver documentación

Nivel gratuito: 3 entornos y hasta 100 análisis de nuevos digests por ventana móvil de 24 h, autohospedado. v1.0-RC1, versión candidata.