Well, no, of course they are not – no more than anybody else of course. I wanted to get that in quickly, before I pulled on my flame-proof suit! But meanwhile, there is a general perception that code is not always developed with security in mind. Why is this? I’d put it down to the following reasons:
Awareness. Developers are not security experts, and nor necessarily should they be. But this does mean that things that might be obvious to a security guy – “what do you mean, you let the message pass across the Internet in clear???” – may not be so obvious to the programmer. Some base principles such as security by obscurity, and the fundamentals of data protection should be familiar to even the most lowly of coders.
Timescales. I was presenting at an InfoSecurity Today webinar yesterday when I was asked about what’s preventing people from getting security right first time. There was a considerable level of sage nodding around the table when I brought up the point about project milestones getting in the way – particularly if one is asked to squeeze in a few extra features just before the deadline. Its a familiar story.
Tooling. There are tools that can automatically deal with some of the developer security workload, such as Fortify, or Watchfire from IBM. Such tools can be difficult to budget for early on in the project, and even harder when the money starts to run out later.
Design. A study we conducted earlier in the year suggested (quite strongly) that there can be an air of “let’s hope it works” early in the project, particulalrly when it came to application resilience. Of course this can come down to money – it can be difficult enough to justify a project at all, never mind when all the security bells and whistles are added.
Visibility. Some of the content of yesterday’s event was based on a previous Freeform Dynamics report, which showed how the security of test data was not clearly articulated to the business risk manager. There is a broader point here, around development shops being sufficiently far removed from the business, that they aren’t necessarily subject to the same levels of scrutiny as others.
Its all food for thought isn’t it? But the bottom line is, however good and diligent are the people involved, factors such as these may well conspire against them to result in a les than secure application. Does this picture equate with your own experiences? I’d be very interested in your feedback.
Through our research and insights, we help bridge the gap between technology buyers and sellers.
Have You Read This?
From Barcode Scanning to Smart Data Capture
Beyond the Barcode: Smart Data Capture
The Evolving Role of Converged Infrastructure in Modern IT
Evaluating the Potential of Hyper-Converged Storage
Kubernetes as an enterprise multi-cloud enabler
A CX perspective on the Contact Centre
Automation of SAP Master Data Management
Tackling the software skills crunch