<img height="1" width="1" style="display:none;" alt="" src="https://analytics.twitter.com/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0"> <img height="1" width="1" style="display:none;" alt="" src="//t.co/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0">


Radically Different Application Security: The IMMUNIO Approach

Risk is defined as “a situation involving exposure to danger.” So what is application security risk? Along these lines, application security risk can be defined as “the danger application code is exposed to."

At IMMUNIO, we believe that traditional approaches to application security are highly inefficient, and we’re dedicated to changing the AppSec paradigm.

We’ve built a solution that is radically different. We believe our approach provides much broader security protections for web apps, significantly reduces the risk of exploitation, and is far easier to implement and maintain than more traditional solutions such as Web Application Firewalls (WAFs).


Application code -- the code that you write and/or run -- is at risk of exploitation of design or implementation flaws. The web application security skills gap in many organizations also contributes to this exposure, as more and more code is written with less and less secure coding know how. The danger to application code consists of exploits that can harm any or all of the following:

  • Systems (for example, through denial of service attacks)
  • Organizations (through data breaches or remote code execution for further infiltration or exfiltration)
  • Users (through the theft of credentials, identities, or financial information)
  • Others (if the system is used to serve malware or spam)

For us practitioners in the field, we have known for decades that all code is at significant risk until security best practices are implemented to drastically reduce that risk.

Why? Because coding is easy, but secure coding is hard. Developers are measured by how fast they write code, not how securely they write code. Most developers do not understand the intricacies of writing secure code (let alone advanced hacking). New security research pops up all the time, and it’s difficult to stay on top of new developments. And there simply aren’t enough security professionals available to keep apps as secure as they can be.

Vulnerabilities are Inevitable. Exploitation is Not.

Application security, then, is the body of knowledge (and the associated industry and technology) whose mission is to reduce the risk to applications.

The application security industry as a whole is focused on dealing with danger through identifying application code exposures. The industry is myopically focused on minimizing the occurrences of vulnerable lines of code in applications. Many solutions aim to help you identify where this vulnerable code exists, so that you can, eventually, remediate it by fixing the affected lines of code. The industry is focused on minimizing risk by minimizing exposure.

IMMUNIO’s approach is different -- radically different. Our goal is to minimize risk by minimizing exploitation. (To see examples of how IMMUNIO does this, take a look at this video, as well as this one, showing how our solution protects against real Rails vulnerabilities.) Instead of focusing on finding all the places where your code is vulnerable, we make sure these inevitable vulnerabilities cannot be exploited by attackers to harm your systems, your data, or your customers.

We argue that the latter approach is orders of magnitude more efficient than the traditional approach. We believe the future of application security programs has to start with tools that safeguard against the exploitation of vulnerabilities.

Comparison of the Current Model to a Modern RASP Model


The Lifecycle of a Vulnerability

The canonical example of an application vulnerability occurs when developers write code that trusts user input. The exploit is made possible when attackers figure this out and craft an input that subverts the system to their will. This type of of injection vulnerability is so common that it is the number one type of vulnerability on the OWASP Top 10 list.


Before any security assessment or code review can take place to identify this security bug, the vulnerability has been introduced into the application, where it lurks unseen. The application is now “at risk.”

Later, the bug may be identified. A source code review, perhaps undertaken with a static analysis, or perhaps identified via pentesting, may reveal this vulnerability. Since both these activities (source code review and pen testing) are processes that involve humans (at least in some capacity) using imperfect tools, this vulnerability may linger for an extended period. Indeed, many recent vulnerabilities sat dormant in code for years before being discovered.

The bug is then reported. It is communicated to the organization developing the application, acknowledged, and eventually validated and assigned a level or priority and importance or severity.

Once the organization decides that it wants to mitigate such a risk, as opposed to just accepting it, it has to remediate the bug, or fix it at the code level. Once the bug is fixed, verified, and the code pushed to production, the vulnerability is now resolved.

Since finding vulnerabilities may take months or years, and actioning those vulnerabilities after that may take months or years, actual risk reduction may take months or years to materialize

Your Code Isn’t Just Written By You

Odds are that your application is not entirely written by you. As with all modern web applications, developers use third party, mostly open source, components typically including web frameworks and libraries.

These third party components have security vulnerabilities of their own. However, your team (including your appsec team) will deal with them in a slightly different manner than it would with code written entirely in-house, because:

  • Since they are big software projects, whose developers do not work within the boundaries of your organization, the team will not attempt to find all flaws in these components
  • Your team will not usually remediate the flaws in the component directly, but rather rely on upgrading to a new security release. In some cases this is a particularly complicated task because with big components, such as web frameworks, this may entail a major release upgrade which might require months of work

The normal practice is to check whether the versions of the libraries used include known CVEs, and if so, the team would evaluate whether those CVEs affect the application. If it does, normally the risk is removed once the component is upgraded.

Similar to your own code, researchers may take years to find subtle bugs that are lurking in a component (SQL injection, for example, has been a known threat to web app security for 17 years, yet it remains at the top of the OWASP Top 10). Most of the time, a reported vulnerability is done in private, to give the component developers a chance to address the vulnerability in a new release before exploits start to be developed for it in the wild.

A further risk is that it is estimated that there are more reported vulnerabilities than there are CVEs. Not every reported vulnerability becomes a CVE. (For more details on the limits of CVE reporting coverage, see this explanation on the CVE website.) This limitation further poses a problem in that without such a mechanism, it becomes very difficult to know which version(s) carry risks.

IMMUNIO: the Web App Immune System

At IMMUNIO, we believe it’s no longer necessary to embark on the ultimately impossible quest to track down every vulnerability, no matter now small, and remediate it. The future of web application security lies in a drastically simpler approach: preventing vulnerabilities from being exploited in the first place.


A vulnerability on its own is just a risk. This risk is not realized until an exploit for the vulnerability is designed and leveraged. Finding all vulnerabilities is hard; detecting and preventing the harm that occurs through vulnerability exploitation is much easier.

An attacker may try to thwart your application by targeting a vulnerability, for example by getting your application to run a system command. What if your application did not let any request (good or bad) issue system commands at all? Or, if system commands are absolutely necessary, ensuring that they’re tightly controlled and monitored? The damage in this case is minimized or eliminated. Even if an attacker finds the vulnerability and crafts a malicious payload, the exploit will be unsuccessful because the application will not allow this exploit vector to proceed.

The concept of thwarting exploitation is extremely effective at reducing risk in the real world. All your organization needs to know is “what is normal operation” for different parts of the application: for example, what parts of the file system are written to/read from, what processes the application forks, and what SQL statements the application generates. If you can identify the “normal” state of the application, then you can also identify what is “abnormal.” Indeed, “exploitation” is nothing more than making the application do “abnormal” things.


IMMUNIO is your applications’ immune system