Learn about the hidden dangers of traditional AppSec tools and why Runtime Security is replacing them: podcast writeup

Are traditional AppSec tools keeping up with advances in software?

That was the question The Application Security Podcast host Chris Romeo recently asked Contrast Security Co-founder and Chief Technology Officer Jeff Williams. 

The TL;DR answer: No. 

The conversation kicked off with a look at the challenges organizations face with traditional Application Security (AppSec) tools — namely, Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), static Software Composition Analysis (SCA) and web application firewall (WAF) — and their burgeoning AppSec backlogs, which almost always contain a shocking number of untriaged and unresolved issues.

Jeff contends that Runtime Security is a perfect fit for solving these challenges and creating healthy enterprise AppSec programs. It’s a game-changer, given its ability to provide fast, accurate and scalable app/application programming interface (API) testing and protection without disrupting software development and operations processes.

You can find the longer answer and a whole lot of nuance in the podcast, where Jeff discussed the benefits of Runtime Security. Below are highlights from the conversation.

The root of the problem: Shortcomings in SAST, DAST, static SCA and WAF

Fundamentally, SAST, DAST, static SCA and WAF tools simply aren't fast, accurate or scalable enough for today’s enterprise, Jeff explains. The complexity of today’s software makes these approaches dangerous for organizations to rely on.

SAST tools look at source code, so they can’t see how the fully assembled application actually works. They don’t see how the custom code interacts with the runtime platform, app/API server, libraries, frameworks and code from other repos. Since most vulnerabilities span both custom code and all these components, these tools make a lot of mistakes. 

DAST tools, on the other hand, do actually analyze the fully assembled running application. But since they work from the “outside-in,” they can only detect vulnerabilities that they can actually exploit and detect in the HTTP response. Possibly the worst part: DAST tools can only scan the “front door,” not all the back-end interfaces and connections in modern applications. Bottom line? DAST takes a lot of work and misses a lot.

Static SCA tools suffer from similar limitations as SAST. They don’t analyze the entire application, just the dependencies in a single repo at a time. This means that they can’t determine how these libraries are actually used by the software. At best, static SCA can do “reachability analysis” to estimate whether code can theoretically execute. Unfortunately, the consensus in the industry is that 90% of the vulnerabilities noted by static SCA tools are unexploitable false alarms. 

WAFs have long been criticized for being difficult to manage, breaking applications and APIs, missing real attacks, and being bypassable. The root cause of the issue is that they have no knowledge of what they’re protecting. They can only analyze the HTTP traffic and match patterns for possible attacks. The problem is that applications and APIs are quite complex. There is no way to capture the patterns of all the possible attacks against this custom code. 

In all these cases, using traditional AppSec tools that don’t have enough context doesn’t produce the results you need for software you’re betting your business on. Sometimes, if you’re only considering a single app/API, it can be tough to see this pattern. But ask any company relying on these tools and you’ll see development delays, long remediation times, expensive triage costs and massive backlogs. Those aren’t the outcomes we need from a healthy AppSec program.

The consequences: Backlogs dating back to the Jurassic Era

The upshot is that legacy AppSec technologies “tend to miss a lot of stuff that's real… and generate a lot of false positives,” Jeff summarizes. “The tools are inaccurate because they don't have enough context. And anytime your tools aren't accurate, people have to get involved. Unfortunately, there aren’t enough people or enough hours in the day to deal with these time wasters, he says — an issue that multiplies as organizations add more and more software. “There's just not enough people to do the work, so it doesn't scale,” he says.

The consequences are very slow remediation, large backlogs and significant risk. Jeff points to Veracode’s own published data, which says that its average time to remediate is 298 days with SAST and 305 with DAST. “Imagine if your No. 1 concern is security, and you have to wait almost a year for vulnerabilities to be mitigated?” he ponders. 

Jeff recently talked with a chief information security officer (CISO) who shared that his organization has a backlog of 1.7 million vulnerabilities that the CISO considers “theoretical.” “Ask just about any CISO or AppSec lead in any company about their AppSec backlog, and the answer you get is not going to be fun,” he confides.

“If you back up, it's kind of obvious that this would happen, right?” Jeff asks. “If you use noisy tools, they're going to generate a big pile of stuff that needs to be triaged, and nobody has the resources to do it. So you're going to be generating this giant backlog, and it's just going to sit there.” No amount of “posture management” is going to fix this. Unfortunately, “some companies count that as success,” he laments. “Carrying a huge backlog has immense cost and actually prevents remediating critical issues.”

Traditional AppSec tools have reached the limit of their evolution. “They're not going to get better, because there's no more information there to get better with,” Jeff continues. “It's a lack of context. That's the problem.” As technology continues to evolve and threats accelerate, security analysis needs more context in order to help organizations focus on real, exploitable vulnerabilities and attacks that could actually cause harm. It’s simply not safe for organizations to bet their business on traditional AppSec tools. And it’s probably infeasible for most organizations to build expert teams to fill in the gaps.

Introducing Runtime Security technology

After a start as a software developer and a 25-year security career doing threat modeling, penetration testing, security code review and creating AppSec tools, Jeff is fluent in the language of code. There are “tons of things that you can't really figure out either statically or with a traditional dynamic tool,” he comments. “Our insight was that the only way to get better context is to watch the actual code as it's running. That’s when everything is assembled, everything's in context and you can really see what happens.” 

Note that “Runtime” shouldn’t be confused with “production.” Developers distinguish compile-time (while software is building) from runtime (anytime the software is running). In other words, “Runtime Security” is a natural part of development, pipelines, testing and production.

Using Runtime Security is simple: You install it on your workloads, and it works in the background to prevent vulnerabilities and attacks. Runtime Security doesn’t require any changes to how you build, test, deploy and operate your applications and APIs. 

True to its name, Runtime Security has full runtime context and uses it to analyze and protect code as it runs. There are no scans or firewalls needed with Runtime Security. All the analysis, testing and protection are done in the background during normal development and operations. With Runtime Security, security testing occurs in the background during every Quality Assurance (QA) test, whether manual or automated. And because each workload is protected individually, Runtime Security naturally scales to massive software portfolios.

What does Runtime Security deliver?

Enabling Runtime Security in your workloads automatically provides all of these capabilities at once:

• Runtime Application Security Testing — (sometimes called Interactive Application Security Testing, or IAST) — a form of DAST that autonomously finds zero-day vulnerabilities in both custom code and libraries. Highly accurate results appear in real time while code is being tested during development.
  
  
• Runtime Software Composition Analysis — autonomously identifies all libraries present in the running application or API environment, analyzes whether they have vulnerabilities, documents how those libraries are actually used by the app/API and generates highly accurate Software Bills of Materials (SBOMs).
   
• Runtime Application Security Protection (sometimes called RASP) — automatically prevents vulnerabilities in both custom code and third-party libraries from being exploited in production. Full visibility into attackers, attack vectors and targeted systems to the code level. Very fast and highly accurate without significant configuration.
  
  
• Runtime Application Security Observability — provides a digital security blueprint that shows how applications work, including the attack surface, how each route invokes security mechanisms, uses dangerous technologies and makes back-end connections.

In other words, Runtime Security is a single technology that covers the whole gamut of AppSec tools. Runtime Security doesn’t need nearly as much configuration as traditional AppSec tools: You basically just install it and do your normal software development process. Runtime Security is also both popular and proven. It’s deployed on hundreds of thousands of web applications and APIs in both development and production at some of the biggest companies in the world.

With Runtime Security, you don’t have to think of API security as a separate thing. Traditional AppSec technologies don’t work well on complex API frameworks, data formats and protocols. Many new API security products are “really just DAST and WAF shoved together,” Jeff says, and they don’t work very well to improve API security. Fortunately, Runtime Security works from inside-out on APIs “perfectly” — exactly the same way it analyzes and protects other types of software. 

How does Runtime Security technology work?

Simply install Runtime Security into your workloads, whether they’re in a data center, cloud or container. An application or API with Runtime Security installed can be moved from an internal data center into the cloud, and protection goes with it.  “Runtime Security will keep working no matter where the code goes,” Jeff emphasizes. “It's radically simpler and more scalable. That's why I say, ‘just build Runtime Security into your stack.’”

Runtime Security uses the same instrumentation techniques as tools like New Relic and AppDynamics, but for security, as opposed to performance monitoring. Runtime Security protects all the potentially dangerous methods in your stack with trust boundaries. These methods do powerful things, like parse XML, make SQL queries, evaluate expressions, start native processes and much more. The trust boundaries perform checks to ensure they’re used safely by developers and protected against being exploited. It’s just that simple.

Runtime Security can also find vulnerable libraries and automatically detect how libraries are used by the custom code in an application or API. And not just the libraries from a project’s code repository or manifest. Runtime Security can see all the libraries in the entire stack and detail exactly which ones are actually used, vs. which ones are just “dead code.” On average, 62% of libraries are never used or even loaded into memory. And any vulnerabilities reported by static SCA tools in these libraries are false positives, almost impossible to exploit. Runtime SCA enables teams to focus on the 38% of libraries that actually matter.

Runtime Security versus SQL injection

Runtime Security can detect all the different kinds of vulnerabilities that SAST and DAST can find, and more. As just one example, consider how Runtime Security defends your organization against SQL injection. 

Let’s start with the methods that send SQL queries to a database. Currently, there is nothing protecting these methods from misuse, either by developers or attackers. These missing protections are the root cause of most AppSec issues. 

Runtime Security enhances your software stack with security trust boundaries that add two critical checks to prevent misuse by both developers and attackers:

1. Is the developer using this method safely? 

The first check is to see if the developer has included any untrusted data in their query without properly escaping or parameterizing it. If this check fails, the developer is instantly notified of a SQL injection vulnerability with a rich trace containing all the details — the HTTP request, exact line(s) of code, stack traces, the actual data that flowed through the app/API and, of course, detailed remediation advice. Note that the developer did not have to attack their code, didn’t need to know anything about security and wasn’t forced to take any extra steps. With this alert, the developer can rapidly make the fix and check in clean code. 

2. Is an attacker attempting to exploit this method? 

In production, the same trust boundary checks to see if data from a user changes the semantics — the meaning — of the query. No user should ever be able to change a query’s meaning, so if the trust boundary detects this, it immediately captures all the relevant state, alerts the operations security team and prevents the query from reaching the database. This protection is unlike a WAF in that it occurs inside the code, where it has rich context for deciding whether an attack is real or not. Runtime protection is extremely fast — typically, it adds about 1% to roundtrip request latency — as it doesn’t require an extra hop and doesn’t rely on simple pattern matching, as do WAFs. And, unlike WAFs, virtually all customers have Runtime Security in block mode.

Notice that in Runtime Security, finding vulnerabilities, checking libraries, and stopping attacks are three sides of the same coin. You can do all three at once with a single product that puts security in the right place.

Think about it this way: Runtime Security is just enhancing your stack to make it resilient against SQL injection, adding the checks that should have probably been there in the first place. Rather than attempting (and probably failing) to fix all the thousands of SQL queries in your enterprise, Runtime Security can add the protection exactly where it should be — right in the libraries you use to access the database. And unlike traditional “fixes” for SQL injection, such as parameterized queries, Runtime Security provides critical visibility into which of your users are attempting to exploit your application and APIs. This enables proactive response to attackers, instead of letting them play around in your software until they succeed.

Runtime Security can deal with a broad range of custom code vulnerabilities, Common Vulnerabilities and Exposures (CVEs) and attacks across most of the major technology platforms in use in most enterprises, including Java, .NET, .NET Core, Node.js, Ruby, Python, Golang, Kotlin, Scala and PHP.

Generating digital security blueprints of your Apps/APIs

Runtime Observability is the newest addition to Runtime Security. This feature includes the capability to produce digital security blueprints of every app and API. These blueprints capture the security relevant details of how the software actually works. Runtime Security gathers this data by watching the code run: It sees the entire attack surface. For every entry point, it documents the security defenses, dangerous technology use, back-end connections and much more.

Rather than trying to collect this information using inaccurate and incomplete surveys and interviews, teams can focus on actual threat modeling analysis. The blueprints also streamline penetration testing, showing testers exactly where to test for which vulnerabilities. They even make highly contextual risk rating and prioritization possible, as every vulnerability can be evaluated in the full context of the software. The same goes for incident response: In production, the blueprint enables fast, contextual response during a breach investigation.

You should always have an up-to-date digital security blueprint of all your applications and APIs. Runtime Security makes it automatic.

Updating your AppSec program with Runtime Security

AppSec programs that leverage Runtime Security can streamline their work and produce far better results compared with more traditional AppSec programs. 

This case study from IDC details how Floor & Decor uses Runtime Security in their AppSec program and the benefits the company experienced. According to Floor & Decor AppSec team leaders, the use of Runtime Security has enabled them to better identify, remediate and avoid potentially impactful security events such as the recent Log4j incident. They noted that their applications were protected from Log4Shell years before it was publicly known.

Runtime Security helped Floor & Decor create a more mature and effective AppSec program in terms of the company’s security vulnerability protection and remediation capabilities, especially for its API environments. As a result, the team provides comprehensive and effective security across business operations in a cost-effective and efficient manner and has established a foundation of robust security upon which expanding business operations can grow.

In addition to streamlining its program, Floor & Decor was able to achieve 258% three-year ROI, with a payback on its investment in five months. The hard-surface flooring retailer experienced 30% AppSec team efficiencies from Runtime Security and a 13% development team productivity gain. With Runtime Security, they need 94% less staff time to handle major security issues related to development environments. They’re also finding 92% fewer applications with vulnerabilities.

These results are significant and achievable for any enterprise that is struggling with traditional AppSec tools.

The future

The speed, complexity, connectivity and criticality of software are all accelerating incredibly quickly. There is no way that “outside-in” AppSec tools, with minimal appreciation of how applications are assembled and how they actually work, can possibly keep up. And the amount of labor to continue running them and dealing with inaccurate results is untenable and is fated to only get worse. Most importantly, the results from these tools simply aren’t good enough to trust your business to.

Fortunately, Runtime Security can enable much more fast, accurate and scalable AppSec in a single technology that is much more compatible with the way organizations build software. Runtime Security is already protecting hundreds of thousands of critical applications in large enterprises across every sector. You are almost certainly already using apps and APIs protected by Runtime Security for your banking, insurance, healthcare, social media, government and social applications.

We see a future where every stack includes Runtime Security and software development organizations have a healthy AppSec program delivering fast remediation, minimal backlog and high-speed innovation.

Listen to learn more

Have a listen to the podcast to learn more about runtime security and IAST, including Jeff’s take on:

• Why DAST is easily replaced by IAST
• Whether it’s time to throw out your WAF
• Why IAST works at DevOps speed
• Why any developer can use IAST to find application vulnerabilities
• Differences in detection and rule technologies between RASP and IAST
• Why runtime security dramatically cuts the rate of new vulnerabilities
• Are RASP and IAST your AppSec panacea?

Read more: 

• Shift smart instead of following shift-left fairy tales
• Stop relying on Vera-slow code scanning
• Case study: Floor & Decor carpets its security with Contrast
• IDC case study: Floor & Decor Ensures Comprehensive and Efficient Security with Contrast Security (PDF)
• Venture in Security article about circle stickers, as mentioned in the podcast