Modern development teams increasingly rely on open-source packages to rapidly build and deploy applications. In fact, most, if not all applications consist of far more open-source and 3rd-party code than the code that’s written by their dev teams.
Many open-source libraries used for software development depend in turn on other libraries, creating large chains of transitive dependencies, which continually introduce thousands of potential vulnerabilities that must be assessed to effectively manage and mitigate risks.
As a result, many companies now incorporate security measures and SCA tools into their CI/CD pipeline to reduce their open-source risk, making developers and security teams responsible for delivering secure applications, creating built-in friction and competition for resources that naturally impact engineering velocity.
However, for many DevSecOps and AppSec teams, open source risk management is a daily battle where they are reactive to a flood of security alerts and incidents—with a low signal-to-noise ratio (10-20%) and a high rate of false positives—wasting significant development and security resources. They lack the essential data and context required to prioritize vulnerabilities based on their impact on application risk profiles.
SCA tools leave companies unaware of actual application risks
The AppSec market is saturated with Software Composition Analysis (SCA) tools, which are increasingly adopted by software development teams to track and analyze open-source components brought into a project.
Traditional SCA tools are static by nature, scanning an application’s codebase and related artifacts to discover all related components, their supporting libraries, and their direct and transitive dependencies—and correlating them with known vulnerability databases to surface vulnerabilities and potential exploits.
SCA tools also help identify licenses included in open source packages, deprecated dependencies, and generate a software bill of materials (SBOM).
While they help you understand open-source risks, traditional SCA tools fall short in several key areas:
- Surface too many vulnerabilities without proper prioritization—many vulnerabilities can have the same severity grade, often classified as high-risk.
- Leave a major gap in coverage—static data is by nature limited compared to dynamic – e.g., it can’t determine if an actual vulnerable package is indeed used.
- High rate of false positives—they alert on every vulnerability regardless of whether it’s exploitable or exists in production.
It’s important to remember that as an AppSec engineer, the real goal of SCA tools isn’t to find vulnerabilities in your dependencies—but to help you understand actual application risks, properly prioritize vulnerabilities, and remediate them!
When you patch vulnerabilities solely based on severity, you’re doing a lot of work that has only a marginal impact on your security posture, even after critical vulnerabilities are addressed.
With traditional SCA tools, AppSec and DevSecOps teams lack the information to decide whether a vulnerability is worth mitigating. Every potential threat must be investigated to determine whether it is real—but wait, isn’t that the job SCA tools are supposed to do?
SCA transitions from static to dynamic with eBPF
As open source threats continue to evolve, and security and development teams increasingly compete for attention, enterprise customers are demanding SCA solutions that provide reliable, accurate, and actionable insights without slowing down the development process.
Over the last few years, enabling technologies such as eBPF have matured and proven themselves in production environments at Big Tech companies:
- Microsoft uses eBPF to enhance the observability and inspection of processes within Kubernetes
- Google uses eBPF for security auditing, packet processing, and performance monitoring
- Netflix has developed a network observability sidecar called Flow Exporter that uses eBPF tracepoints to capture TCP flows at near-realtime
- Meta uses eBPF to process and load-balance every packet coming into their data centers
- LinkedIn has deployed an eBPF agent for infrastructure observability, called Skyfall, across almost all servers within their datacenter fleet
eBPF is used extensively to drive a wide variety of use cases:
- Providing high-performance networking and load-balancing
- Extracting fine-grained security observability data at low overhead
- Helping application developers trace applications
- Providing insights for performance troubleshooting
- Preventive application and container runtime security enforcement
Today, eBPF is being widely adopted by existing and new AppSec players to deliver the next generation of dynamic SCA tools, which leverage runtime intelligence to determine actual application risks in production, reduce alert noise, and help developers prioritize vulnerabilities.
Using dynamic SCA tools, developers can get detailed information about vulnerability existence and exploitability in production, so they can focus on mitigating the most critical threats first.
However, even SCA tools that leverage eBPF have limitations:
- eBPF is limited in its access to applicative context (and it’s potentially risky).
- eBPF can’t be used in environment where it’s not possible to run in a privileged mode (EKS Fargate, GKE Autopilot), or where the kernel isn’t accessible (serverless).
This gap is exactly where Helios’ full-stack approach to observability—which combines data from the application, kernel, and platform levels for end-to-end visibility—and deep runtime collection capabilities come into play.
Full-stack runtime: observability and security come together
The Helios platform was created as a dev-first observability platform to help Dev and Ops teams find and fix issues in distributed applications more quickly. Helios leverages powerful instrumentation techniques to provide traces and correlate them with logs and metrics, enabling end-to-end app visibility and quicker troubleshooting. Helios is recognized for giving developers the granular, actionable telemetry data they need for observability, debugging, and testing purposes, so they can confidently ship code at high velocity. Salt Security, for example, has slashed detection and resolution time by half with Helios.
At Helios we’re always looking for ways to apply our observability expertise and powerful instrumentation techniques to solve new business problems. Recently, we recognized a convergence between observability and security, and identified full-stack runtime observability as the missing component in this transformation—providing DevSecOps and AppSec teams with essential data and insights on vulnerabilities and their impact on business.
Today, we are proud to introduce Helios Runtime for AppSec, the world’s first runtime analysis tool for SCA that leverages eBPF together with full-stack observability to deliver accurate, actionable vulnerability relevancy, prioritization, and context.
Helios Runtime for AppSec generates a unified security posture that helps teams get an end-to-end view of their application and security data—at the platform, kernel, and app levels—enabling them to analyze and prioritize SCA alerts, and conduct rapid forensics investigations and runtime taint analysis.
As always, Helios’ new AppSec technology is easy to integrate into developer and security workflows, requires no custom development, has a low footprint, no impact on performance, and provides rich signals across the entire stack with the high level of accuracy, context, and granularity demanded by enterprise CISOs.
Supercharge your SCA workflow with Helios
Helios Runtime for AppSec analyzes how your application behaves during runtime, so you know which open-source vulnerabilities really matter. Helios integrates with any SCA platform and enriches its findings with runtime usage insights to help filter and prioritize vulnerability alerts.
Using Helios, DevSecOps and AppSec teams can:
- Determine the impact of the vulnerability on the actual deployment
- Prioritize vulnerabilities based on the actual effect on the runtime application
- Eliminate false positives, and shorten troubleshooting time and MTTR
- Secure software supply chain throughout the SDLC
- Generate a dynamic runtime SBOM that is always up-to-date
- Balance security and development efforts to increase reliability
Get a demo to see Helios Runtime for AppSec in action or ask us for more information on Slack.
