Framing the challenge
DevOps is desired; Security is required. DevSecOps brings them together.
The demand for speed and innovation is everywhere. 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 considering that development, security, and operations teams all strive for the same end state: Fewer vulnerabilities in production.
Who should care about this?
This scenario applies universally to government agencies and the vast surrounding ecosystem of private industry that advises and performs services related to DevOps, IT modernization, and information security. With a government-wide push for IT modernization, citizen-facing digital services, website modernization, and the fact that many programs rely on producing functional and secure software, agencies want greater DevOps maturity , but they’re often unsure how to turn that goal into reality in a world where compliance matters a lot.
From challenge to opportunity
A Convenient Truth: Security Can Accelerate DevOps Adoption
Enter DevSecOps, which unites groups around a shared objective: software that is both functional and secure. Agencies increasingly recognize that security plays a key role in software delivery, and therefore it makes perfect sense to “push security to the left” by weaving security steps into developer workflows. The result: faster releases, more secure releases, and the freedom to focus on the mission.
A tidy definition of DevSecOps comes from my colleague Nic Chaillan, who is doing some incredibly pioneering work to build a DevSecOps platform of best-of-breed tools that can be leveraged as a turnkey solution across the Department of Defense enterprise.
“The software integrated tools, services, and standards that enable partners and users to develop, deploy, and operate applications in a secure, flexible and interoperable fashion.”
The General Services Administration is pursuing a DevSecOps model “that will not only engage Security throughout the development and operations processes, but more specifically, ensure their involvement as we align the Authority to Operate (ATO) process” with its increasing adoption of cloud.
The Department of Homeland Security is working technical and policy angles simultaneously. While its cloud steering group tackles aspects of policy, its Cloud Factory is helping to establish a highly automated, secure, reliable set of managed services that allow for the dev/ops flow, feedback, and innovation of various applications.
DevSecOps and authority to operate (ATO)
A prime example of a thorny issue wrapped up in both technology and policy is everyone’s favorite whipping boy: the ATO process. One sticking point is that an ATO is usually good for three years, although it assumes no major changes to a system’s cybersecurity posture will be made during that time. When changes do occur, the Authorizing Official might require a reassessment and reauthorization, which impacts project cost and schedule and runs counter to being Agile.
Fortunately, the National Institute of Standards and Technology’s Risk Management Framework (RMF), the government’s foundation for system assessment and accreditation, encourages an alternative approach to the traditional 3-year ATO process through continuous reauthorization. The daunting and labor-intensive application of RMF controls presents a prime DevSecOps opportunity: automation and orchestration can minimize the release of crappy code (happy Dev!), make the results of security gates a foregone conclusion (happy Sec!), and provide continuous visibility into system changes and security posture (happy Ops!).
Achieve “security at speed” through automation and orchestration
People have been using CloudBees or open source Jenkins for a long time, primarily for traditional software development, 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.
Using CloudBees to build compliance and governance (e.g., approvals, warnings, rejections, remediation) into the developers’ tools and workflows empowers the developers to own the security experience – continuously test code and fix defects – without having to be security experts. This is DevSecOps in practice. This is “security at speed.”
This recognition is growing rapidly. There is no shortage of DevSecOps reference architectures, and Jenkins is usually featured at the heart. A few good examples are below:
Sample DevSecOps Reference Architectures
Source: Nicolas Chaillan
Source: Edureka!
CloudBees Core to implement DevSecOps
Using CloudBees Core for DevSecOps is 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 insecure or non-compliant software doesn’t move downstream.
Integrate approvals, warnings, rejections, and remediation into developers’ own tools and workflows.
Visualize software pipeline through the CloudBees Core UI in order to monitor pipeline progress and correlate it back to security checks.
Apply governance protocols like RBAC to provision smartly – and make security staff and sys admins happy.
What’s more, CloudBees Core leverages the massive ecosystem of ~1,500 Jenkins plugins to integrate with the most commonly used security tools (see sample below). That means that, no matter the tools in an environment, CloudBees Core can orchestrate them right out of the box.
CloudBees solutions help meet common needs of enterprises embarking on their DevSecOps journeys, as seen below.
Moving forward – the “So What?”
DevSecOps isn’teasy to implement, it requires a commitment to new ways of carrying out a mission. Fortunately, DevSecOps can yield profound benefits to agencies.
DevSecOps might seem out of reach, but don’t be fooled! With just a basic CI/CD foundation , security can be pushed to the left and the benefits of “speed to capability” can be had. By automating security/compliance tools and processes, defects due to human error are reduced. Developers can be confident the right security checks have been completed (and acted upon), build a consistent and transparent audit trail showing how 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 security posture and decreasing the performance problems that cause outages and bog down security teams and developers alike. Imagine being able to identify and correct flaws early in the delivery process, before they’re exposed to the public.
With the astonishing rise of DevSecOps, it’s an exciting time to be with CloudBees, teaming with government agencies and service providers to give customers an extraordinary experience.
Additional resources
Learn why buy-in from everyone is essential for DevOps success
Listen to a podcast on scaling a DevOps transformation
Download the Accelerate: State of DevOps 2018 report