4 compelling reasons you should implement a DevSecOps approach

By Richard Harpur

If you are responsible for building or maintaining software in an engineering or IT role, you should have a vested interest in that software being secure. Yet companies are finding themselves faced with an increasingly complex threat landscape with a lack of skills, resources or capacity to consistently fend off attacks. 

The DevSecOps approach has been positioned as a salve to this issue, combining the best parts of DevOps with a mindset that bakes in security protocols, filters and best practices at the start of the development process instead of the end. Done right, DevSecOps can streamline what you can accomplish even with limited headcount, save organizations money and eliminate shoddy security practices forever. 

We’ve gone in-depth on the overall process of enabling low-risk releases with a sound DevOps approach (you can find parts one, two, three and four of this four-part series here). But even with all the “how-to” knowledge to be successful, adding the “Sec” to a DevOps process is still a relatively new approach, and thus your journey to get buy-in may have a steeper uphill than you might expect. Mature organizations are often hesitant to risk moving from the reliability of an incumbent development process, even with the gains in efficiency DevSecOps brings to the table. This level of change will inherently be uncomfortable at first.

And that’s okay. Adopting a new mindset should take some time, and you need a compelling reason to do so tied to tangible impacts and benefits to your business. We’ve gathered some of those common benefits for you here, so consider this your cheat sheet for convincing your manager, your manager’s boss or even just yourself that it’s time to jump feet first into DevSecOps.

Reason #1: There is a global shortage of security professionals and cybersecurity skills

According to a 2020 survey of cybersecurity professionals by the Enterprise Strategy Group and Information Systems Security Association, 70% of respondents indicated that their organization has been significantly or somewhat impacted by the global cybersecurity skills shortage. This follows predictions from several cybersecurity groups and organizations that over the next several years, millions of cybersecurity job openings will go unfilled—with the rate of the skills gaps and job shortages rapidly increasing.

Couple this with an increasing number of high-profile data breaches hitting companies of all sizes, and it paints a pretty bleak portrait of the reality of security today. In the ESG and ISSA survey, for example, respondents were asked what impact the security shortage was having on their organization, with the following mentioned frequently: 

  • Increasing workload on existing staff

  • Cybersecurity staff spending a disproportionate amount of time on incident response

  • An increase in human error

  • Burnout and attrition among existing staff

  • An inability to utilize security technologies to their full potential

If you are reading this and work in a technology organization, there’s a good chance you’ve been impacted by this shortage. 

While DevSecOps certainly won’t be a magical cure-all for larger issues around technology skill shortages in general, it can put your development, IT and security teams as they are right now in a stronger security posture and overall position to succeed, largely because DevSecOps is a culture and mindset shift that’s doesn’t hinge on securing new headcount.

Reason #2: DevSecOps allows your security team to move faster

Above all else, the function of DevSecOps is to reduce friction so teams can operate at high velocity while bringing consistency in the form of a secure development process.

According to Shannon Lietz, DevSecOps leader for Intuit, “The purpose and intent of DevSecOps is to build on a mindset that ‘everyone is responsible for security’ with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.” DevSecOps works by moving away from the concept of a dedicated security team and, where appropriate and safe, moving decision-making to the person with the most context to make the right decision. 

To understand how DevSecOps helps your team move faster without sacrificing security, consider the development communities move from “waterfall” approaches to agile development.

In a waterfall approach, the time frame (from when a piece of software was requested to when it’s released) is very long. If the requirement for the project changes—or the testing that happens at the end exposes a critical issue—teams would have to revisit already-completed work before the project was fully finished. With agile, slices of work are released more frequently with testing embedded alongside the development process, allowing the process to deliver value consistently and provide a feedback loop for stakeholders with a smaller potential for catastrophic changes.

While not a direct match with the way the waterfall methodology approaches testing, modern security has often been treated the same way: tacked on to the end as an afterthought, an annoying barrier to get through. Like agile before it, DevSecOps implements security at every step along the way through concepts like threat modeling, vulnerability scanning, pen testing, code standards and real-time code analysis. These security functions no longer have to only happen once a quarter or once a year, and don’t have to grind the development process to a halt.

In short: DevSecOps implements a sustained security model, providing more value, more often.

Reason #3: DevSecOps replaces one-off, point-in-time security assessments

As your team moves away from quarterly or annual security assessments and embeds security testing and activities in the development process as part of DevSecOps, you not only move faster—you also get better security. Instead of just having a single snapshot of how secure your code is, you are constantly looking at it.

You achieve this repeatability by using code. Everything else in a DevOps lifecycle is already driven by code, so why not security?

Let’s look at the concept of patching, for example. With DevSecOps, you might make the decision to rebuild the environment on a daily or weekly basis, with that rebuild containing all the latest patches available. This represents a major shift from the traditional method of patching every 30 days, but it achieves the same result without introducing any compliance violations.

We can also introduce security in the CI/CD pipeline, implementing security testing just as you would do integration and unit testing, and deploying to a secure environment so that every environment you build has a secure baseline.

Reason #4: Deploying DevSecOps doesn’t have to rely on securing new budget

To reiterate: DevSecOps is not about standing up a new team that is “the DevSecOps team,” but rather is a cultural change. You can implement this cultural change even if you’re limited in your ability to bring new security roles on board. 

Let’s say you have a medium or large development group but not enough resources for a dedicated security practice; if some of your senior developers are stronger with security concepts and security practices, you can still put yourself in a position to meet security practices by embedding them in the pipeline. If you have them in your org, your existing security professionals can then transition away from the role of monitoring, blocking or being the person that says “no”—and focus on helping identify vulnerabilities in code. 

With open communication and visibility, your security team will become your development team’s best friend, and vice versa.

The value of a more nimble security approach

Implementing DevSecOps is not without pain. You can’t go out and buy it and plug it in; it’s a culture change that takes time to work well. It’s also not an overnight decision to switch over from the status quo, especially when the status quo is still delivering good enough results in the moment.

But there’s no doubt that the future of security is through scripted automation. 

Consider how Windows, once entirely GUI-based only, is now driven by scripts using PowerShell—or how the CLI is the primary method used to configure environments in AWS. It’s not a matter of if you decide to adopt a sustainable, automated, “baked-in” approach to security, but when.

With global disruptions forcing many businesses to radically rethink how they get work done, many are pivoting processes quickly. Speed and agility matter in today’s business stakes arguably more than, and DevSecOps gives you both—while ensuring sound security practices don’t get lost in the shuffle.

For a more in-depth look at DevSecOps, check out Richard Harpur’s Pluralsight course "DevSecOps: The Big Picture" or watch our free on-demand webinar “Adopting DevSecOps: The Holy Grail of Sustainable Security.”

About the author

Richard Harpur is a highly experienced technology leader with a remarkable career ranging from software development, project management through to C-level roles as CEO, CIO, and CISO. Richard is highly rated and ranked in Ireland's top 100 CIOs. As an author for Pluralsight - a leader in online training for technology professionals - Richard's courses are highly-rated in the Pluralsight library and focus on teaching critical skills in cybersecurity including ISO27001 and Ransomware. As a Certified Information Security Manager (CISM) Richard is ideally positioned and passionate about sharing his extensive knowledge and experience to empower others to be successful. Richard also writes extensively on technology and security leadership and regularly speaks at conferences. When he is not writing for his blog Richard enjoys hiking with his wife and 4 children in County Kerry, the tourist capital of Ireland. You can reach Richard on twitter @rharpur.