In the early years of software development, you would often design it, build it, and only then think about how to secure it.
This was arguably fine in the days of monolithic applications and closed networks, when good perimeter-based protection and effective identity and access management would get you a long way towards minimising the risk. In today’s highly connected, API-driven application environments, however, any given software component or service can be invoked and potentially abused in so many different ways. Add to this the increasing pace of change through iterative ‘DevOps-style’ delivery and ever-faster release cycles, and many understandably assert that security management and assurance nowadays needs to be an ongoing and embedded part of the development and delivery process.
But what are the practicalities of this? Do developers – i.e. those writing the code – need to take more responsibility for software security? If so, what do they need to enable them to step up? And whatever you do to bake security into the development and DevOps cycle, how do you do it without killing productivity, and stifling freedom, flexibility and responsiveness, never mind destroying morale?
These were some of the questions we explored recently in an online survey of 183 respondents involved in designing, building, delivering and/or securing applications and services. The study was conducted via The Register IT news site and threw up some very interesting results.
Download the Research Note to read more …
