Since its introduction more than a decade ago, DevSecOps has promised more secure software, leading to more secure cloud and hybrid environments. By integrating security early in the development lifecycle, also known as “shift left,” DevSecOps should make it easier to continuously deploy secure applications. Developers write secure code, analysts test that code before the app is delivered, and then you lather, rinse, and repeat your way to greater 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 is not at a point where it is widespread and successful. Developers are not security experts, and security teams often lack the resources to continuously test the code those developers create while still going about their daily business. Sometimes bureaucracy or lack of buy-in gets in the way. Effective DevSecOps requires the commitment of multiple teams in the form of budget, human resources, and time. Another related point of failure could be data and communications silos that isolate security and development teams from one another. For DevSecOps to work, everyone needs to be on the same page and able to support the group.
Let’s dive a little deeper into some of these challenges.
Developers are really good at what they do, but they are generally not security experts. Historically, being concerned about safety was not 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, it’s unclear at this time how quickly that training becomes a job requirement. Currently, developers often need help ensuring they have secure headers, templates, and frameworks for specific assets like virtual machines, containers, and Lambda functions.
Writing secure code is even more difficult in multi-cloud environments because there is no single application that works across all cloud solution providers (CSPs). Even if it is the same type of application, it must be written for each environment. All of those challenges combined mean developers have to rely on security teams, but that’s difficult for a couple of reasons. Just like developers, security analysts need to know the ins and outs of each CSP, and there is also a considerable gap between available jobs and available analysts. In fact, a (ISC)2 Workforce Study sets the number of open positions at more than 2.7 million worldwide.
Developers vastly outnumber security teams. Some estimates have a disparity of up to 100 developers per security analyst. That kind of imbalance makes shifting left through testing early in development life cycles incredibly difficult. While automation can take some of the testing burden off security teams, SANS estimates that only 50% of organizations use automated testing, and 27% offer no testing at all.
When combined, those testing and workforce numbers make leaning entirely on DevSecOps a difficult proposition at the best of times. 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 in concept than 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 find their way into cloud environments far too often, with 58% of respondents admitting that their development teams have released applications with security vulnerabilities. As a result, nearly 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 – Trust your security team, not developers, to protect critical assets. Under this realistic approach, developers are not asked to carry much of the security burden by 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 the lines of communication between Dev and security are open, but it’s essential to understand that there are gaps in early testing processes and no code is foolproof. While it’s important to think about the “Dev” part of DevSecOps, security teams will still need the right tools and processes to protect workloads and applications after they hit production environments. And that brings us to our next step.
Step 2: Follow widely accepted security best practices. This step will do more to keep your cloud secure than relying heavily on DevSecOps processes early in the development lifecycle. Think of this step as a shift to the right with ongoing vulnerability scanning and testing after applications are released. And while this is incredibly obvious, it’s still worth mentioning: You should implement security measures like limiting permissions and hardening IAM policies. Reducing trust and layered defenses are essential to post-deployment security, and understanding your cloud environment is the critical next step in staying secure.
Step 3: Enhance your threat visibility, monitoring, analysis, and detection capabilities. While the first two steps are important, this step is essential to defending against threats that get past your perimeter defenses or take advantage of insecure code. Visibility should include accurate inventories of assets in IaaS and PaaS environments, as well as for containerized and serverless deployments. And, given the realities and challenges of cloud and hybrid security, whatever tool you choose must work across all cloud service providers. If you can monitor and analyze one or more network telemetry sources in a single tool, you can also reduce complexity and silos, reducing stress on your security team and making your job easier.
The reality is that relying on network telemetry won’t make DevSecOps immediately viable at scale, but it will help identify threats that use insecure and often untested code as a way to get into your cloud environment. And if you still intend to rely primarily on DevSecOps processes despite the security challenges they create, you’ll definitely need that layered visibility and threat detection to defend your cloud.