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 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, though, 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 should nowadays be an ongoing and embedded part of the development and delivery processes.
But what are the practicalities of this? Do developers – ie, those writing the code – need to take more responsibility for software security? If so, then what do they need to step up, without killing their productivity, destroying their morale, and risking them walking off to the competition? Perhaps security is best left to the specialists and operations teams after all?
We know you have a view on this discussion, so let us know what you think in our latest Reg reader study.
source:-theregister
