Some Things are Easier to Fix than Fight

I posted some time back about how some things are easier to fix than find. That's particularly true of application testing. It's difficult to know if you've reached every case, every role, every permission set, every set of circumstances to cover the entire application. Sure, you can know how many form elements there were and if you tested every one, or if you tested every submission or query circumstance, but that's only of what you were able to crawl.

All that being said, when doing static analysis, sometimes it's easier to fix problems than to fight them. Developers understandably are very defensive of their work. They take pride in what they do, and while most accept constructive comments from one of their kind, it's certainly very difficult for them to take arguments from a "security specialist" about how they wrote their code wrong. I suppose professional athletes are good examples - when criticized for making mistakes during games by the media, athletes (and coaches) frequently respond with a type of remark that should the roles be reversed, the media folks wouldn't make any better decision.

So when you're armed with only a static analysis, which really only has theoretical findings, not validated findings, it's not unusual to get some push back. "That couldn't really happen", "we don't allow that type of interaction", "you can't prove that", or some version of "you don't understand our code". I'm sure these all follow The Five Stages of Application Security Grief, but when you witness them all at once, the distinct stages are sometimes hard to identify.

So what's a "security professional" with "no understanding of our code" to do? Well, you have a few options. You could just ignore your customer and hope the findings really are bogus. Meanwhile, they'll continue making the same bad mistakes in other applications (and probably write books about it). Or you could continue in a futile screaming match about who's right. Maybe the one who can yell the longest will win. Or maybe, if you really do understand their code, you could provide simple solutions to their problems. It's sometimes even faster to write a solution to a theoretical problem than it is to argue the point over whether the problem is theoretical or actual.

Now, I understand that nothing goes directly from concept to production, but it might just be a step to bridge that gap between "just security professionals" and application experts. Meaning, you might just show that you're "one of them" after all.