A recent Forrester Research survey of security professionals found that fully one-third of them had experienced a security breach. And it’s important to realize the code is now the primary target, rather than the infrastructure. Making things even trickier, some estimates suggest close to 60% of applications are made up of open source code – and others put those estimates as high as 80% or 90%. Open source code is something that’s inherently more vulnerable than code generated from scratch, but it’s an understandable choice for busy developers trying to meet ever-tightening deadlines.
For years, security was part of a separate organization known to swoop in after the code was committed, find problems and demand changes from (perhaps not surprisingly) reluctant developers who’d already moved on to the next project. Security was not just an afterthought; it was a top-down experience delivered by people who were far removed from the challenges of development. It’s not at all hard to understand why this approach was a major source of frustration for everyone involved.
The goal of DevSecOps was to build on the silo-busting that happened when DevOps was implemented – now dev, ops, and security all work together. It’s still early days, of course, but our 2020 Global DevSecOps Survey showed promising signs: Almost 28% of security professionals said they’re part of a cross-functional security team for the first time, while nearly as many said they’re now part of the development process.
But serious friction between developers and security remained. For the second year in a row, our survey found a sizable majority of security pros continued to complain that developers found far too few bugs and that those they did find were discovered too late in the process. They also said it was difficult to get devs to actually fix the problem.
From the developer side, the issue was clear: Most companies weren’t running many, or any, security scans, and for those that did, just a fraction gave devs access to the results within their coding environment. No one likes context-switching, but for developers it can be especially challenging and lead to “out of sight, out of mind” outcomes.
To break what feels like a very vicious cycle, experts say it’s time to start thinking about in-context or developer-first security. In a nutshell, dev-first security gives a coder a “developer-friendly” security tool that lives in the IDE and empowers finding and fixing bugs in a painless manner. Ideally the security portion will be something that’s automated, allowing a busy developer to not have to think about bugs; the process will just happen naturally as part of the coding process.
Key to the success of developer-first security is a change in perspectives on both sides. Security pros need to remember devs wear a lot of hats (coding, testing, security, and even some ops functions) while they are able to focus solely on vulnerabilities. Given that, it’s vital that security pros spend time understanding what developers are asked to do – and perhaps learn to code? – in order to provide the necessary training, encouragement and empathy. At the same time developers have to be open to a process change and excited about the opportunity to contribute to code security in a meaningful way.
Moving security in with the development team, ensuring teams have the right mix of skills, and creating a collegial environment will go a long way toward a successful developer-first security effort.
GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.Try GitLab Free