Accesibilidad como evidencia

Demuestre si el código vulnerable se llama realmente

Análisis de tres capas: gráficos de llamadas estáticas, coincidencia de símbolos binarios, sondas eBPF en tiempo de ejecución: produce DSSE firmado pruebas que reducen el 70-90% de los falsos positivos.

Análisis de tres capas

Cada capa proporciona evidencia progresivamente más sólida de que una función vulnerable es (o no) accesible desde su aplicación code.

Capa 1

Análisis estático de gráficos de llamadas

Extraer gráficos de llamadas de código de bytes, AST y código fuente. Rastree rutas desde puntos de entrada hasta símbolos vulnerables.

  • • Soporte de lenguajes: Go, Rust, C#, Java, Python, JavaScript, C/C++
  • • Maneja el despacho virtual, llamadas de interfaz y reflexión con aproximación conservadora
  • • Produce DAG con estado de accesibilidad por nodo
Capa 2

Análisis de símbolos binarios

Combina símbolos vulnerables con exportaciones binarias compiladas. Confirma que el código está realmente vinculado.

  • • Extracción de tablas de símbolos de ELF, PE, Mach-O
  • • Referencias cruzadas de información de depuración de DWARF/PDB cuando esté disponible
Capa 3

Sondas eBPF en tiempo de ejecución

Perfiles de producción opcionales. Captura invocaciones de funciones reales durante la ejecución.

  • • Instrumentación eBPF basada en Tetragon
  • • Registros symbol_id, code_id, hit_count, loader_base
  • • Preservación de la privacidad: no se capturan valores de argumentos

Resultado: 70-90 % menos falsos positivos. Concéntrese en 12 CVE accesibles en lugar de 487 teóricos.

Hash de nodo Se une

Las pruebas de accesibilidad se abordan en función del contenido para su deduplicación y verificación. Los hash de nodo permiten una diferenciación eficiente entre versiones.

Hash de nodo

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

Hash de ruta

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

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

Desconocidos como estado de primera clase

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

Cubo de accesibilidadPeso predeterminado
Punto de entrada1.0
Llamada directa0.85
Confirmado en runtime0.45
Desconocido0.5
Inalcanzable0.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.

DSSE Firmado Pruebas

Cada análisis de accesibilidad produce una prueba firmada criptográficamente almacenada en un almacenamiento dirigido a contenido.

  • DSSE sobre con in-toto Formato de predicado SLSA
  • Verificable por auditores sin acceso a la red
  • La reproducción determinista produce resultados de bits idénticos
  • Gráficos y seguimientos archivados sin conexión verificación

Rutas de almacenamiento dirigidas a contenido

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

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

eBPF Runtime Sondas

La instrumentación opcional basada en Tetragon captura las ejecuciones de funciones reales en producción, proporcionando la accesibilidad más alta evidencia.

Datos de sonda capturados

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

Sondas envíe observaciones a /api/v1/observations en lotes. Cada observación incluye el URI de CAS para el artefacto subyacente.

Listo para eliminar falsos positivos mediante ¿70-90%?

Instala Stella Ops y comienza a producir pruebas de accesibilidad firmadas con análisis de tres capas.