I’ve been a part of several development organizations, and, for several of those teams, security was an afterthought to the development process. We’d secure databases and even implement field level encryption but we rarely had to consider many attack vectors as we were building internal apps for enterprises and the risks were there, but not as great.

Fast forward to the Mobile First world we live in and that lazy attitude is no longer acceptable. S&R teams have real concerns and actively work to protect their computing environments – both internal-facing and external-facing. Development teams work the other side of that and implement secure code as part of their daily activities (right?). With an appropriate level of trust between the two organizations, many use code scanning utilities to verify delivered code and hunt for vulnerabilities. There are many sources of vulnerabilities; it could come from code written by the company’s developers, code pasted in from Stack Overflow or even added through some third-party or open source library. In my experience, static code scanning tools are effective and can catch a lot of potential vulnerabilities but, from a developer behavior standpoint, what the ultimately do is simply teach developers how to get their code to pass the scans, not actually deliver more secure code.

A former manager of mine left his day job and started his own company; building an online service for small businesses. My biggest question when I heard this news was “how did he know what to do to make this environment he built as secure as it needed to be?” The app is browser-based, so he built the system using Node and runs the application on OpenShift. There are a lot of books on online tutorials on Node, MongoDB and other tools he was using, but just throwing something together in his basement, how would he have the requisite skills to secure this thing in the wild?

I’ve been doing some Node development for a Raspberry Pi project I’m working on and therefore have been studying how to use Node and Express to build web apps and expose web services on the Pi (yeah, I know I’m a geek, no need to tell me). In one of the books I read, there was some very useful information on how to secure different components in a node-based site. What struck me as I read this was how would I have known otherwise to do this stuff to my app? Does a developer study all the security aspects of the system under development then start coding or does he (or she, of course) code away and either add security to the app while coding or perhaps add security to it afterwards (once everything’s coded)? I did some research on this and quickly discovered that ‘when’ you identify and address security issues during the development process dramatically impacts the cost of fixing said security issue(s).

OK, so at this point, I had enough information to craft a plan for an interesting research project and I got started. I chatted with some colleagues, both on the AD&D and S&R sides of the table, spoke with several service providers and, for the best real world examples, many client development organizations. The goal of this research was to identify strategies development organizations (not S&R teams) utilize to instill and maintain the appropriate level of security coding awareness in developers. I’m most interested in mobile development, but the things I learned affect all types of development, only the primary risks change.

My initial research culminated in a report titled App Security Can’t Happen Without Developers. The report is finished and has entered the editing process, so you will be able to read it before too long. This started what I think will be an ongoing area of study; I’m not trying to become a full-time security professional, I want to keep with my AD&D roots, but this is something that really interests me and I hope to keep writing about it. If you have interesting insights on how to impart security awareness in developers or have specific examples of how your development organizations does this effectively, please let me know, I’d love to chat about it and, of course, include it in a future report.