At Security Compass, we had the experience of building secure programming guideline documents for a number of clients. Unfortunately, we found that in many cases the documents became shelfware and were rarely read by developers. If you’re a security Subject Matter Expert (SME) who has built a secure programming guide, there’s a good chance you’ve experienced similar results. There are 4 main reasons why:
- Time pressure: Developers under time pressure to deliver a feature, iteration or release rarely have time to sift through a 40+ page document looking for best practice guidance. Moreover, even if one developer takes the time to read through the guide there’s still the challenge of disseminating knowledge to other members of the team.
- Seniority: Senior developers can often feel they already have sufficient expertise in security, often ascribing security problems to more junior developers. It’s natural for them to feel skeptical that any general best-practice guidance can really benefit their application, particularly if they have been through penetration tests and/or code reviews in the past.
- Static content: A single document can grow quickly out of date with advances to attacks as well as defensive technologies. Developers need actionable information relevant to today’s threats.
- Context switch: Studies show that developers lose productivity every time they shift context out of their development tools. Asking developers to switch between their regular tools and a static document means lost productivity, which in turn reduces the likelihood they’ll read it.
These are the reasons why we believe that tailored software security requirements are the right approach to taking a proactive stance towards application security.