Software complexity is exploding. Modern applications and application programming interfaces (APIs) comprise hundreds of repositories, frameworks, components, platforms, containers, services and connections. The rapidly increasing use of third-party, open-source libraries and AI-generated code is aggravating the challenge.
We need a way to simplify the problem — a “root cause” that we can target. Fortunately, almost all application security issues are tied to a “dangerous function.”
Dangerous functions are simply software procedures, methods, routines or subroutines that perform a powerful task and can cause harm if not used safely. A typical software stack has thousands of these dangerous functions, performing tasks such as creating files, parsing documents, executing native commands, deserializing objects and querying databases.
The problem is that dangerous functions are far too difficult to use securely. There are no instructions for developers, no documentation, no compiler warnings, etc. Even worse, these functions don’t detect or block attacks and exploits. So there’s no way to know if you’ve been attacked. This virtually guarantees that there will be extensive vulnerabilities in production and that attacks are easy, undetected and unblocked.
For example, exposed database access functions are the root cause of SQL injection (SQLi) attacks. Developers aren’t warned to ensure untrusted data is escaped or parameterized before being used in a query. And in production, attempts to modify the meaning of queries are neither detected nor blocked.
How Runtime Security works
There’s a better approach called Runtime Security, which involves adding lightweight trust boundaries to dangerous functions using instrumentation.
Runtime does three things:
- Prevents misuse of dangerous functions by developers
- Prevents the use of vulnerable open-source libraries
- Prevents exploitation of dangerous functions in production
Every time the app is run, it automatically tests and protects itself in development, QA and production in all environments (cloud, containers, servers and serverless). All running instances pass along telemetry about vulnerabilities and attacks.
As developers fix and enhance the application, no additional action is needed: Runtime easily scales to continuously protect an entire software portfolio, including applications, APIs and even third-party applications. It covers the whole stack at once, instead of scanning pieces separately and overlooking major components. The result is a highly effective AppSec operating model that delivers a high level of security without compromising innovation.
It’s the only way to protect organizations from exploding application complexity and the threat it poses to their security.
Here are five ways that runtime solves the complexity crisis and enables highly effective AppSec programs:
1. Runtime solves the problems with legacy AppSec tools
Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST) and Software Composition Analysis (SCA) tools are slow and error-prone, only testing parts of software at a time. This leads to huge and growing backlogs of theoretical vulnerabilities, largely false alarms that developers waste time chasing down.
Runtime avoids these time-wasting backlogs by eschewing theoretical vulnerabilities and false positives, instead focusing on reporting vulnerabilities that are actually observed in running software. Runtime analyzes the entire stack as it runs, instead of running a specific tool on every individual part. This approach delivers a near-zero false positive rate, along with detailed findings and instant feedback that empowers developers to secure their own code, without requiring the kind of expert assistance required by difficult-to-use legacy AST tools.
2. Runtime protects against zero days
Organizations are rightfully concerned about their lack of ability to detect and prevent zero-day attacks. They know that zero days are increasingly being exploited in the wild (PDF), with adversaries focusing on enterprise-specific software and appliances.
Runtime Security provides two capabilities to prevent zero-day attacks from working. First, trust boundaries prevent exploitation of entire classes of common weaknesses, like SQLi, unsafe deserialization, expression language injection and many more. Second, Runtime Security prevents common exploit techniques from being used by attackers, such as reflection-based access to the classloader in Java, which has been used in Log4Shell and Spring zero days.
In fact, Runtime has addressed many zero days even before they were discovered, including Log4Shell, the CVE-2020-17530 Apache Struts2 zero day that led to the Equifax breach, Spring4Shell and more. Runtime can identify such zero days in both custom and third-party code and prevent them from being exploited.
3. Runtime eases alert fatigue
Web application firewalls (WAFs) have failed to effectively protect web applications, given that they both over- and under-protect, creating both spurious alerts and exposed risks.
The resulting alert fatigue is a serious challenge for security and development teams. It’s not only impossible to keep up; the amount of noise from false positives is almost certain to drown out important signals that actually matter.
Runtime reports only attack attempts that actually connect with their intended vulnerability. Over 99% of attack attempts don’t satisfy this basic criteria, and there’s no reason to waste security analyst time investigating them. For the attacks that do matter, Runtime facilitates effective incident response by reporting exact details down to the exact line of code.
4. Runtime creates live security blueprints
Runtime delivers “security observability” by creating a kind of live security blueprint that directly captures all the security relevant details of an application or API. For each exposed endpoint, Runtime blueprints capture the attack surface, defenses, dangerous functions and outbound calls to API endpoints, operating system calls, database queries and file systems.
The security blueprint improves AppSec by providing detailed context:
- Threat modeling benefits from an up-to-date blueprint recorded directly from the running application or API.
- Pentesting can focus on only those attacks that are possible in a particular route
- Risk rating and prioritization is more accurate with full application and API context
5. Runtime unifies tool alphabet soup
Traditional AppSec requires running a significant number of focused tools, including at least SAST, DAST, SCA and WAF. These tools can’t secure increasingly complex development environments and software. Each tool requires human experts for configuration, operation and triage. They become a bottleneck that leads to backlogs and silos that waste resources and delay development. Runtime Security provides all of these capabilities in a single technology while raising the coverage and accuracy of both assessment and protection.