Don’t throw good AppSec money after bad

From the “How does this make sense?” department comes this finding: The more they get breached, the more likely it is that firms plan to throw money at Application Security (AppSec). … as in, the technology that should have protected them in the first place.  

Why are people increasing AppSec spend? The answer is simple: Because their tools aren’t working.

The numbers 

In its 2022 Security Survey, Forrester found that 63% of security decision-makers reported that their firm’s AppSec budget would increase in 2023, despite the economic downturn. The more often those firms had been breached, the more likely they were to pour additional fuel onto their AppSec dumpster fires. 

Specifically, among those who reported that their firms hadn’t been breached, 52% said that they planned to fatten their AppSec spend. Of those who reported that they had been breached — between one and five times in the past year — that number rose to 63%. Out of those businesses that got hit six or more times in the previous year, a majority — 78% — reported that they planned to increase their 2023 security technologies budget. 

Mind you, given the cost of breaches, there’s ample cause to put preventative and protective AppSec measures into place — if the technology actually does what it’s supposed to do, that is. In fact, Forrester went so far as to call legitimate AppSec “imperative.” 

You can see why: Vulnerable applications have been implicated in breaches for years. The Verizon DBIR 2023 highlights this continuing trend: Once again, web applications are the most frequently attacked target. Application programming interfaces (APIs) have also bubbled up as a preferred target, making API security the “hot AppSec tool,” Forrester says. Recent research shows that 74% of organizations report that they’ve experienced three or more security incidents tied to APIs. Recent API-related breaches have exposed tens of millions of customers’ personal data, including that of 9.8 million Optus customers, 5.4 million Twitter users and 37 million T-Mobile customers. 

As it is, two-third of security decision makers who’ve seen their firms breached six or more times said that total breach costs have exceeded $2 million — a figure that doesn’t even include brand damage and the cost of lost opportunities. 

How to stop burning cash on security that doesn’t work

Before piling on further loss in a hopeless attempt to recoup money previously spent on security that doesn’t work, it’s crucial for firms to understand the bigger picture of what they’re already doing with established processes. The last thing you want is for new tools and technologies to bog down developers’ work or the security team’s tasks. To this end, Forrester advises that firms look for tools that:

1. Fit seamlessly into the development workflow.
2. Provide accurate results. 
3. Integrate security guardrails into the continuous integration/continuous delivery (CI/CD) pipeline across all development teams. 

… with all due respect to Forrester, though, Contrast thinks that the first thing on that list should be “deploy tools that actually work.”

Before investing in yet more AppSec technology, it makes sense to take a hard look at what you’ve already got, where it’s working and where it’s proved to be a bad investment. 

Some things to keep in mind while you assess squandered AppSec investments: 

Where AppSec money gets wasted

Too many organizations are wasting money on broken tools. The problems: 

SAST tool issues

Static Application Security Testing (SAST) tools and technologies are often used in development pipelines to find vulnerabilities early.  This makes sense: if you can prevent vulnerabilities before you launch, you’ll be better off. However, SAST tools analyze application from the outside-in, which means they only 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 tool dilemmas

DAST tools, on the other hand, do actually analyze the fully assembled running application. DAST tools emulate the activities of a hacker, feeding malicious data to the software as it runs. DAST analyzes how the application responds to the simulated attack and looks for security gaps that could be exploited. 

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.

Spotty feedback

These tools take a lot of effort (in the case of pentesting) and compute resources (in the case of DAST, to re-run), which means that they're only run periodically.

SAST, on the other hand, is generally run on every production-ready version of the code.

Our approach is easier than any of these. Instrument once, and you’ll get feedback anytime the application is updated and exercised. That said, you have to exercise the application for us to find results. That's not always done on every increment, just as SAST may not always be done on every increment. 

Static SCA screwups

Keeping track of open-source dependencies is a priority for the security team. To that end, SCA tools examine software to determine the origins of all components and libraries within the software. They help organizations track the sources of an application’s codebase and locate new entrants in the Common Vulnerabilities and Exposures (CVE) database as they come up.

But Static SCA tools suffer from similar limitations as SAST in that they narrowly look at one aspect of the application in isolation: the dependencies. This means they can’t determine how these libraries are actually used by the application.

A handful of the top SCA tools do “reachability analysis” for some of their supported languages, which helps, but even the vast majority of SCA findings after reachability analysis are still unexploitable false alarms. The main problem with Static SCA tools is that they fail to identify cases when dependencies are specified by the application’s dependency manifest but not actually used. This results in false positives and wasted developer time as they chase down more extraneous alerts instead of helping the organization compete by actually spending their time creating code.

Static SCA tools also miss dependencies injected by the environment, which is more and more common as more and more applications are deployed to container clusters. 

All of which results in…

1. False positives

Traditional AppSec tools paralyze security teams with false positives. Recent research shows that 59% of surveyed IT decision makers receive more than 500 cloud security alerts per day, for example.

All too often, these alerts are false alarms. Research has found that more than two-fifths — 43% — of organizations have a false-positive rate of 40%. 

All that is to say that inaccurate legacy detection tools, such as SAST and DAST, are based on technology that was introduced decades ago when the pace of development was much slower and there was time to run every finding to ground.  With today’s much faster (and still accelerating) pace of development, there is no way for a security specialist silo to manually verify each finding without slowing the entire process down.

If you’re planning to increase your AppSec budget, it doesn’t make sense to invest more money in inaccurate legacy tools that inundate you with false positives. Given that security teams can’t tell which alarms are real and which are inaccurate, they have to waste their precious time investigating them all — work that can take anywhere from 10 minutes to multiple hours. For resource-constrained organizations, the prospect of investigating every single vulnerability reported by inaccurate tools is little more than a fantasy. 

2. Inadequate processes

SAST, DAST and Static Software Composition Analysis (SCA) are often slow and cumbersome, requiring separate security scanning phases that disrupt the development life cycle. This disjointed approach hampers the agile methodologies that modern development teams embrace, creating friction and delays. By treating security as an isolated phase rather than an integrated part of the development process, these tools create a barrier rather than a bridge between development and security teams.

3. Mountains of backlog

Traditional AppSec tools create monstrous AppSec backlogs: backlogs that almost always contain a shocking number of untriaged and unresolved issues. They lead to a false sense of security, offering a shallow, outdated grasp of vulnerabilities and falling short in terms of depth, context and real-time responsiveness, all while leading to lengthy times to remediate.

If you’re hearing your security/AppSec teams praying that there’s no serious threat in their mountain of backlogged security issues, you can bet that they’re being suffocated by reports from inaccurate AppSec tools.

Learn how to invest in security more wisely

Instead of spending yet more money on tools that aren’t working, take a look at Runtime Security. With the power of instrumentation, Runtime Security protects the thousands of methods in a typical software stack that are both dangerous in use and totally unprotected. Runtime does so by embedding trust boundaries throughout the entire software stack. These trust boundaries warn developers if methods are used unsafely, determine if libraries are vulnerable and exploitable, reveal security blueprints by observing method use, detect attacks, and prevent exploit attempts. 

Runtime changes the AppSec game by replacing expensive, inaccurate and inefficient manual tools and processes — ineffectual tools and processes that don’t protect firms from being breached — with automated, accurate, actionable security that safeguards every application, from development to production. 

Stop throwing good money after bad. To find out how Runtime Security can help free your security team from chasing false positives, improve processes and dig out from suffocating backlogs, tune in to a webinar with Forrester Research and Contrast Security on Tuesday, Dec. 12, at 11am PST/2pm EST. 

You'll learn how Runtime Security is revolutionizing AppSec, strengthening apps/APIs from the inside out and offering a road that leads away from the dumpster fire that AppSec budgets have become. 

Read more:

• Contrast Security Integration with CI/CD Pipelines (solution brief PDF)
• Contrast's MTTR is 37x faster than the competition (blog)
• Let’s talk stats: Why AppSec’s running on broken math (blog)
• False positives + false negatives = real costs (blog)
• The Truth About AppSec False Positives (white paper PDF)
• Learn about the hidden dangers of traditional AppSec tools and why Runtime Security is replacing them (podcast writeup)