Since its introduction more than a decade ago, DevSecOps has promised more secure software, which leads to more secure cloud and hybrid environments. By integrating security early in the development lifecycle, also known as “shifting left,” DevSecOps should make it easier to continuously deploy secure applications. Developers write secure code, analysts test that code before the application is delivered, and then you lather, rinse and repeat your way to stronger security. But no code is bulletproof, and more than ten years later, DevSecOps is still more of an idea than an effective practice.
Why DevSecOps is a myth
There are several reasons why DevSecOps isn’t at a point where it’s widespread and successful. Developers aren’t security experts, and security teams often lack the resources to continuously test the code those devs create while still doing their day-to-day tasks. Sometimes bureaucracy or a lack of buy-in gets in the way. Effective DevSecOps requires commitment from several teams in the form of budget, human resources, and time. Another related point of failure could be data and communication silos that isolate security and development teams from each other. For DevSecOps to work, everyone needs to be on the same page and able to support the group.
Let’s dig a little deeper into some of these challenges.
Developers are really good at what they do, but they’re generally not security experts. Historically, being security-minded wasn’t a job requirement. DevSecOps may force a change in that mindset, but there are no guarantees that change will come quickly or easily. While there are security training programs for developers, how quickly that training becomes a job requirement isn’t clear at the moment. Currently, developers usually need help ensuring that they have secure headers, templates, and frameworks for specific assets like VMs, containers, and Lambda functions.
Writing secure code is even more difficult in multicloud environments because there isn’t a one-size-fits-all application that works across Cloud Solution Providers (CSPs). Even if it’s the same kind of app, it has to be written for each environment. All those challenges combined mean that developers need to lean on security teams, but that’s difficult for a couple of reasons. Like developers, security analysts need to learn the ins and outs of each CSP, and there’s also a sizable gap between open jobs and available analysts. In fact, an (ISC)2 workforce study pegs the number of open positions at more than 2.7 million worldwide.
Developers severely outnumber security teams. Some estimates have the disparity as high as 100 developers for every security analyst. That sort of imbalance makes shifting left via testing early in development lifecycles incredibly difficult. While automation can take some of the burden of testing off of security teams, SANS estimates that only 50% of organizations use automated testing, with 27% offering no testing at all.
When combined, those testing and workforce figures make leaning fully into DevSecOps a difficult proposition at best. Organizations still need to take additional steps to defend their cloud against advanced threats.
Three steps you can take to defend your cloud
DevSecOps, in its current form, is better as a concept than it is in execution. Even now, after years of learning curve and implementation attempts, DevSecOps causes more problems than it solves. A recent report states that only 15% of organizations integrate security throughout the development lifecycle. The same report suggests that insecure assets make it into cloud environments too frequently, with 58% of respondents admitting that their development teams have released apps with security vulnerabilities. As a result, almost half (45%) of those organizations subsequently reported a breach.
There is a better way to defend your cloud environment, and you can do it in three steps.
Step 1: Rely on your security team, not developers, for securing critical assets. Under this realistic approach, developers are not asked to carry so much of the security load via writing secure code. Rather, the development team is a small part of a much larger cross-functional security ecosystem. Helping developers create secure code and ensuring that the lines of communication between Dev and security are open, but understanding that there are gaps in early testing processes and no code is bulletproof, is essential. While thinking about the “Dev” part of DevSecOps is important, security teams will still need the proper tools and processes to protect workloads and applications after they make it into production environments. And that leads us to our next step.
Step 2: Follow widely accepted security best practices. This step will do more for keeping your cloud safe than heavily relying on DevSecOps processes early in the development lifecycle. Think of this step as shifting right with continuous vulnerability scans and testing after you release applications. And while this is incredibly obvious, it still bears mentioning: you need to put guardrails in place such as limiting permissions and strengthening IAM policies. Reducing trust and layering defenses are essential for post-deployment security and understanding your cloud environment is a foundational next step for staying secure.
Step 3: Enhance your visibility, monitoring, analysis, and threat detection capabilities. While the first two steps are important, this step is essential to defending against threats that make it past perimeter defenses or take advantage of insecure code. Visibility must include accurate inventories of assets across IaaS and PaaS environments, as well as for containerized and serverless deployments. And, given the realities and challenges of hybrid and cloud security, whatever tool you choose must work across cloud service providers. If you can monitor and analyze one or more sources of network telemetry in a single tool, you’re also able to cut down on complexity and silos, reducing stress on your security team while making their jobs easier.
The reality is that leaning on network telemetry won’t make DevSecOps immediately viable at scale, but it will help identify the threats that use insecure and often untested code as a way to enter your cloud environment. And if you’re still intent on relying mostly on DevSecOps processes despite the security challenges they create, you’ll definitely need that layered visibility and threat detection to defend your cloud.
