RS Runtime Security Observability + Control
Start Free Read Docs
eBPF-powered runtime security platform

Detect, investigate, and control runtime risk across Kubernetes, containers, and Linux hosts.

Runtime Security is a single platform that turns kernel-level eBPF telemetry into prioritized findings and enforceable policy. A lightweight sensor captures process, file, and network activity from every workload; the backend correlates signals, maps them to MITRE ATT&CK and PCI DSS, and pushes policy decisions back to the sensor. One console covers inventory, exposure, detection, investigation, and control — so teams go from alert to action without stitching tools together.

Start Free Explore Features Deployment Docs All Resources
Real-time Visibility eBPF-based process, file, and network telemetry mapped to pods, containers, and hosts.
Investigation Workflow Correlated threat, vulnerability, drift, and exposure signals with compliance-ready triage context.
Flexible Deployment Same sensor, same features on standalone Linux, Docker, Kubernetes, AWS EKS, or AWS ECS.

Feature pathways

See the core capabilities before rollout

Five capability pillars cover the full runtime loop: inventory and exposure, correlated detection, event evidence, policy controls, and flexible rollout. The sequence mirrors the navigation you will use in the console after login.

Step 2

Detection findings

Prioritize correlated threat, vulnerability, and drift findings. Each finding links to MITRE ATT&CK tactics and compliance mappings.

Step 3

Event timeline

Drill into process, file, and network events. Reconstruct kill chains with exact command lines, file paths, and destinations.

Standalone Docker K8s EKS ECS
Step 4

Policy controls

Convert findings into file, process, and network policies. Policies sync to sensors immediately — no redeploy needed.

Step 5

Deploy + scale

Roll out the same sensor across standalone hosts, Docker, Kubernetes, EKS, or ECS. One control plane observes all of them.

Feature-first onboarding with deployment included

Create your account, review findings and controls, then deploy sensors in the environments where you need live coverage. Every feature shown above maps to a section in the runtime console.

Open Sign-up Form Feature + Deployment Docs

Core feature stack

From runtime visibility to policy-driven response

Use one platform to observe activity, correlate risk, and apply controls without switching tools. Each card below maps to a section in the runtime console.

1) Runtime visibility

Stream eBPF-based process, file, and network telemetry across clusters, containers, and Linux hosts in near real time.

  • Unified inventory across pods, containers, and hosts
  • Exposure view (listening ports, SSH access, privileged runtimes)
  • Live event timeline with container and namespace context

2) Correlated detections

Group threat, vulnerability, drift, and process anomalies into prioritized findings with actionable context.

  • MITRE ATT&CK tactic and PCI DSS requirement mapping
  • CVE-linked runtime signals and image drift markers
  • Top process alerts ranked by severity and frequency

3) Policy response

Turn investigation output into file, process, and network policies that reduce repeat runtime risk.

  • File integrity monitoring with include/exclude paths
  • Process controls for binaries, args, and privilege changes
  • Network guardrails for DNS, egress, and IOC destinations

Feature deep dive

Detect and investigate from the same screen

Correlated signals help teams move from severity to event evidence quickly without exporting data between tools. Each finding below is a real category the platform surfaces — with the underlying events one click away.

MITRE ATT&CK T1059 Command and Scripting Interpreter 18 events across production namespaces in the last 30 minutes.
PCI DSS Requirement 10.2 high-risk event cluster 9 audit-linked events with privileged command execution.
Vulnerability CVE-linked runtime signal in payment service image Image hash drift observed after container restart.
Exposure Unexpected open admin port on non-managed container Port surfaced after deployment policy bypass.

Process Alerts

Prioritized by severity and recent activity
  • bash spawned by nginx in production containerhigh
  • curl executed with external IOC domain argumentmedium
  • chmod 777 on executable path under /usr/local/binmedium
  • scp initiated from host to unknown destinationlow

Runtime control

Policy controls that close the loop

Apply controls where detections occur and keep observability plus response synchronized. Policies are defined in the console and pushed to sensors through the policy fetch loop — no sensor restart, no manifest rebuild.

File Monitoring Control

Watch sensitive files, configuration paths, and drift-prone binaries with policy scoping.

  • Include and exclude path rules with glob support
  • Read, write, create, delete, and rename filters
  • Policy templates for /etc, /usr/bin, and container image layers
  • Per-host, per-namespace, or per-container targeting

Process Monitoring Control

Control runtime execution with process-based include/exclude patterns and context filters.

  • Binary, argv, and command-pattern controls
  • Privilege escalation (setuid/setgid, capability change) focus
  • Shell-spawn detection inside service containers
  • Parent/child chain rules to catch living-off-the-land abuse

Network Monitoring Control

Monitor DNS and egress behavior with policy-level baselines for runtime activity.

  • Protocol (TCP/UDP/DNS) and endpoint-focused rules
  • Service and namespace segmentation
  • IOC-aware lookups against known-bad domains and IPs
  • Listening-port tracking for exposed services

Deployment coverage

Deploy your way without losing feature parity

All deployment paths feed the same findings, event timeline, and policy control workflows. Pick the target that matches where your workloads run today — the sensor, the data plane, and the console are identical across paths.

Standalone

Linux Host Binary

Install directly on Linux hosts for the fastest proof of value. Full host-level visibility (process, file, network) plus container awareness via cgroups.

Best for: bare-metal servers, VMs, and edge hosts without an orchestrator.

Docker

Docker Runtime

Run as a privileged container. The sensor mounts the host PID namespace and keeps full event plus control coverage for every container on the host.

Best for: single-node Docker hosts and developer environments.

Kubernetes

K8s Clusters

Deploy as a DaemonSet so every node runs one sensor. Namespace, pod, label, and container metadata flow into findings and policies.

Best for: self-managed Kubernetes, OpenShift, and k3s clusters.

EKS

AWS EKS

AWS-tailored DaemonSet install with IAM-aware context. Preserves all detection, investigation, and policy features on managed Kubernetes.

Best for: AWS shops running managed Kubernetes with regional compliance.

ECS

AWS ECS

Deploy on ECS EC2 launch type for task-level runtime visibility. Each task definition ships with sensor sidecar for identical telemetry.

Best for: teams standardized on ECS instead of Kubernetes.

Architecture diagram

A simple view for end users

Your workloads keep running where they already live. A small runtime sensor is added, and that sensor sends security activity into the Runtime Security console for review. The flow is intentionally one-way for telemetry and one-way for policy — there is no proxy, no agent-to-agent mesh, and no external dependency.

Your environment

Linux hosts, Docker, Kubernetes, EKS, or ECS workloads where your applications already run. No code changes and no reboots required.

Runtime sensor

Lightweight eBPF-backed sensor installed via one deployment command. Watches process, file, and network activity at the kernel level.

Runtime Security console

Events, findings, policy controls, inventory, and deployment status live here. Log in to overview.php to see all of them in one place.

Deployment diagram

The rollout sequence using the same commands as `overview.php`

These examples mirror the real commands shown after login. Replace the placeholders with your customer UUID and pin, or use the generated values from the rollout page.

1

Choose a path

Pick Linux, Docker, Kubernetes, EKS, or ECS based on where your application runs.

2

Use your account values

The command includes `CUUID` or `code` plus `PIN` so the new sensor connects to the right account.

3

Run the command

Install the sensor in the target environment with the matching command shown below.

4

Verify visibility

Open the console and confirm new findings, timeline activity, and policy coverage start to appear.

Static landing pages cannot inject per-customer secrets, so this page shows the exact rollout patterns from `overview.php` with placeholders: `YOUR_CUSTOMER_UUID` and `YOUR_PIN`.

Kubernetes

Direct cluster install.

kubectl create -f "https://runtimesecurity.in/k8s.php?code=YOUR_CUSTOMER_UUID&pin=YOUR_PIN"

Amazon EKS

Configure cluster access, then install.

aws eks update-kubeconfig --region <region> --name <cluster-name>
kubectl create -f "https://runtimesecurity.in/eks.php?code=YOUR_CUSTOMER_UUID&pin=YOUR_PIN"

Amazon ECS

EC2 launch type only.

curl -fsSL "https://runtimesecurity.in/ecs.php?code=YOUR_CUSTOMER_UUID&pin=YOUR_PIN" -o bpfaudit-ecs-task.yaml
aws ecs register-task-definition --cli-input-yaml file://bpfaudit-ecs-task.yaml
aws ecs update-service --cluster <ecs-cluster> --service <service-name> --force-new-deployment

Linux host

Run the downloaded binary on the host.

wget https://runtimesecurity.in/download/bpfagent-amd64
CUUID=YOUR_CUSTOMER_UUID PIN=YOUR_PIN ./bpfagent-amd64

Docker

Run the sensor as a privileged container.

docker run --rm -itd --privileged --pid=host --env CUUID=YOUR_CUSTOMER_UUID --env PIN=YOUR_PIN docker.io/bpfaudit/bpfaudit:latest

Merged architecture page

Full architecture and technical flow (inline)

The architecture content is now fully inlined in this page. This includes platform deployment architecture and the technical sensor-to-AI data path.

Read direction: runtime telemetry flows left to right. Policy updates flow right to left.

Technical diagram

Sensor to AI data path

go sensor -> eBPF hooks -> kprobe/tracepoint -> ringbuffer -> go processing -> backend -> database -> AI evaluation -> overview.php

Techniques used

What this project uses under the hood

The sensor, the ingest pipeline, and the console rely on a small set of well-understood kernel and user-space techniques. The platform and data-path diagrams above show how they fit together.

eBPF kernel instrumentation

Core runtime visibility is built with eBPF programs and maps, loaded from Go with the Cilium eBPF libraries.

kprobe and kretprobe hooks

Hooks on kernel paths such as file, process, and network functions capture low-level behavior with entry/return context.

LSM policy hooks

Linux Security Module hooks enforce and audit policy decisions for actions like file permission, create, unlink, rename, and connect.

Ring buffer event transport

Kernel events are published via eBPF ring buffers and consumed by Go readers for user-space processing and forwarding.

Go normalization pipeline

Go decodes events, enriches container and namespace context, applies filters and dedupe, then batches to backend APIs.

Dynamic policy fetch and apply

Policy is pulled from backend endpoints and applied to process and network rule maps for audit/block behavior.

MITRE and compliance mapping

Event classification maps activity to MITRE ATT&CK tactics and PCI DSS-relevant patterns for faster triage.

Additional probes in modules

Project modules also use eBPF iterators and user-space probes (uprobes/uretprobes), including SSL-focused telemetry.

Technical note: event capture starts in kernel hooks, crosses through ringbuffer to Go user-space processing, then backend/DB/AI enriches before rendering in overview.php.

Ready to evaluate features in your own environment?

Create an account, review findings and controls, then deploy sensors with the method that matches your platform.

Start Sign-up Read Full Docs All Resources

Resources + docs

Every page you may need, in one place

The short landing page above is the entry point. These deeper pages cover implementation, console walkthroughs, architecture, and the open-source inventory tool.

Docs

Product documentation

First-time onboarding path (sign up → verify → deploy → validate → control), deployment tracks, detection domain table, and operator FAQs.

Open docs.html

Sign-up

Create account

Minimal form for full name, email, and password. After email verification you can log in and access the full console (or use the modal on this page).

Open signup.html

Log-in

Runtime console (overview.php)

The live console with inventory, findings, events, process alerts, policy controls, and deployment helpers (per-tenant commands for every deployment path).

Deployment PDFs

Printable deployment diagrams

One-page PDFs per target for review boards and change tickets.

Standalone Docker K8s EKS ECS

Contact

Talk to the team

Questions about onboarding, compliance scope, or a PoC in your own environment? Drop us a note using the contact form.

Open contact form