AppSec: Moving the Collective Needle on Security is the Need of the Hour

AppSec is a multi-dimensional, multi-disciplinary problem whose solution set includes just about every technical and interpersonal domain. It can be difficult, maddening, inspiring, amazing, all at the same time.

Evans Data estimates that there are something like 28 million programmers working presently. I guess that a small proportion, perhaps one million, no more than two, of those have heard of AppSec or software security. Probably only some of them work within an active AppSec or software security program. Even fewer have access to even a single security tool when industry consensus is that multiple verification methods are required to approach anything like reasonable practice. Yet, all 28 million programmers are busily adding to our pile of collective vulnerability.

I'm sure you all know that it takes a couple of different verification methods in order to even approach reasonable coverage and depth. Each method or tool is designed to find particular problems and will miss plenty of others. A single tool just isn't enough at today's state of our art.

Many tools require significant expertise and effort to eliminate extraneous and false findings. I’ve seen teams who’ve accumulated static analysis finding queues of tens of thousands of issues. When faced with that much work, harried developers typically say, “None of the above, thank you. I’ll skip security analysis in favor of something that actually delivers value.”

And that's just the testing side. I can't tell you how many really excellent architects/designers only do a little ad hoc security thinking, which is almost always limited by what each one knows and is confined to the functionality they expect their software to perform. In other words, really constrained threat modeling, not holistic at all. It's not that these folks don't think about security. It's that they don't have the requisite knowledge to be sufficiently inclusive and holistic. They do their best. And because threat modeling has repeatedly been presented as some special, security "thing", once done only by experts, most of these fine architects don't think that they are threat modeling at all. When actually, most people threat model all the time as a matter of living.

Let’s not forget our risk problem: we don't have actuarial tables yet! The best we can do is casino math, which is hard to set up well (see Factor Analysis of Information Risk - FAIR). Instead, we misapply Common Vulnerability Scoring System (CVSS), a severity rating, as our "risk" rating. There's a growing, and I think quite a solid body of research showing that using the CVSS Base Score is essentially equivalent to choosing at random. Ugh.

These are our very real problems. I can't just tightly focus on my own security concerns to the exclusion of the context in which we work. Somewhere in most graphs of open source dependencies or API call dependency trees is code written by some of those 27 million programmers who have no tools or much understanding. The context I believe is every security person’s problem, and should be that of every person who helps to create and operate software. 

I intend to contribute whatever I can, no matter how seemingly insignificant, just so long as there’s potential to move our collective “needle”. That’s why The Purple Book is important: to help each of us understand how we may move our collective needle and how we can help each other. Establishing baseline practices and making expertise readily available are surely some of what needs to happen.

We are all highly dependent upon software. Most of which haven’t been written with holistic software security in mind. That’s a sobering thought. But it’s also our call to action.