Listen to this Post
Introduction:
For years, security compliance programs have operated on a foundation of assumptions rather than facts. A library appears in a Software Bill of Materials (SBOM), so it must be a risk. A scanner flags a CVE, so it must be remediated immediately. This build-time theory of security has created an epidemic of alert fatigue, with security teams drowning in thousands of “vulnerabilities” that may never actually execute in production. According to Oligo Security, more than 90% of vulnerabilities flagged by static tools never execute in production environments. The industry is waking up to a fundamental truth: compliance needs to evolve from build-time theory to runtime reality.
Learning Objectives:
- Understand the critical difference between build-time SBOM assumptions and runtime execution reality
- Learn how Deep Application Inspection and eBPF technology can validate true exploitability
- Master the practical implementation of runtime vulnerability management using open-source tools
- Discover how to generate VEX artifacts and automate compliance reporting based on runtime evidence
- Implement strategies to reduce vulnerability backlogs by 90% or more within 48 hours
You Should Know:
- The SBOM Illusion: Why Static Inventories Lie to You
A Software Bill of Materials (SBOM) has become the gold standard for software supply chain compliance, mandated by Executive Order 14028 and the EU Cyber Resilience Act. But an SBOM is fundamentally a static inventory—it catalogs everything in the kitchen, every utensil, ingredient, and appliance available for use. What it cannot tell you is what actually made it into the finished cake.
The gap between what is installed and what executes in production is where security programs break down. Take the XZ Utils backdoor (CVE-2024-3094) as a real-world example. The malicious code was present in the SBOM, appearing in thousands of container images. However, it remained dormant until specific runtime conditions were met and never executed in most environments. An SBOM alone would have flagged it as a critical risk; runtime observation would have shown it was harmless in your specific deployment.
This is why industry leaders are now distinguishing between SBOM (what’s installed) and RBOM—Runtime Bill of Materials (what actually executes). The distinction matters because remediation capacity is limited. Security teams cannot patch everything, and they shouldn’t have to. The question isn’t whether you have an SBOM; it’s whether your SBOM is telling you the truth.
Practical Verification: Checking What’s Actually Running
To move from assumptions to truth, you need to observe what’s executing in your environment. Here are practical commands to inventory running processes and their dependencies:
Linux – Identify Running Processes and Their Libraries:
List all running processes with their dependencies
lsof -P -i -1 | grep LISTEN
Check which libraries are loaded by a specific process
lsof -p [bash] | grep '.so'
Monitor system calls to see what's actually executing
strace -p [bash] -e trace=open,openat,execve -o /tmp/runtime_trace.log
Use eBPF-based tools for deep inspection (requires bpftrace)
bpftrace -e 'kprobe:do_execve { printf("%s executed %s\n", comm, str(args->filename)); }'
Windows – Inventory Running Processes and Loaded Modules:
List all running processes with their loaded modules
Get-Process | ForEach-Object {
$<em>.Modules | ForEach-Object {
[bash]@{Process=$</em>.ProcessName; Module=$_.FileName}
}
} | Export-Csv -Path runtime_inventory.csv
Check specific process dependencies
Get-Process -1ame "process_name" | Select-Object -ExpandProperty Modules
Use Sysinternals Process Monitor for runtime analysis
Download from: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
Container Runtime Inspection:
Check what's actually running inside a container docker exec [bash] ps aux Inspect loaded libraries inside container docker exec [bash] lsof -p 1 For Kubernetes, use kubectl to exec into pods kubectl exec -it [bash] -- /bin/sh -c "ps aux && lsof -i"
2. Deep Application Inspection: Seeing What Scanners Miss
Traditional security tools—SAST, SCA, DAST, and CSPM—all share a fundamental limitation: they reason from build-time theory rather than runtime execution. They can tell you what might be vulnerable, but they cannot tell you what is actually exploitable in your specific environment.
Deep Application Inspection (DAI) represents a paradigm shift. Rather than guessing which risks get realized at runtime, DAI observes actual code execution at the library and function level. This granular approach maps exactly which parts of the codebase—including third-party dependencies—are active in production, identifying provable risk rather than theoretical vulnerability.
Oligo’s implementation of DAI uses patented eBPF innovations to achieve unprecedented observability with less than 1% CPU overhead. The technology observes code execution, OS processes, and even AI behavior, all non-intrusively and without needing access to source code.
The Call Stack Revolution
When a vulnerable function actually executes at runtime, DAI surfaces the full call stack that led to that execution. This transforms the security conversation entirely. Instead of debating whether a vulnerability might be exploitable, security teams can point to concrete evidence: the vulnerable code didn’t just exist—it ran.
For developers, this changes everything. It’s no longer about fixing something “just in case.” It’s about fixing something you can see running. This shared understanding removes friction, and remediation happens faster because the evidence is concrete, not theoretical.
Setting Up Runtime Observability with Open Source Tools
While commercial platforms like Oligo provide enterprise-grade DAI, you can begin implementing runtime observability with open-source tools:
Using Falco for Runtime Security Monitoring:
Install Falco (runtime security monitoring) curl -s https://falco.org/repo/falcosecurity-packages/install-binary | bash Run Falco with default rules sudo falco -r /etc/falco/falco_rules.yaml Custom rule to detect unexpected library loads Add to /etc/falco/falco_rules.local.yaml: - rule: Unexpected Library Load desc: Detect when a process loads an unexpected shared library condition: > evt.type=open and evt.dir=< and fd.name contains ".so" and not proc.name in (trusted_processes) output: "Unexpected library loaded (process=%proc.name file=%fd.name)" priority: WARNING
Using eBPF for Function-Level Tracing:
Install BCC tools for eBPF tracing apt-get install bpfcc-tools linux-headers-$(uname -r) Trace library function calls in real-time trace-bpfcc 'do_sys_open "%s", arg1' Monitor process execution with arguments execsnoop-bpfcc Profile function calls in a specific process profile-bpfcc -p [bash] -af 30
- The 90% Noise Reduction: Prioritizing What Actually Matters
The numbers are staggering. In 2024 alone, more than 48,000 new CVEs were disclosed. For AppSec teams, that number isn’t just impressive—it’s exhausting. Every new CVE triggers triage, analysis, and often a conversation with developers, even when the real-world risk is unclear.
Oligo Security reports that its runtime platform reduces vulnerability backlogs by 90% to 99% within 48 hours. This isn’t magic—it’s simple math. When you filter findings through runtime evidence, business context, and actual execution paths, the overwhelming majority of “vulnerabilities” simply don’t matter.
Why Runtime Evidence Changes Prioritization
Traditional vulnerability management treats every CVE as potentially critical. Runtime evidence changes this fundamentally:
- Reachable Risk vs. Theoretical Vulnerability: A theoretical vulnerability exists in code or configuration. Reachable risk exists when the vulnerable path is active in production and can be exercised by an attacker. Only reachable risk requires urgent response.
-
Exploitability as the Basis for Prioritization: When teams know which functions run in production, they can suppress low-value noise and focus on issues that affect live services. This improves response speed and makes remediation queues more credible to engineering teams.
-
Call Stack Evidence: Runtime call stacks provide definitive proof that vulnerable code has executed, not when risk is inferred. This transforms AppSec from a messenger of endless alerts into a trusted source of high-confidence insight.
Practical Implementation: Vulnerability Prioritization Workflow
Script to correlate running processes with known CVEs
!/bin/bash
runtime_prioritize.sh - Prioritize vulnerabilities based on runtime execution
Get list of running processes and their dependencies
for pid in $(ps -eo pid=); do
if [ -r /proc/$pid/maps ]; then
cat /proc/$pid/maps | grep '.so' | awk '{print $6}' | sort -u >> /tmp/runtime_libs.txt
fi
done
Compare with known vulnerable libraries (example)
This is a simplified example - in practice, use SBOM + CVE databases
while read lib; do
if grep -q "$lib" /path/to/vulnerable_libraries.csv; then
echo "ALERT: Running process uses vulnerable library: $lib"
fi
done < /tmp/runtime_libs.txt
- Automating SBOM and VEX Reporting with Runtime Evidence
Compliance requirements continue to expand. Executive Order 14028, FedRAMP, CMMC 2.0, and SOC 2 all demand transparency into software supply chains. But generating SBOMs and VEX (Vulnerability Exploitability Exchange) artifacts from static analysis alone perpetuates the assumption problem.
Runtime evidence transforms compliance from a checkbox exercise into a meaningful security practice. By binding SBOM artifacts to runtime telemetry, organizations can transform CSAF-VEX generation from static disclosure into execution-grounded exploitability assessment. Research has shown that this approach achieves an F1-score of 0.93, reduces false positives by up to 42%, and alters exploitability outcomes in 31% of cases.
Generating Runtime-Verified SBOM with Open Source Tools
Using Syft to generate SBOM from a running container
syft scan docker://nginx:latest -o cyclonedx-json > sbom.json
Using Trivy to scan a running container with runtime context
trivy image --severity CRITICAL,HIGH nginx:latest
Generate VEX document based on runtime verification
Example using OpenVEX (https://github.com/openvex)
cat > vex.json << EOF
{
"@context": "https://openvex.dev/ns/v0.2.0",
"author": "Your Security Team",
"timestamp": "$(date -Iseconds)",
"statements": [
{
"vulnerability": {"name": "CVE-2024-XXXX"},
"products": [{"@id": "pkg:docker/nginx@latest"}],
"status": "not_affected",
"status_notes": "Vulnerable function not executed at runtime"
}
]
}
EOF
Continuous Compliance Monitoring
For enterprise environments, implement continuous runtime compliance monitoring:
Kubernetes admission controller for runtime policy enforcement
Using OPA (Open Policy Agent) with runtime data
cat > policy.rego << EOF
package kubernetes.admission
deny[bash] {
input.request.kind.kind == "Pod"
lib := input.request.object.spec.containers[bash].image
not runtime_verified(lib)
msg = sprintf("Image %v lacks runtime verification", [bash])
}
runtime_verified(lib) {
Check against runtime telemetry database
data.runtime_telemetry[bash]
}
EOF
- From Compliance to True Security: The Runtime Future
The shift from build-time theory to runtime truth represents more than a technological evolution—it’s a fundamental rethinking of what security means. Google’s 2026 M-Trends report confirms a long-standing industry shift: protection needs to operate in real time, at the runtime level, to keep pace with modern attackers. Exploitation remains the number one initial access vector, accounting for 32% of intrusions.
What Undercode Say:
- Key Takeaway 1: SBOMs Are Not Enough — A static inventory of components provides visibility but not truth. Without runtime validation, compliance programs operate on assumptions that create more noise than security value. Organizations must evolve from “what’s installed” to “what’s actually running.”
-
Key Takeaway 2: Runtime Evidence Transforms Security Culture — When developers can see call stacks proving that vulnerable code actually executed, the security conversation shifts from theoretical debate to evidence-based action. This removes friction, accelerates remediation, and builds trust between security and engineering teams.
-
Key Takeaway 3: The 90% Noise Reduction Is Real — By filtering vulnerability findings through runtime evidence, organizations can reduce backlogs by 90% or more within 48 hours. This isn’t about ignoring risks—it’s about focusing limited resources on risks that actually matter.
-
Key Takeaway 4: Compliance Must Become Continuous and Runtime-Aware — Regulations are making SBOMs mandatory, but a static PDF is futile if you cannot map components in real-time. The future of compliance lies in continuous, execution-verified reporting that proves not just what’s installed, but what’s actually running and exploitable.
-
Key Takeaway 5: AI and Dynamic Systems Demand Runtime Visibility — AI applications introduce highly non-deterministic behavior that static scanners cannot track. Agentic AI systems create exploitability conditions that cannot be inferred from static SBOMs. Runtime security is the only way to secure modern, dynamic application environments.
Prediction:
-
+1 The runtime security market will experience explosive growth over the next 24 months, with traditional SCA and SAST vendors acquiring or building runtime capabilities to remain competitive. Organizations that adopt runtime-first security strategies will gain significant competitive advantage through faster development cycles and reduced security overhead.
-
+1 Regulatory frameworks will evolve to require runtime-verified SBOMs and VEX artifacts, not just static inventories. The EU Cyber Resilience Act and future iterations of Executive Order 14028 will likely mandate execution-grounded exploitability assessment, creating a new compliance baseline.
-
-1 Organizations that continue to rely solely on build-time security tools will face increasing security debt and alert fatigue. As CVE disclosures continue to rise—submissions in early 2026 are running nearly one-third higher than the same period last year—static-only approaches will become completely unmanageable.
-
+1 eBPF-based runtime security will become the standard for cloud-1ative protection, with major cloud providers embedding runtime observability directly into their platforms. The technology’s ultra-low overhead (<0.5% CPU) and deep visibility make it ideal for production environments.
-
-1 The gap between security theory and runtime reality will be increasingly exploited by attackers. As demonstrated by the XZ Utils backdoor, attackers understand that dormant code in SBOMs goes unnoticed. Organizations without runtime visibility will remain vulnerable to supply chain attacks that never trigger static alerts.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Most Compliance – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
