Orchestrating DevSecOps: Security at Speed

The demand for speed and innovation is all around us. However, that enthusiasm sometimes creates conflict when it butts up against security, which tends to value the status quo. In some cases, the dogged hunt to increase velocity can introduce new challenges and risks (e.g., skipped process gates, insufficient testing).

The goals of development teams can seem at odds with what security teams need to do. Traditional models of security have certain characteristics (e.g., manual, sequential, segregation of groups, narrow guardrails) that don’t always jibe with a development team’s thirst for speed, flexibility and innovation. The result is an all-too-common mindset that "security is blocking the world." (“It doesn’t matter how fast we develop, delivery will be halted by onerous security checks and change control.”) But it doesn’t have to be that way. Especially when you consider that development, security and operations teams all strive for the same goal: Release fewer vulnerabilities into production.

DevOps is desired; security is required. DevSecOps brings them together.

Enter DevOps , with its emphasis on people (e.g., collaboration), process (e.g., fast feedback loops) and technology (e.g., automation and orchestration). DevOps brings together disparate groups to pursue a shared objective: software that is not only functional but also secure.

Source: Loves.cloud

At its foundation, DevOps requires continuous integration and continuous delivery (CI and CD) technology to help stitch together steps in the software delivery process and thereby reduce waste (effort, time, cost). With that goal in mind, and recognizing that security plays a key role in software delivery, it makes perfect sense to “push security to the left” by weaving security steps into developer workflows. The result: faster releases and more secure releases, as well as the freedom to focus on the mission.

Building compliance and governance (e.g., approvals, warnings, rejections, remediation) right into the developers’ own tools and workflows empowers them to own the security experience – continuously test code and fix defects – without having to be security experts. The well-documented benefits of this type of automation and orchestration are legion: increased productivity, decreased manual effort, fewer performance outages, stronger security posture, clearer compliance picture….the list goes on and on. This is DevSecOps in practice. This is “security at speed.”

But I will go a step further and say that automating security is a way to actually accelerate an organization’s adoption of DevOps. For organizations searching for tangible steps to do DevOps, a continuous security model can be an effective on-ramp because there are usually discrete security teams, security steps are usually prescribed and compliance is often well-defined. Far from an ethereal concept, automating security and orchestrating its role in the development lifecycle make a great early step to putting DevOps into practice.

Bottom line: DevSecOps might seem daunting, as if you first need to controller DevOps. However, integrating security into the development process is just one aspect of putting DevOps into practice. DevSecOps is within reach of many organizations, even though some might not realize it.

Lots of people have been using CloudBees or open source Jenkins for a long time, primarily for traditional software development purposes, which makes the DevSecOps use case a novel – and logical – extension of a tool that’s familiar the world over. Because of that, pivoting from traditional use cases to the DevSecOps use case feels simultaneously natural and revelatory.

This recognition is growing rapidly. There is no shortage of DevSecOps reference architectures, and Jenkins is featured at the heart of most. A few examples are below.

Sample DevSecOps Reference Architectures

Source: Edureka!

Source: Coveros, Inc.

Using CloudBees Core for DevSecOps is remarkably straightforward:

• Weave security functions and controls throughout the development lifecycle by plugging security actions into Jenkins pipelines (example below).

• Insert automatic and manual gates to ensure that insecure or non-compliant software does not move downstream.

• Integrate approvals, warnings, rejections and remediation into developers’ own tools and workflows.

• Visualize the software pipeline through the CloudBees Core user interface in order to monitor pipeline progress and correlate it back to security checks.

• Apply governance protocols like Role-Based Access Control (RBAC) to provision smartly – and make security staff and sys admins happy.

(image 4)

Source: CloudBees, Inc.

What’s more, CloudBees Core leverages the massive ecosystem of ~1,500 Jenkins plug-ins to integrate with the most commonly used security tools. This means that no matter the tools you have in your environment, CloudBees Core can probably orchestrate them right out of the box.

DevSecOps might seem out of reach, but don’t be fooled! Starting with just a basic CI/CD foundation, you can begin pushing continuous security to the left and reap the rewards. By automating security/compliance tools and processes , you reduce defects due to human error, gain confidence that the right security checks have been completed (and acted upon), build a consistent and transparent audit trail showing how your applications were built over time, and ensure a system is always worthy of release.

The result? A quicker path from concept to creation, with fewer vulnerabilities released into production, thereby strengthening your security posture and decreasing the performance problems that cause outages and bog down security teams and developers alike.

With the astonishing rise of DevSecOps, it’s an exciting time to be with CloudBees, teaming with service providers to reveal this novel use case to customers and give them an extraordinary experience.

• Hear the DevOps Radio podcast about DevSecOps