Alcanzabilidad como evidencia
Análisis de tres capas: grafos de llamadas estáticos, coincidencia de símbolos binarios y sondas eBPF en tiempo de ejecución. Produce pruebas firmadas con DSSE que reducen significativamente los falsos positivos.
Lo que esto significa para su negocio
Corrija solo las vulnerabilidades que su aplicación realmente puede alcanzar — omita el resto. Stella demuestra qué CVEs son alcanzables para que su equipo se concentre en riesgos reales, no en ruido de escáneres. ReachabilityAnálisis que demuestra si el código vulnerable es realmente llamado por su aplicación — filtrando falsos positivos del ruido de escáneres
Hasta 70-90%
Reducción típica de ruido
El rango observado varía según el stack y la cobertura.
3
Capas de análisis
Grafos de llamadas estáticos, símbolos binarios, sondas eBPF en tiempo de ejecución
100%
Firmado y reproducible
Cada veredicto de alcanzabilidad es evidencia firmada con DSSE
Cada capa aporta evidencia progresivamente más sólida de que una función vulnerable es (o no) alcanzable desde el código de tu aplicación. CVECommon Vulnerabilities and Exposures – un identificador único para una vulnerabilidad de seguridad conocida públicamente
Extrae grafos de llamadas de bytecode, AST y código fuente. Rastrea rutas desde puntos de entrada hasta símbolos vulnerables.
Cruza símbolos vulnerables con exportaciones binarias compiladas. Confirma que el código está realmente vinculado.
Perfilado opcional en producción. Captura invocaciones reales de funciones durante la ejecución.
eBPFExtended 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 TetragonResultado: significativamente menos falsos positivos. Concéntrate en 12 CVE alcanzables en lugar de 487 teóricas.
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).
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 |
|---|---|
| Punto de entrada | 1.0 |
| Llamada directa | 0.85 |
| Confirmado en runtime | 0.45 |
| Desconocido | 0.5 |
| Inalcanzable | 0.0 |
Puntuación final = max(bucket_weights) en todos los caminos. Los nodos desconocidos contribuyen a la puntuación de riesgo en lugar de ser ignorados.
Antes de habilitar el bloqueo duro en producción, valide la cobertura en su propio corpus de código. La siguiente matriz describe cómo evaluar cada ruta de lenguaje/tiempo de ejecución y cómo se deben tratar las incógnitas.
| Idioma/tiempo de ejecución | Ruta de llamada estática | Evidencia binaria/símbolo | Evidencia en tiempo de ejecución | Puerta predeterminada cuando se desconoce |
|---|---|---|---|---|
| Ir, óxido, C/C++ | Validar la extracción de rutas de llamadas directas y transitivas | Validar la precisión de coincidencia de símbolo/ID de compilación | Confirmación eBPF opcional para servicios de alto riesgo | Revisar o bloquear hallazgos críticos por política |
| Lenguajes Java y JVM | Validar la accesibilidad a nivel de método y los casos de envío dinámico | Validar la asignación de código de bytes/símbolo jar | Seguimientos en tiempo de ejecución recomendados para caminos reflectantes | Enrutar desconocidos al carril de revisión manual |
| .NETO | Validar el gráfico de llamadas de IL y el linaje de paquetes | Validar la resolución de PDB/símbolo en versiones de lanzamiento | Confirmación de tiempo de ejecución para escenarios recortados/AOT | Revisar las incógnitas antes de permitir una decisión |
| Nodo, Python, Ruby, PHP | Validar puntos de entrada del marco y límites de importación dinámicos | La evidencia de símbolos es parcial por diseño para el despacho dinámico | Se recomienda encarecidamente realizar seguimientos en tiempo de ejecución | Mantener desconocido como estado explícito y requerir aprobación |
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.
DSSEDead Simple Signing Envelope – un estándar simple y flexible para firmar datos arbitrarios con firmas criptográficas con in-totoUn 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 SLSASupply-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.zstCada análisis de alcanzabilidad produce una prueba firmada criptográficamente, almacenada en un almacenamiento direccionado por contenido. DSSEDead Simple Signing Envelope – un estándar simple y flexible para firmar datos arbitrarios con firmas criptográficas
DSSEDead Simple Signing Envelope – un estándar simple y flexible para firmar datos arbitrarios con firmas criptográficas con in-totoUn 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 SLSASupply-chain Levels for Software Artifacts — un marco para garantizar la integridad de los artefactos de software a lo largo de la cadena de suministro)Rutas de almacenamiento direccionadas por contenido
cas://reachability_graphs/<hh>/<sha>.tar.zst
cas://runtime_traces/<hh>/<sha>.tar.zst
La instrumentación opcional basada en Tetragon captura ejecuciones reales de funciones en producción, proporcionando la evidencia de alcanzabilidad más sólida.
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 observaciones a /api/v1/observations en lotes. Cada observación incluye el URI de CAS para el artefacto subyacente.
Instala Stella Ops y comienza a producir pruebas de alcanzabilidad firmadas con análisis de tres capas.