What The Bloody Hell Is An Application ?

It’s a bit pathetic that, for an industry that generally calls itself “Application Security”, we don’t seem to know how to define what an application is. Long gone are the days where a single executable was an application– now you might have a stand-alone application on your desktop that is essentially a web browser pulling down bits of JavaScript, and it all communicates with a tangled web of micro-services on the back-end.

Sure, you might think, “who cares, I know it when I see it?” That has essentially been the industry’s conclusion for a long time. For instance, when I was first grappling with this question long ago, I read Matt Bishop and David Baileys paper, A Critical Analysis of Vulnerability Taxonomies from 1996 and just gave up. In essence they said it doesn’t really matter as long as it works for you. 

That conclusion and position is no longer valid, if it ever was. We now live in a world where we are passing critical security information between tools, verbally talking about the business risk of applications, creating SBOMs for applications and reporting vulnerabilities in applications. 

How many security professionals have seen a new CVE come in, and wasted time pushing it back to engineering, because they saw the code in question used in one repository, only to find out they were wasting the developer’s time, because there was far more to the story?  This kind of thing is the reason why so many people across development and security report to us that the two functions generally have a pretty poor relationship.

Many people will have heard business guru Peter Druckers phrase “if you can't measure it, you cant manage it” but if you can’t even define it, how the hell can you hope to secure it ? Think about that for a minute, it's actually nuts. The Wikipedia definition is terrible but not as bad as Law Insiders. ISO’s definition was updated in 2015 and looked like it was written by someone from IBM. 

Everything we do in this industry centers on understanding what an application is so I asked a bunch of application security people I respect, and as expected, no one had a good definition of what an application is, and everyone without fail thought there should be one. 

So here is a brain dump that I hope will turn into a Twitter thread (before everybody abandons Twitter) that will turn into a standard that will be useful and hopefully widely accepted. I will be absolutely delighted if this is torn apart, as long as it gets put back together, better. 

Intuitively, we think of applications as making up all the code “we” wrote to provide specific functionality, as well as the code we directly incorporated from third parties (generally, open source software). This is where the supply chain world is mostly focused, and having a hard enough time getting their hands around it.

In many tech organizations, the notion of an application is a tangled graph of micro-services, where some individual services can be part of multiple related applications. That alone is a jarring realization to people who have been in the industry a long time, but haven’t worked in a modern big tech company.

But isn’t an application more than that? The code repos are usually deployed through a continuous integration system (that may itself change the code) and onto a host system such as an operating system, containers, mobile phone or services provided by a cloud infrastructure provider. It might make sense to consider those things parts of our application as well, since they all can have an impact on security (among other things).

These hosts usually provide additional security controls. An application usually uses services / API’s, both internal and external to the deployment environment to communicate with other applications and users. These can include services like machine learning, logging (Segment), identity providers (Okta) and financial services (Stripe). An application usually processes data in a data store including databases (Google Big Query),  object storage (AWS S3) and increasingly data warehouses / data lakes (Snowflake) where it is typically accessed by other applications.   Should we consider these services that an application uses, or part of our application?  This might be the natural boundary– even if we want to think of those services as part of our application, they are a black box where we have no insight or control. We might be able to get information on their security controls, but as a lone voice, we’d never be able to get them to do anything different there.

When you look at that list you can quickly and logically see that each and everyone of the things I have listed are technically connected and so can have a security impact on each other. 

I therefore suggest that we should take a fairly maximal view of what an application is. We should think of it as being  made up of all of the code repos, hosts, infrastructure, services and data-stores that work together to provide a specific set of functionality.

And, more importantly, we need better tooling to help us get our hands wrapped around the full application, so that people will stop acting like executables are applications, and push too much busy work into the system. We’re trying to do our part there, for example we are working on a set of open source code analysis rules using CodeQ that we plan to turn into an OWASP project when it is more complete we are calling that Codeography.

LinkedIn thread for comments is here. I would love to hear your thoughts.