What is DevSecOps?

Freshen up how you build security into your software pipeline. In this article, we’re setting you up for DevSecOps success with the seven core principles:

1. Shift left security
2. Holistic automation
3. Continuous security testing
4. Collaborative culture & communication
5. Security as code
6. Observability
7. Continuous improvement

We’ll also set the stage with a bit of DevSecOps overview and then point you on your way with some best practices for implementing DevSecOps. Let’s get started.

DevSecOps overview

DevSecOps is an evolution of the DevOps methodology. Its goal is to enhance the way developers, IT operations, QA and InfoSec teams approach security in the software development lifecycle (SDLC). Despite the focus of DevOps teams toward improving software quality, security often remains an afterthought.

As we know, security serves a critical goal toward software quality that must be baked into the SDLC process — early and thoroughly all phases of the lifecycle. So, we can think of DevSecOps as an integration of culture, responsibility, tools and best practices for security throughout the SDLC pipeline, across all activities:

• Software planning and design
• Development and testing
• Delivery
• Deployment

The value & benefit of DevSecOps

DevSecOps doesn’t just provide enhanced application security — it front-loads considerations like  security risks and vulnerabilities much earlier in the development cycle, helping to avoid surprises later.

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.

Finally, DevSecOps enables 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 disrupting the workflow.

Not sure what DevSecOps might mean for your organization? Here are some areas that it can absolutely support:

And with that background, let’s take a look at how we actually implement DevSecOps.

DevSecOps concepts & principles

So, just how do we integrate security? Let’s review the key principles of DevSecOps that teams should be working into their SDLC workflows.

1. Shift left security

DevSecOps teams work with cybersecurity experts early during the SDLC process, a major shift from traditional DevOps. In DevSecOps, cybersecurity becomes a shared responsibility of all members of the DevSecOps teams. That means that software design and implementation follows security best practices, considering areas like:

• Potential security vulnerabilities
• Threat vectors
• Compliance regulations

When shifting security left (towards the beginning of the SDLC), every software build is configured for security — optimized for performance, cost, time to market and other key business goals. This enables the team to identify early the security risk and exposure, enabling a secure build for every integration into the CI/CD pipeline.

(Read more about shift left security.)

2. Holistic automation

Adopt end-to-end automation for extensive testing and CI/CD processing. Within DevSecOps, automation is adopted as a strategic and well-informed decision— instead of merely automating any and all manual processes. After all, automating waste processes only compromises software quality.

In such cases, any rework to address quality issues tend to come at the expense of security performance. This practice goes against the concept of DevSecOps.

Instead, DevSecOps teams ensure that cybersecurity testing is thoroughly integrated into the automation processing, checking for:

• Software dependencies
• How every change impacts the overall security performance of the software application

3. Continuous security testing

The practice of Continuous Testing is extended by introducing automated testing functions that analyze build quality for security vulnerabilities. Within DevSecOps, Devs and QA teams collectively adopt the responsibility for improving software quality by continuously testing every build — in fact, the process is integrated into the CI/CD pipeline. These include:

• Static application security testing
• Dynamic testing functions

You can also develop a threat model and establish security policies early during the SDLC process. Automated remediation tools may be adopted to address frequent vulnerabilities that are introduced as Devs and QA teams follow rapid release cycles and fast sprints at the pace of DevOps.

(Learn about autonomous testing, an emerging technology that harnesses ML to create and drive software testing.)

4. Collaborative culture & communication

Organizations are expected to make it easier for DevSecOps team members to collaborate and communicate. In a traditional enterprise IT setting, Devs, QA, Ops and InfoSec teams tend to work in silos, each team adopting their own policies and objectives. These goals are often conflicting and ultimately require a superseding policy that dictates the priority objectives.

From a DevSecOps perspective, this is impractical: An unknown consequence, security malpractice or un-informed decision can have a lasting negative impact on the overall software quality and performance.

5. Security as code

To make it easier for Devs and QA teams to configure and develop customized automation workflows for security testing, users can treat security policies, procedures and controls as code.

Security as Code ensures that continuous and automated security testing does not introduce unnecessary cost and delays to the SDLC processing. Security testing processes run alongside functional testing within the automated CI/CD workflows — Devs and QA teams can automatically work on the results and improve security performance with the programmable approach to security, as the tools, metrics, testing scope and configurations are reused.

The testing procedure also follows consistent policies, which are agreed upon during the security planning and initial design phase.

6. Traceability, auditability & visibility

One of the most important goals of DevSecOps is to deliver insights that help create a reliable environment for achieving the desired security performance of the SDLC pipeline. In order to achieve this goal, DevSecOps follows three characteristics:

• Traceability: Carefully tracking configuration items for compliance and to understand how security issues and policies are handled. 
• Auditability: Ensuring that the process is well-documented. Administrative controls, policy implementation and security decisions should be tracked for audits and accountability.
• Visibility: Strong monitoring and observability capabilities are adopted to achieve a holistic and end-to-end view of the security performance across the SDLC pipeline.

The work that sums up these concepts is observability. Learn more about the benefits of Observability and Explainability in SDLC in this blog post by Splunker Sandeep Kampa on DevOps.com.

7. Continuous improvement

Since security threats continue to evolve and new development sprints can be exposed to different security risks, DevSecOps aims to iteratively improve the security capability by incorporating feedback on a continuous basis. This feedback comes from…

• Multiple functional teams
• Executives and business decision makers
• External partners
• End-users in the real-world environment

Make provision in the beginning to ensure that security related feedback can be incorporated across iterative sprints and release cycles.

(Track your security operations success with these metrics.)

Challenges of succeeding at DevSecOps

OK! These concepts clearly highlight just how important it is to build security into the entire software development lifecycle. So, why are dev teams still struggling so much? Some common obstacles that teams experience are:

• Staff might resist changing 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. Consider some organizational change management best practices to alleviate this.
• Two concepts, two viewpoints. Historically, developers may have a poor understanding of security threats and security practices. Conversely, security professionals often had a poor understanding of the development process, making it difficult to integrate their laser-sharp security focus with the workings of software development.
• 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.
• Learning new tools is tricky. 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.

Best practices for succeeding at DevSecOps

DevSecOps is part strategy, part toolkit, part training and part cultural shift. That means, unfortunately, there’s no universal playbook on how to “do DevSecOps”.

Still, armed with the seven core concepts and these best practices, you’ll be well on your way!

• Embrace continuous delivery. Ensure or revamp your software delivery process to focus on smaller, more frequent release cycles.
• Integrate security staff with your DevOps teams. 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.
• Implement continuous security monitoring tools. Once code is deployed in the marketplace, the “Ops” component kicks in, and applications must be actively and continuous monitored to ensure 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 are not experts in security. DevSecOps works best when everyone is cognizant of standard security principles and requirements.

DevSecOps enables speedier, reliable software delivery

By following DevSecOps principles, enterprise IT teams can achieve two important goals: speed of SDLC release cycles and reliable software delivery in context of the evolving security risks, changing user expectations and strong regulations applicable to different industries and geographic locations.