DevOps Security best practices

DevOps security is the application of information security policy and technology to the entire DevOps life cycle and value stream. Since DevOps tends to involve every stage of the software development life cycle (SDLC), effective security becomes even more critical.

For most organizations, information security isn't new. One of the primary concerns of information technology is: How can it be secured from compromise? However, DevOps infrastructure is a significant departure from the more traditional paradigms of IT. How can information security be successfully applied to DevOps?

DevOps VS DevSecOps comparison

Learn more about the transition from DevOps to DevSecOps here.

4 Primary Challenges of DevOps Security

Shifting from traditional models of IT and software development to the modern, agile focus of DevOps has given rise to new security challenges, requiring not only a shift in security tooling, but a shift in culture, people, and processes. Although DevOps is often thought of as the melding of development and operations, DevOps and security have remained separate.

1. Rapid Pace of Change

One of the more prevalent effects on security: DevOps has a rapid pace of change. In legacy environments, new infrastructure was typically provisioned as physical, bare-metal hardware, with a long cycle between a provisioning request and functional availability. Software development typically followed a waterfall cadence, with major releases happening every few months or quarters. In contrast, modern agile environments might see multiple production deployments in a single day.

Additionally, utilizing cloud-based infrastructure means that additional capacity can be scaled up in a matter of minutes, instead of hours or days. This all adds up to a significant increase in the rate of change for a given environment. Legacy technology and processes were not built to adapt to an environment with that much delta.

2. Cloud Security

Another challenge is a direct result of the prevalence of cloud-first architecture. Compared to a traditional, on-premise deployment, the cloud presents a much broader attack surface, with loosely defined and fuzzy network boundaries. Nearly any provisioned resource can be configured to be accessible to public internet traffic with just a few clicks or lines of code. Legacy network security operated under the assumption that the network would be well defined, with a handful of well-established ingress and egress vectors. Learn more about Cloud Security challenges.

3. Workload Containerization

This also introduces new variables into the security environment. They provide attractive features for modern development and deployment workflows, but the added complexity of the underlying engine, orchestration, and networking means more potential attack vectors that need to be monitored and secured.

4. Collaboration

Legacy security tools, technology, and process simply weren't designed with many of these use cases in mind. Siloed security and engineering teams will not scale with the rapid, iterative pace of a DevOps-first culture. Security and engineering, operating in isolated bubbles, will often duplicate operational effort and information flow that could easily be aggregated in one bucket.

Building one pipeline is also crucial so that teams are in sync and are getting the same information from the same source. In reality, however, it’s not uncommon to see things such as organizations running two Splunk agents on the same box—one for the security team and one for the application team; or a fraud team getting feeds from both security and infrastructure—each of which are running entirely separate and parallel event pipelines.

What About DevSecOps?

DevSecOps is the integration of the DevOps model; fast-feedback software delivery and organizational culture, with information security practices. Rather than DevOps security, in which information security is added to the stages of the DevOps cycle post hoc; DevSecOps seeks to integrate security and engineering objectives with a "shift-left" mindset.

Security is shifting left

Figure 2: Security objectives are being shifted left

DevOps security typically starts with a general mindset or posture. In DevOps security, tools aren’t the whole picture. DevSecOps practicesare not about checking off the boxes on a to-do list. If the team doesn’t have a security mindset, achieving the goal of having a secured platform will be next to impossible.

In DevSecOps, security objectives are applied to the different stages of the life cycle using provided tools and processes. Security teams may still be operating in discrete silos from engineering and ops teams, although a more collaborative culture may be present. While the model of shared responsibility between development and operations has been a core tenet of DevOps since its inception, security still typically involved outside interaction with a siloed security team or organization.

DevSecOps aims to integrate security objectives into the entire DevOps life cycle, particularly in the early stages of design and development. Security responsibilities are “shifted left,” giving developers ownership over security remediation before issues make it into higher SLA environments.

For companies with lean teams, shifting left can help alleviate some of the remediation burden held by security teams. In the case of Reddit, an automated API allowed a small security team to manage a large number of repos, and also empowered developers to own security remediation:

"After getting our repos clean, we flipped the script so that new pull requests would fail if there are any security vulnerabilities. This shifted Reddit away from a reactive security team initiated approach toward a developer-centric, developer-led approach for remediation. The only way we could manage all this work was using the Snyk API."

Spencer Koch, Security Professional at Reddit

The fast feedback capabilities of DevOps and DevSecOps tooling, particularly CI/CD, means developers can immediately respond to automated security feedback, eliminating manual review cycles and ensuring improved security posture throughout the SDLC.

Move from DevOps to DevSecOps

How does an organization make the move from a DevOps culture to one of DevSecOps? The answer might seem counterintuitive: They need to stop worrying about security. Instead, an organization needs to empower everyone to own security. There are some core strategies that can help start that process.

As described previously, shifting left is a key focus area for a serious DevSecOps effort. Moving security objectives earlier in the SDLC improves overall security outcomes. What does this look like? Rather than development teams kicking completed deployment artifacts over the wall for security to review and report on late in the SDLC, security seamlessly integrates with early-stage development cycles, including requirements gathering and design.

This isn't about forcing onerous requirements or additional process on top of existing workflows; the ultimate goal is to have the least amount of friction possible throughout each stage. DevSecOps means an organization can move to a secure software development life cycle (SSDLC).

Figure 3: DevSecOps + SDLC = SSDLC

Expanding on the shift-left mindset, empowering developers and infrastructure engineers to own security objectives end-to-end boosts the security posture of an application. Achieving that ownership requires emphasizing automation and fast feedback cycles. If a developer pushes code, there should be immediate feedback on any potential security issues with the new features or fixes. Assuming there is actionable feedback, the developer makes the necessary changes, and the organization has immediately improved security without the intervention of a security engineer.

At Red Ventures, focusing on a “frictionless” experience for developers meant that efforts to improve critical aspects of security, particularly containerized workloads, were readily adopted. Existing workflows can be used to enhance security with minimal disruption.

Further integrating this automation into CI/CD means that application code as well as infrastructure-as-code(IaC) changes can be analyzed for potential issues, presenting rapid feedback as needed.

Organizations Can Improve Security Outcomes with DevSecOps

Figure 4: The DevSecOps value proposition

Once organizations stop worrying about DevOps security, and implement DevSecOps, they'll have evolved their software development and delivery to the next stage of DevOps culture. In DevSecOps culture, security joins the collaborative model shared by operations and development.

Shifting security left means that security objectives are baked in from the beginning. Developers, infrastructure engineers, and operations are all empowered to take ownership of security issues. The fast-feedback cycles inherent in DevSecOps culture and tooling means that automation such as CI/CD pipelines can provide a granular view of potential security issues in seconds and minutes, not hours or days.

Choosing modern tooling to support a DevSecOps initiative is key. Legacy security tools and processes weren't designed with the rapid pace of change present in cloud-native architecture.

With DevSecOps in place, an organization can deliver software faster and more securely, and ultimately generate more value for their customers and themselves.