What Is DevSecOps?

DevSecOps is important because it doesn’t just raise awareness about application security issues and the development environment, it actually makes these applications and environments safer. It improves communication between developers and security pros and directly embeds security in the development process. DevSecOps aligns everyone with the simple mandate that all code must be secure at every step of the development process.

DevSecOps has become particularly important in recent years due to the increase in speed of code releases. Cloud tools and agile development methodologies have hastened the development cycle even further, and many traditional security tools and methodologies are unable to keep up.

By adopting DevSecOps practises, organizations are able to build more secure applications at a faster pace. Vulnerabilities are discovered earlier in the development cycle, allowing for fewer fire drills later in the process and overall better quality code. While initially developers may think that developing with security in mind impedes innovation, over time they most likely will grow to see the value of a DevSecOps approach, particularly as organizations increasingly use automated tools to tackle their security needs.

The concept of DevSecOps first emerged in January 2012 in a (since deleted) blog post by Gartner’s Neil MacDonald, who suggested that the vision of DevOps was “incomplete without the incorporation of information security, which represents yet another silo in IT.” MacDonald noted that 75% of successful attacks against systems were targeted at vulnerabilities that were already known and which could have been prevented if only developers had taken the time to apply necessary patches or updated configuration standards. His vision — known as DevOpsSec at the time — suggested that “information security must change in multiple ways … becoming more adaptive and programmable and making information security representation an integral part of DevOpsSec teams.”

Over time, the “Sec” in DevOpsSec migrated to the middle of the term, in part representing a security-driven bridge between development and operations. Complicating matters is the recent rise of another related term, SecDevOps, which suggests that security should be considered before anything else in the development process.

Today, DevSecOps is making inroads in the industry. According to a recent study conducted by IDC and Micro Focus, the global pandemic has accelerated DevOps and DevSecOps adoption, driving demand for new services and more frequent use of applications. Thus, almost three-quarters of all firms have accelerated their DevSecOps initiatives. However, while companies are placing more efforts around cybersecurity, only 45% said that the integration between their software development, operations and security was unified, while more than half gave their company's efforts a low rating. Consequently, nearly a decade after the concept of DevSecOps first emerged, progress remains fairly slow.

At a fundamental level, the difference between DevOps and DevSecOps is one of integration — while many DevOps methodologies include security as part of the process, DevSecOps places dedicated emphasis on security, integrating it into every step along the way. Like DevOps, DevSecOps includes among its goals the speedy development of applications, but DevSecOps aims to maintain the pace of DevOps while also ensuring consistent application security testing and other strong security processes.

DevOps practices and DevSecOps share many traits in common, both relying on strong communication among developers and operations professionals, reliance on automated tools to speed up delivery, and a continuous development cycle that breaks from the old “waterfall” methodology. However, with DevSecOps, all of those traits include elements of security. In a DevSecOps environment, security professionals will be embedded with the developers and IT operations team, tools will include systems that help automate security testing and code analysis, and the continuous integration and CD pipeline processes will include routines that call for security checks before any code is allowed to proceed to public launch.

In practice (per a recent report from Security Compass), adopting DevSecOps will often address issues that slow the DevOps development cycle, but most experienced DevSecOps shops note that automation of security and compliance routines can greatly improve cycle time.

Agile processes were designed to help with the management of development projects and to improve delivery time by reducing their complexity; this is done by creating small teams that work closely together and operate using a “sprint” structure to deploy code updates incrementally.

Like agile, DevSecOps is also built around a continuous development and testing process, using a cycling build-test-deploy workflow to keep delivery frequency high while ensuring overall high quality of code.

The two disciplines are not mutually exclusive. Agile shops can — and often do — also adopt DevSecOps principles or create some kind of hybrid structure that merges the two approaches. 

The main difference is that agile development methodologies (e.g. Scrum and Extreme Programming) have more to do with how development teams are structured and how developers create code. DevOps is more focused on how code is compiled and released. Agile methodologies result in iterative code changes at a faster cadence, necessitating automation and DevOps practices. Technically, DevOps practices and tooling can exist without agile development methodologies, but the reverse situation is less true.

Another difference between agile and DevSecOps, of course, is that agile was not explicitly envisioned with security top of mind, while DevSecOps stresses the importance of integrating security in the development process from the start. In many agile shops that have not also adopted DevSecOps practices and strategies, security remains an afterthought. However, both disciplines often work together and, in many respects, need to.

As with adopting any new methodology, DevSecOps can be a challenge to implement and sustain over time, making automation and scripted environments critical components.

Some of the biggest obstacles are as follows:

• Staff might resist changing organizational structure. Staff may be more comfortable with their current working cohort and may resist adding security professionals to a group they feel is working well already. Many may claim that changing the working structure will slow down development and reduce quality, rather than improve them both.
• Security is inherently poorly understood: Historically, many developers have had a poor understanding of security threats and security practices. Conversely, security professionals have often had a poor understanding of the development process, and integrating their laserlike focus on security with the fast-paced world of modern development can be difficult.
• Traditional security practices scale poorly. Traditional waterfall models are slow and tedious processes, which often don’t mesh well with the breakneck pace of modern development. However, reconciling the two makes security automation tools a necessity in DevSecOps environments.
• New tools must be adopted and learned. DevSecOps adopters will find that they must ask staff to work with new people and development processes. Similarly, security professionals will have to master development-centric tools.

DevSecOps doesn’t just provide enhanced application security, it front-loads considerations such as security risks and security vulnerabilities so they are addressed much earlier in the development cycle, helping to avoid surprises later in the game. Because DevSecOps relies heavily on automated security tools, its ultimate value is generated from the integration of security into the DevOps continuous development process, essentially making it possible for the organization to embrace “continuous security.” As security threats continue to evolve in their sophistication, DevSecOps provides a strong tactical methodology for mitigating them, giving security testing a critical and much more visible role in the software development life cycle.

DevSecOps also allows you to build more secure apps, with security for the software factory and secure production — all three essential to the foundation of building a holistic, security-oriented practice. And finally, it allows you to have a centralized understanding across the entire team development environment — QE, DevOps, SRE and security — giving teams the ability to align on work processes and objectives without having any disruption in the flow.

DevSecOps is part strategy, part toolkit, part training and part cultural shift. As such, there’s no universal playbook on how to implement DevSecOps, but the following general steps can put you on the path.

• Embrace continuous delivery. If your organization has not already embraced the continuous delivery and integration of development and operations teams that a DevOps approach provides, your first step is to get on board. By revamping your delivery process to focus on smaller, more frequent release cycles, you set the stage for the required operational shifts as you migrate to DevSecOps.
• Align and integrate security with your DevOps team’s workflow. Integrate security and embed security professionals within DevOps teams, rather than trying to embed developers in the security group. The goal is to incorporate security tools, including automated security testing, directly into the development process.
• Load up on automated DevSecOps tools. Adding extra routines in the form of new security operations and checkpoints will naturally slow down the development pipeline, possibly leading to frustration in your development team. Keeping as much as possible automated will keep throughput and functionality high.
• Implement continuous security monitoring tools. Once code is deployed in the marketplace, the “Ops” component kicks in, and applications must still be actively monitored to ensure their security over time. When vulnerabilities are discovered, the organization must be ready to enact a remediation plan to correct them.
• Train staff extensively on security. Your development team is unlikely to be well-versed in security protocols, and even if they are not the first line of defense, it’s important to get them up to speed. DevSecOps works best when everyone is cognizant of security principles and requirements.
• Remember that security is part of your culture. Security isn’t just a set of tools and techniques, it’s a state of mind. Lead by example, be transparent with staff about expectations, and reward team members for embracing and implementing DevSecOps principles.

DevSecOps is not created by simply taking your development, operations and security team members and putting them together. In fact, many different DevSecOps structures exist, ranging from relatively siloed designs where all three sides work independently to fully integrated operations where duties are freely shared among team members. In general, the goal should be to create a structure that provides as much collaboration and transparency as possible.

Here are some additional tips on how to integrate DevSecOps into your operations, engineering and security teams for the maximum chance of success.

• Focus on existing team members before adding new ones. Your existing staff probably has a lot of institutional knowledge, so don’t let that talent go to waste. While most DevOps teams have a need for new blood and new skills, the most effective teams are likely to be a blend of veterans and newcomers.
• Assess what skills you need. Are your developers on fire, but you have no security expertise in-house? Is your operations team generally under-experienced? By tallying up the skills you have and are lacking, you can easily recruit to fill these gaps. The effectiveness of the team’s leadership should also be carefully considered as part of this analysis. (New developers generally gravitate to positions where strong leaders can teach them new skills.)
• Allow for experimentation (and failure). DevOps and its successors are built around creating a collaborative, blameless structure that is designed to improve over time. Allow these teams to experiment with structure and workflow, and provide a mechanism to reflect on what works and what doesn’t. Reward the team liberally for both its successes and “good efforts” that didn’t pan out.

To maximize your chance of long-term success, it’s important to keep focused on building a culture that supports your DevSecOps team members.

• Focus on cooperation. Many DevOps and DevSecOps implementations fail due to infighting and departmental silos. Don’t let this happen — instead, reward openness, cooperation and knowledge sharing that encourages continuous improvement over time.
• Give teams authority and autonomy. Avoid dictating processes and tools to the team. Teams should have the authority to figure these issues out on their own, which in turn will bolster their camaraderie and improve culture.
• Support DevSecOps with strong leadership. If management does not demonstrate a strong commitment to security, there’s no real hope of the rank and file doing the same. Unless security is a clear mandate from the CEO down, it will be virtually impossible to build a culture that treats the topic with the seriousness it requires.
• Invest in education. Make efforts to align the skills of your DevSecOps team members. Focus on ensuring developers have access to security training while also immersing security professionals in DevOps methodology. The ultimate goal: Ensure that everyone in the organization understands that security is a universal goal.

DevSecOps has hardly become a universal approach to development and security. Still, DevSecOps continues to look more and more like a corporate necessity. Threats are on the rise, and the damage caused by successful attacks is getting worse. According to a Digital Guardian study, the average cost of a single corporate data breach in 2019 was $8.2 million, or $242 per breached record. For healthcare companies, the cost per breached record is nearly twice that; these breaches can take nearly eight months to identify, and even longer to actually clean up. Any effort that can be undertaken to help stem this costly tide can be of considerable benefit to the enterprise, and DevSecOps can be a key tool in that arsenal.

DevSecOps isn’t the only line of defense against hackers and other malicious exploits, but it is a strong first line of defense. By rethinking the DevOps pipeline with a strong focus on security, the enterprise can set itself up with a much stronger security focus from the start, rather than attempting to remediate damage from an attack that has already taken place. Too many organizations have paid the price of downplaying or ignoring the need for security. By leveraging DevSecOps, you can take another step to keep from joining their ranks.