{{announcement.body}}
{{announcement.title}}

Adding "Sec" Into the DevOps Mix

DZone 's Guide to

Adding "Sec" Into the DevOps Mix

Security experts, and operations team members need to operate in harmony. This extends to security in all stages of development.

· DevOps Zone ·
Free Resource

Just when we thought we knew what we were doing with DevOps, it’s time for an even longer — and more challenging — term, DevSecOps. DevSecOps is scaled, enterprise-level DevOps where security is baked into every step of the process, shifting the entire SDLC left and creating a culture where everyone has a stake in quality and security.

This is the right time to talk about adding “Sec” into the DevOps mix because security breaches are at an all-time high. In the first quarter of 2019, over 1900 breaches were reported involving 1.9 billion records, according to a report from Risk-Based Security. That’s an increase of more than 50% year-over-year. It’s never been more important to ensure code safety. But it’s also never been more important to release code quickly. The tension between these two competing demands is real, and reflects the distinct — and often contentious — divide between developers and security pros.

To truly scale software development, developers, security experts, and operations team members need to operate in harmony. This will require a serious rethink of both corporate culture and the development toolchain. Developers are being asked to do more than ever before, and at a much faster pace. A streamlined toolchain that gives them the information they need in their existing workflow is critical. Test automation with CI/CD, monitoring, and security all need to be in the same place. With the right tooling, it is easier to begin incremental cultural changes that will empower ownership of security across the entire lifecycle.

It’s hard work, and the playbook isn’t established yet, but the payoff is clear. Organizations that have scaled DevOps successfully report they are three times more likely to find bugs before code is merged and 90% more likely to actually test all, or nearly all, of the code, according to GitLab’s 2019 Global Developer Report: DevSecOps.

But the survey also found 49% of security pros struggle to get developers to address needed remediations, and roughly the same percentage said bugs were most often found by them (not developers) after code is merged. Clearly there is work to be done.

Rethink Toolchains

Developers trying to do more with less can hardly be faulted for thinking a new tool might solve all the problems. But it’s possible to have too much of a good thing, or in this case, too many tools and toolchains. That excess can actually create more problems than are solved. In fact, the wrong choice of toolchains — or simply too many of them — can make it much harder for companies to scale from DevOps to DevSecOps.

A study from Forrester Research released in June 2019 found most companies use two or more toolchains for software development and, on average, each toolchain contains at least six tools. Over a quarter of organizations (27%) admit to using 3-5 toolchains. And, apparently, the more toolchains a company uses, the more tools get involved. The Forrester study found that two-thirds of organizations using three or more toolchains had supersized them to include 11 or more tools.

Toolchain “sprawl” causes exactly what DevOps seeks to eliminate — problems with productivity, visibility, and security. In fact, it becomes the responsibility of developers or release/DevOps teams to wrestle the toolchain beast roughly a third of the time. Toolchain integration is time-consuming — 35% said integration is accomplished by a combination of plug-ins and scripts — and 46% of respondents said they lack the skills, resources, or expertise to integrate discrete tools. Additionally, 44% said they struggle with toolchain maintenance issues.

The Forrester report found 67% of survey takers said handoffs among multiple tools were to blame for development delays.

Worse still, overburdened toolchains create significant visibility issues (40% of respondents said lack of visibility was a top challenge they’re facing). This can actually slow down software development because of the many handoffs required, as code has to be moved from tool to tool as it works its way down the release pipeline. The Forrester report found 67% of survey takers said handoffs among multiple tools were to blame for development delays.

It’s also clear that monster toolchains do nothing but make it harder to create secure code. Just under 50% of respondents said they spend too much time and money integrating and maintaining the diverse security landscape each tool requires.

While developers are dealing with toolchain issues, they’re not able to do the real work that leads to faster software development. Working across so many tools leads to a breakdown in communication and collaboration between development, operations, and security teams. This often spells inefficiencies — such as discovering bugs only after code is merged.

Making an Out-of-the-Box Choice

So “less is more” when it comes to tools, but how much more is it, really? Forrester asked organizations considering an out-of-the box toolchain what they expected the benefits to be, and then compared them with companies already using a single toolchain. Companies shopping around expected improved quality (46%), improved security (44%), improved developer productivity (40%), and increased revenue (38%). Companies already using a streamlined toolchain said they experienced increased security (47%), followed by increased revenue (46%), improved quality (45%), improved developer productivity (42%), and improved compliance (35%).

Companies need to choose a tool wisely, keeping in mind the complex task at hand. Security should be part of the decision-making process because identity and authentication hurdles need to be managed in a uniform way at every step. By eliminating stored credentials, developers and the operations team won't need to spend time on shortcuts and hacks, even while security is strengthened.

Speed also matters, and nothing can get an organization to operate more quickly than visibility into the process. Visibility ends guesswork when it comes to key areas like cycle time, flow, and backlog. So, a tool with monitoring and visibility can help simplify answers to questions of “Where are we not moving fast enough?” without interrupting workflow.

It’s also vital to keep bigger objectives in mind. A soup-to-nuts toolchain that can deploy to any cloud is the most efficient way to ensure a team remains cloud-provider agnostic.

Once that choice is made, the benefits are clear, according to the Forrester study. “An out-of-the-box toolchain that provides security, productivity, and fewer context jumps gives time back to engineering teams so that they can re-invest their time into working on innovation and customer success,” the study authors concluded.

Foster the Culture

With the right toolchain in place, it’s time to take an honest look at the culture, particularly around security. Secure code is everyone’s responsibility, but “everyone” can easily become “no one.” Developers, used to independence and, perhaps, a somewhat larger seat at the DevOps table, can be loath to let security professionals (and their many rules) into the process. The security team, on the other hand, can legitimately feel their hands are tied when it comes to code remediation.

These are valid concerns, but it’s important to remember we went through this same thing when Dev and Ops started working together. There were growing pains then, and we’re looking at more growing pains now.

The security team should be part of the engineering organization so they are naturally more aligned and share the same leader.

The underlying philosophy should start the conversation: the security team should be part of the engineering organization so they are naturally more aligned and share the same leader. Consider having developers and security professionals “co-work” on the challenges. In the past, we had dojos set up to teach developers how to do DevOps; we need the same plan now, only for DevSecOps.

The DevSecOps momentum is building. We need to ship fast and we need to ship securely. Companies that invest the time in aligning security teams with engineers by making the right organizational choices, picking the right toolchains, and investing in continued education for their developers will see the results: safer code that ships faster.

This article was originally published in our Scaling DevOps Trend Report. To read more articles like this, download the report today!


Read Today  

Topics:
Scaling DevOps ,devops ,devsecops ,security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}