The Future of Application Security Depends On Our Infrastructure

To say that the future of application security depends on our infrastructure may sound controversial — especially coming from a runtime application security startup founder.

Don’t get me wrong. Our vision is still the same: application security has to be done at the application layer, and more so than ever, that security must be embedded in the application.

Prevoty built a new language-based security (LangSec) approach that enables the application to defend itself by understanding both the actual grammar of inputs (e.g. content, queries, commands) and the intent of that data.

The Never-Ending Cycle of Vulnerability Management

Even the most judicious developers will most likely introduce vulnerabilities into the code base during development. In a world of continuous releases, this results in new vulnerabilities pushed into production every hour of every day.

Practicing the Secure Software Development Life Cycle (SSDLC) methodology helps architect applications more securely, allows finding vulnerabilities before the code is pushed into production. In theory, this practice gives a chance for developers to fix vulnerabilities prior to release.

We all agree that developers are scarce resources whose talents are maximized when producing value to the business. I hope that we can also all agree that developers are not security specialists by design. So what happens after your security team has spent time and money to scan, find and prioritize application vulnerabilities? The security team will ask developers to fix them. What does that mean?

Developers will have to find a way to remediate each and every vulnerability, in most cases by creating or importing some kind of input validation or blacklist/whitelist mechanism or building a one-time workaround.

The Consequences of Developer-Led Security

Letting developers fix vulnerabilities may have a couple consequences:

  • Customized patches are a nightmare to support, with no scalability
  • Most likely, the workaround will not be optimized and will slow down the application
  • Changing the application may reintroduce a new set of vulnerabilities, bringing us back to square one.

One of our customers performed a deep analysis of their remediation costs when evaluating our product. Turns out it costs them $40,000 on average to remediate one vulnerability. This cost includes, scanning, reviewing, prioritizing, fixing, testing and releasing new code.

The Power of Standardized, Automated Remediation

So why not standardize remediation? In other words, why not let developers code with standardized, automatic security features built into the application?

Today, Prevoty offers an agent that can be deployed in applications by either developers or operations teams during the development cycle or instantly in production. Security teams can offer both developers or operation/DevOps teams an automated way to neutralize and remediate vulnerabilities.

But if we think to the future, we can’t help but wonder: what if Prevoty’s LANGSEC technology could already be enabled (or come preloaded) in your containers, your continuous release tools, your development languages, or the framework you are leveraging? This level of security at the infrastructure level would dramatically reduce the number of vulnerabilities we see in applications today.

In my mind, the biggest driving force in the future of application security will be twofold: How much will our application infrastructure embrace security? To what extent will we be able to integrate and automate security seamlessly into our infrastructure and development tools?

I would love to hear your thoughts. Send us your feedback at