Open source / Evidence-driven Linux security

Don't tell me my application is insecure — show me why.

See what an attacker can learn from your application at runtime.

Explore on GitHub ↗ Explore the research →

Static ELF inspection ptrace / eBPF Process memory Evidence & lineage

RuntimeXRay is an evidence-driven security analysis tool for compiled Linux applications. It combines static ELF inspection, runtime tracing, process-memory analysis, lineage, and graph-based detection to produce security findings backed by observable evidence.

The goal is not simply to produce more warnings. RuntimeXRay tries to answer:

What happened, where did it happen, and what evidence proves it?

🤖 “The AI wrote it. But what did it actually build?”

AI can produce working code in seconds. RuntimeXRay examines the compiled result and the behavior that actually occurs during execution.

📦 “You didn’t write that library. Do you really know what it does?”

RuntimeXRay can observe supported behavior from third-party, legacy, or binary-only components without requiring complete source visibility.

🧩 “Who still understands this entire application?”

Large systems accumulate years of code, dependencies, configuration paths, helper processes, and operational assumptions. RuntimeXRay turns some of those assumptions into observable evidence.

⚡ “Can security review keep up with the release cycle?”

Runtime evidence can complement source review by showing which supported behaviors actually occurred in a controlled execution.

Evidence, not intent

RuntimeXRay deliberately separates observation from conclusion.

For example, observing a connection to a network endpoint does not automatically mean exfiltration. Accessing a sensitive file does not automatically mean compromise.

RuntimeXRay aims to make the strongest claim that the available evidence supports — and no stronger.

Research / Stage D

Inspect memory. Don't change it.

Explore our measured comparison of Linux remote-memory readers, including performance, fork copy-on-write effects, and access semantics.

View benchmarks →

What RuntimeXRay can do today

Unified CLI

runtimexray analyze
runtimexray trace
runtimexray mem

analyze performs static ELF inspection.

trace performs runtime tracing using either ptrace or eBPF.

mem scans an authorized running process for supported sensitive values.

Static analysis

ELF 32-bit and 64-bit parsing
x86_64 and ARM64 architecture detection
NX / executable-stack detection
PIE detection
RELRO detection: Disabled / Partial / Full
Stack-canary detection
Dangerous and legacy imported API detection
CWE references where justified
Text and JSON reporting

Dynamic tracing

ptrace backend
eBPF backend using Linux raw_syscalls tracepoints
Syscall observation
Process and thread tracking
fork / vfork / clone handling
exec tracking
Process-instance identity
Exec-generation tracking
File-access observations
Network endpoint observations
Selected syscall-buffer inspection
FD/resource tracking
Pipe identity and explicit DataFlow relationships
Optional memory scanning with --scan-memory

Memory scanning

/proc/<pid>/cmdline
/proc/<pid>/environ
Readable process-memory mappings
Password-like values
API-key / token / secret-like values
Private-key markers
Page scan limiting with --max-pages

Sensitive values are redacted by default.

RuntimeXRay uses a per-run HMAC-SHA256 fingerprint so the same exact sensitive value can be correlated within one analysis without normally printing the raw secret.

Evidence correlation

File → memory → socket

RuntimeXRay can currently correlate the same exact sensitive value across:

source file
    ↓
read / receive
    ↓
exact sensitive-value fingerprint
    ↓
independent process-memory observation
    ↓
write / send
    ↓
socket destination

The memory evidence must come from an independent memory scan. RuntimeXRay does not invent the memory leg merely because the same value appeared in a syscall buffer.

Current confidence: exact-fingerprint-match

Cross-process pipe-chain correlation

RuntimeXRay can also follow the same sensitive value across multiple explicit pipe DataFlow boundaries:

Process A
    │
    ▼
  pipe 1
    │
    ▼
Process B
    │
    ▼
  pipe 2
    │
    ▼
Process C

This rule requires explicit pipe DataFlow edges, matching exact fingerprints, distinct process instances, and temporally compatible transfers.

Current confidence: explicit-pipe-dataflow-chain

Current architecture

Static ELF collection
        │
Runtime tracing ─────────┐
        │                │
Memory scanning ─────────┤
                         ▼
                   LineageGraph
              Observations + Edges
                         │
                         ▼
              DetectionRuleRegistry
                         │
                         ▼
                DetectionEngine
              Primary → Composite
                         │
                         ▼
                      Findings
                         │
                         ▼
                NarrativeBuilder
                         │
                         ▼
                 Text / JSON report

Collectors record facts. Detection rules derive security conclusions. Narrative generation explains those conclusions. Reporting serializes the result.

Built-in detection rules

Primary rules:

builtin.hardening
builtin.dangerous_api
builtin.sensitive_file_access
builtin.network
builtin.sensitive_data_presence

Composite rules:

builtin.sensitive_data_flow
builtin.sensitive_value_cross_process_pipe_chain

Extensibility

The current extension point is IDetectionRule. Rules are registered through DetectionRuleRegistry.

Custom rules currently require source integration and rebuilding RuntimeXRay.

Dynamic external .so loading is planned, but is not implemented today.

Common options

--report FILE
--json FILE
--log-level LEVEL
--log-file FILE
--min-severity LEVEL
--show-secrets

Severity levels:

Critical
High
Medium
Low
Info

Default minimum severity: Medium

Tests and architecture support

Core suite

The current core test suite contains 56 tests when ptrace tests are enabled and eBPF runtime tests are excluded.

GitHub Actions runs the core suite natively on:

x86_64
ARM64

Dedicated eBPF runtime suite

Dedicated jobs execute 16 eBPF runtime/integration tests on each architecture:

x86_64
ARM64

Skipped eBPF runtime tests are treated as CI failures.

Current scope

Linux ELF only
x86_64 and ARM64
Authorized analysis in controlled environments
Runtime behavior is limited to executed paths
RuntimeXRay is not a sandbox
RuntimeXRay does not prove exploitability
RuntimeXRay does not prove malicious intent
RuntimeXRay does not yet provide general-purpose taint tracking
Exact secret lifetime measurement is not implemented yet
Arbitrary function-level tracing is not implemented yet

Experimental

Sensitive-object correlation beyond simple isolated findings
Cross-process sensitive-value propagation through explicit pipe chains
Memory scanning under larger workloads
Broader narrative generation
eBPF behavior across different kernel configurations

Planned

Broader sensitive-value lineage
Memory-copy correlation
Sensitive-value lifetime checkpoints
Additional sinks and sources
Additional IPC/resource models
Network-boundary policy
Static/runtime evidence correlation
Release-to-release behavioral comparison
HTML reports
External dynamic detection-rule loading
Optional evidence-grounded AI explanations
Running-process attach
PE support
Mach-O support
Improved local and air-gapped packaging

Evidence-first AI

RuntimeXRay may eventually use AI to explain existing evidence. AI is not intended to become the evidence source.

Observed evidence
       ↓
Detection rules
       ↓
Structured Findings
       ↓
Narrative
       ↓
Optional AI explanation

Raw secrets must not be sent to an external AI service by default.

Documentation & project links

GitHub Repository README Architecture Threat Model Security Checks Extending Detection Rules Integration Examples Memory Reader Benchmarks Use Cases Roadmap FAQ