Let me start by saying I have a great deal of respect for Dinis Cruz. He’s tremendously passionate about application security and has made numerous contributions to the community through his involvement with OWASP. We even sat on a panel together recently. But I was taken aback by a presentation he gave at OWASP AppSec Brazil entitled Making Security Invisible by Becoming the Developer’s Best Friends.
The premise of the talk was that developers and security teams should communicate and work better together — hard to find fault with that. But after flipping through the slides and watching the accompanying developer rant video I really took issue with the way this message was delivered. To paraphrase, Dinis puts the burden on the security practitioners to change their ways to work within the existing development culture, no matter how dysfunctional that culture may be.
There is no doubt that security practitioners need to better understand where the developer is coming from, but it needs to go both ways. Developers need to understand that the security guys have expertise that they don’t have. Imagine if the engineers of a jet engine didn’t listen to the test team responsible for modeling real-world hazards such as birds flying into the engine. The engineers can say that time to market, fuel economy, noise level, and cost are all they care about. But it won’t be true. They have to care about the safety of real-world incidents. Who cares if a jet engine can carry a plane across the country silently with one gallon of gas if a small bird can take the plane down? The same goes for security of software. You can have the coolest app in the world but if a script kiddie can take you down with a few single quotes, you’ve failed.
Here are a couple slides from Dinis’ presentation that further illustrate the mentality that security professionals are up against:
The difference between “lecturing” and “advising” is a matter of perspective. For instance, you can describe the same XSS vulnerability to two different developers, in exactly the same words, and get two different reactions: one asks questions wanting to understand the situation better, the other folds his arms and fires back with responses like this. What’s the difference? One is acting defensively while the other is not.
I don’t need to understand the full context of your application to know you have a real vulnerability. SQL injection is SQL injection. The guys testing the jet engine don’t necessarily know how to build the engine. Dinis argues that security is useless without understanding application context. I concede that security may become more valuable with context but can still provide plenty of value on its own.
Really, how stubborn is it to think that there is absolutely nothing useful you could learn by taking some security training? I don’t think I even need to elaborate on this one.
So what now? Truthfully, both sides need to make some concessions for there to be any real progress. I don’t think the answer is becoming the developer’s best friend. Progress starts with both sides acting professionally, not making too many assumptions, and acknowledging that they may be able to learn something from the interaction. Remember that both sides are interested in making the product better.
I’ll leave you with a recent tweet from Dan Cornell, another OWASP luminary:
My variation on this might be “I’m not telling you your baby is ugly. I’m telling you his diaper is about to leak all over your upholstery and you might want to do something about it.”