Feb 13, 2011

Security People vs Developers

"Developers don't know shit about security". That may very well have been the most retweeted quote from the 2011 OWASP Summit. I heard it from stage firsthand and I wrote the original tweet about it, adding "Well, I got news. You don't know shit about development".

I truly believe this is one of OWASP's biggest problems. I hear it all over the place – frustrated appsec people claiming that developers and managers are ignorant, lazy, or untrained since they don't prioritize security. But it's we, the appsec people who are ignorant, lazy, and untrained! And that's why we're failing in developer outreach. We keep going to our own conferences, pushing Powerpoint slides, discussing unsexy web 1.5 code, and still think we're on the top of the hill. We're at the bottom, guys!

I've done surveys with 200+ developers to figure out how security is prioritized. In general, this is the picture:

Software Priorities According to Developers
  1. Functions and features as specified or envisioned
  2. Performance
  3. Usability
  4. Uptime
  5. Maintainability
  6. Security

When I tell appsec people this they typically go "Yeah! See, that's the problem. We should be much higher on that list!" No. No, no, no. We belong at level six and unless we appreciate and understand how security fits in with functions, performance, usability, uptime, and maintainability we will keep being ignored by developers.

Why? Well, a featureless system is useless. A security feature that hits performance notably is out. A system with poor usability will bring no business so usability is above security. "Uptime, hey that's a security thing!" No. Just because DoS attacks hit your uptime doesn't mean we own the issue. Many things affect uptime such as release and deploy cycles, maintainability, caching, scalability, configuration, and patching (no, not just security patching). Finally, maintainability affects ROI much more than security in the general case. Thus, security == level six.

Appsec friends, let 2011 be the year where you go to training to learn what's important in software and where security fits in the big picture. Then we won't hear anymore jokes on ignorant developers in 2012. Instead we'll be humble and get things done.


  1. Most mature app sec people take security as supporting functionality to aid a business/workflow. I think your thoughts on the lack of developer knowledge is a minority standpoint.

  2. The problem here is not that the security component isn't being prioritized, it's that you're viewing security as a separate component. You're just reversing the mistaken perspective that you're complaining about when both extremes are wrong and misleading.

    Security is a sub-component of function/features meeting intended metrics, it is a component of general performance, and it is a component of uptime. I'd challenge any ranking of security vs other concerns that
    assumes there are security elements that aren't part of those other "more important" concerns. I (very nearly) only care about security when it affects those things. There are other things that security is a sub component of too that aren't on your list (PR/regulatory/etc) but even there it's never security for security's sake.

    Security in a vacuum isn't just a lower priority, it's irrelevant. It shouldn't be a priority at all.

  3. John, simple question, is authorization a business requirement?.....

  4. @Anonymous: Not sure if you're discussing "appsec peoples' lack of development knowledge" or "developers' lack of security knowledge". Which of those are a minority standpoint?

    @Michael Graham: Security affects functions and features for sure. I've actually published two studies on security requirements that show 76% of them are functional and 24% non-functional. The list is not an ordering of duties and thusly does not say security should be separate or should be bolted on in the end. The list just says how project managers and product owners prioritize spending and developers work time and training. If you for instance have a performance and a security issue at hand, the performance issue will be resolved first. If there's a new course on HTML5 and one on appsec, the HTML5 course will be prioritized.
    There are of course differences in markets. Internet banking may not have the same priority list as gaming or social networking. There are IT segments where security is higher on the priority list.

  5. @Eoin I'd say yes, but not required in all systems. Many run with only authentication on the system facing the public Internet.

  6. I'm really glad you wrote this article, I completely agree. It is apparent that a lot of people generating these opinions/material have never been in an infosec type role, and are more likely consultants or vendors.

  7. I agree with John W that security people, overall, do not understand development.

    I agree with many of his points.

    However, there are subtleties that he and all of you are not picking up on. Every software project is different/custom and every production application even moreso.

    Developers cannot and won't prioritize security (or always dead last). Application security needs to be prioritized by the app owners and/or business/project owners. They are the ones who don't "get" development or security (and especially how they mix).

    A custom solution must be brought in and applied to solve the situational interests for almost every software project and production/published app. These solutions usually involve threat-modeling, code review, secure code construction, and app pen-testing -- where threat-modeling is the only optional component (sometimes issues are all too obvious, especially when responding to an appsec incident). Some appsec projects have other needs, but those are the basic 4.

    I am worried about the innovation in the past year from the appsec product and service vendors. I am worried about the innovation in OWASP projects from the past year.

    I am even more deeply concerned about the direction of the appsec product and service industries. However, a bright shining cloud is visible in open-source projects that provide developer- and operations- accessible web portals such as RIPS and Arachni. Can OWASP, SAFEcode, or another source provide the necessary training, endorsements, and methodologies to link technology with people and process?

  8. As a developer intent on educating the masses, I can say first-hand that a big reason why it is #6 on the list is because app security is exactly what you mention -- it is non-sexy. If done right, it is invisible. Great. How do you sell THAT!!??

    That being said, I have to say that a HUGE part of the issue is that the development community is ignorant as a whole about web security. We know now to think SSL and authentication. But SQLi and XSS? We don't KNOW that our small intranet app is a gateway to huge financial losses on the internet for our customer. It is just ignorant bliss. If the dev community is unaware of the holes, and we are, then who tells us? The InfoSec folks. Who don't know development. Who are anal about all the security and compliance stuff. 180 degrees from the web folks.

    What I find that works is to show damage from web apps and then tell the developer they are next for the headlines. Devs want the glory. A negative headline is bad for them. Looking stupid is bad for them. Realizing XSS exists is a win-win. It will take a small army of devs to turn the tide. Devs won't listen to InfoSec...it will take a few of their own to lead the education and make it part of the process, in order to CYA. Voila...done.

    I speak at dev user groups/conferences about this stuff. I asked each group how many people know what XSS is, how it works, how to code against it and actively do code against it. Same with SQL Injection. In every single group, not a hand is left raised to say they can do all that. They don't even know they are leaving holes open. And these are the top attacks that have also been around for YEARS. Ahhh to be so blind.

    OWASP is a great thing. Getting people to look at it is key. Getting them to then apply it is critical.

  9. John, I couldn't agree more.

    Some of us have been trying to say the same thing for a while with little success and even less attention. The problem has been that the point of view that security must reconcile itself and maybe even ride backseat to the priorities of the business has either just been lip service, has not been a popular one, or sounded like a cop out.

    Every time I've met an AppSec practitioner who proudly boasted of having go/no go authority my mind reeled with the thought of the damage they were doing to our industry. I can think of another organization that has go/no go authority, the TSA, and we know how effective they are and the wonders they have done for air travel. Is AppSec unwittingly pursuing this same dream? I've also been speaking with developers a lost over the past year and I can tell you my findings are the same as yours. These guys and gals are pissed at security people because "security doesn't know shit about development"

    By pointing out that OWASP, one of AppSec's emperors, has no clothes, you have brought some of the contention this idea was lacking. Read your post and then look at these tweets https://twitter.com/chriseng/status/35689378101731328 and https://twitter.com/chriseng/status/35701606616023040 from Chris Eng at the summit and the issue starts to become even more clear.

    Hopefully your post will be a catalyst and bring the attention and debate this idea needs. We have a lot of work to do and until security people learn how to earn the respect of the business and the developers who ultimately will be the ones fixing the problems, AppSec will remain in the dark ages.

  10. John, Thanks for writing this up. I could not agree more and I could not have written it myself better.

    Let's work toward a day when security gets integrated into software development and we no longer need separate "application security people".

    Tin Zaw

  11. Security shouldn't be on the list in the first place. It should be part of functionality and not seen as a separate discipline or layer.

  12. Great blogs John, generating important discussions!

    I think these comments (taken from others comments) says everything I'd have to say here:

    "The problem here is not that the security component isn't being prioritized, it's that you're viewing security as a separate component. You're just reversing the mistaken perspective that you're complaining about when both extremes are wrong and misleading."


    "It is apparent that a lot of people generating these opinions/material have never been in an infosec type role, and are more likely consultants or vendors."


    "Security shouldn't be on the list in the first place. It should be part of functionality and not seen as a separate discipline or layer."

    and partially this:

    "I agree with John W that security people, overall, do not understand development."

    But I'd add "a lot of developers don't understand development either" as well.

    Keep up the good work!

  13. Really enjoyed this post. In the Web Ops space we are wrestling with this topic on our own domain under the rubric "DevOps" - like security, ops folks have this same divide with devs over availability, performance, maintainability (and security, when the shop is small enough that it's the ops person doing that too!). Anyway, the leading solution is to embed an ops person onto the product team so that both functional and "nonfunctional" requirements are all taken into the same queue and can be prioritized appropriately. And it works.

    I thought dre's presentation at Austin OWASP was super on point, as it essentially prescribes the same solution. No one likes the external smartypants security auditor who comes in and huffs about how retarded the devs are. What do you think is going to happen? You need to embed a security expert onto the product team in a DevOps style - dre coined the name of the role as "Security Buddy." That's awesome. How can you hate your security buddy?

    It's more messy and takes deeper engagement, but the future of really incorporating security into apps is this model, which focuses on collaboration and overall value of the product over either group's specific bailiwick.

  14. Hey John,

    i have to agree with the priorities (the way you describe them), but i have to disagree with the general idea

    I feel that it is the developer's responsibility to understand basic security concepts (to say the least). I am not saying that all developers should become "security guys", but i expect a web application developer to know what SQLi is and how to prevent it

    In the same fashion, i expect a UNIX administrator to NOT have /etc/passwd with 777 permissions. Yes, the system will work with these permissions, but really, would you like to have this sysadmin managing your blog?

    It is (in general) expected from us (security people) to know all the new tools, all the new attacks and all the new countermeasures. In the same sense, i expect developers to know about the new libraries (ESAPI or AntiXSS or whatever is out there) and keep up with security issues created by their code. Is this too much to ask?

  15. I do have to agree that security is on the bottom of the list for most developers simply because they are not taught/required to think ahead in the larger scope when designing these systems. It can fall under the same mistake as when they suddenly realize that they need a mobile version and quickly slap something on which is just a reduction of the core HTML code. Or if they suddenly realize that a user profiling system needs to exist.

    The problem, as some comments mentioned above, is that security is not sexy, it's often considered a burden because it requires a fairly complex learning curve, modification of coding behavior, and results in.... nothing visual for the end user and a mere checkbox for the management.

    The gratification (personally and from management) is usually lacking. But if, as mentioned above, we can integrate security by design using tools and methodologies that are deemed to do well to produce secure code, it can help.

    It's usually a game of chance, "I'll add it later when it becomes necessary". In the end, I think developers do know (at least in the back of their mind) what (if not how) needs to be done to try to be secure, but time, budget, pressure, and ability to build something functional w/o the security tend to override it.

  16. Good post. I have a quibble with the prioritized list, though.

    Imagine you can only have the top 70% of each characteristic on the list above. Things would be ... well, better than they are. The problem I see is that "Functions and features as specified or envisioned" is voracious, and most of the rest of the bars are left with pocket change. Developers work their butts off and become exhausted by an unrealistic and uncontrolled expansion of the feature list.

    IMHO, this can usually be blamed on management that rewards project leaders based only on feature lists and recent sales. It takes too long for the downsides of under-investment in the other five areas to bite anyone. A big feature list pays cash, fast. IMHO, it will take a coalition of security professionals, developers, and QA to educate management into a more defensible application development strategy, where each critical requirement is actually addressed, and not just given lip service.

    This will require dropping the attitude that exists among all of us, and stopping the "us vs them," "developer vs appsec pro" mentality. Let's work together with the smart people from all teams. I agree with the punch line -- we should all offer more humility. Arrogance yields isolation, which yields failure.

  17. very vast view point yet very productive for both developers and apsec guys.

    i totally agreed that many times the matter of app security would have been under sighted but this because of the culture of the industry to get things done with in the time line. but i think its better to look at security while writing the code to rimed any overload of project flow

  18. Bit late to the discussion but most commentators have a point but we really need something practical.

    Management needs a no-brainer business case to fund security as a feature. It is a two step thing ...

    1. Take your Apache access log and find a way to show that to management. It will prove to anyone that hackers are automating their probes and any insecurities will therefore be found. No brains required there. Once an executive has been officially shown something like that they have a duty of corporate care to take it into account.

    2. Write a list of security tests which specify simple inputs and required responses from the finished application. Then put a price on achieving success and ask for sign-off.

    Note that building a suite a such tests might be expensive or might have already been done. I don't know. But it is needed.


  19. Yeah, because developers don't really know how dangerous if the door to their system was open. I think at least those developers have to get hacked before they say "Oh!! My source code was stolen! My database were dropped!! My server was error!"
    But those are the best case when you get hacked because you know the problem. What if malicious code was putted in your source code and server? You don't know what happened, you feel okay until one of your customer start to complain, your website was blocked and deleted from search engine, your website visitors get virus from your website, etc. How long you need to build fix your system and to get back trust from your customer??