No love lost between security specialists and developers
GitLab finds 68% of security professionals feel that less than half of developers can spot security vulnerabilities, but most people feel it’s a programmer’s job to write secure code.
Unless you’ve been under a rock, you’ve noticed hardly a day goes by without another serious security foul-up. While there’s plenty of blame to go around for these endless security problems, some of it goes to developers who write bad code.
That makes sense. But when GitLab, a DevOps company, surveyed over 4,000 developers and operators, they found 68% of the security professionals surveyed believe it’s a programmer’s job to write secure code, but they also think less than half of developers can spot security holes.
Everyone knows security needs to be baked into the development lifecycle, but that doesn’t mean it is. The survey showed long-standing friction between security and development teams remain.
Nearly half of security pros surveyed, 49%, said they struggle to get developers to make remediation of vulnerabilities a priority. Worse still, 68% of security professionals feel fewer than half of developers can spot security vulnerabilities later in the life cycle. Roughly half of security professionals said they most often found bugs after code is merged in a test environment.
At the same time, nearly 70% of developers said that while they are expected to write secure code, they get little guidance or help. One disgruntled programmer said, “It’s a mess, no standardization, most of my work has never had a security scan.”
Another problem is it seems many companies don’t take security seriously enough. Nearly 44% of those surveyed reported that they’re not judged on their security vulnerabilities.
So, if you’re under the gun to get the code out and you know no one’s paying attention to security, what would you do? That’s right. Hang security.
Underlining this, a recent study found that, left to their own devices, many freelance programmers didn’t bother to secure passwords in a business assignment. In short, many developers don’t think about security when writing code.
The survey may be new, but the clash between security and developers is ancient. As Linus Torvalds, Linux’s creator, once said, “security problems are just bugs.” And security hardening patches should never result “in killing processes. The only process I’m interested in is the _development_ process, where we find bugs and fix them.”
Torvalds continued, “From a security standpoint, when you find invalid access, and you mitigate it, you’ve done a great job, and your hardening was successful, and you’re done. “Look ma, it’s not a security issue anymore,” and you can basically ignore it as “just another bug” that is now in a class that is no longer your problem.”
10 dangerous app vulnerabilities to watch out for (free PDF)
But merely fixing the security issue is only the beginning of a programming fix. Torvalds wrote, “From a developer standpoint, things _really_ are not done. Not even close. From a developer standpoint, the bad access was just a symptom, and it needs to be reported and debugged, and fixed, so that the bug actually gets corrected.”
In short, Torvalds, and many other programmers see security experts as getting in the way of creating productive code. Security to them is not job No. 1 if it gets in the way of making working code. Good programs require both security and functionality.
Colin Fletcher, GitLab’s manager of market research and customer insights, wrote: “Our research tells us that while most developers are aware of the dangers that vulnerabilities present and want to dramatically improve their security capabilities, they often still lack organizational support for prioritizing secure code creation, increasing secure coding skills, and implementing automated scanning and testing tooling to make that happen sooner rather than later.”
From GitLab’s viewpoint, the answer is a good DevOps practice. One of the keys to this is to make security a part of DevOps. Then, the combined team is three times more likely to discover bugs before code is merged.
By discovering security vulnerabilities earlier on in the pipeline, not only are the results more secure, there’s likely to be less friction between security and developers. They may never love each other, but at least they can get along better. And that is good news for any company.