DevOps implementation is often unsuccessful. Here's why (and what you can do to move forward).

Much like "blockchain", "big data" and "digital disruption", the term "DevOps" is another term thrown around the IT departments of large organizations, but with this one, development managers are faced with significant changes depending on the maturity of the company’s SDLC.

Many have (correctly) identified the need for faster software development lifecycles; a more precision process that is closely aligned with business objectives, allowing for clearer workflow and collaboration between the development and operations-based teams. DevOps is essentially "Agile" development, all grown up and ready to take on the constantly innovating, rapidly deploying needs of the modern business.

The problem is, few companies are truly successful in their DevOps implementation. Without the right support, nurturing and understanding across the business, it can quickly become one of those "don’t mention the war" projects, and everyone just keeps operating with whatever dysfunction they previously had.

For security professionals, it’s a good initiative but it still doesn’t mix the security team in from the beginning as much as would be ideal; however, security can still be injected into the process far earlier than say, the Waterfall method (yes, it’s an old process… and yet, many organizations still operate under that methodology), reducing the cost of fixing bugs and helping to avoid potential catastrophe down the track.

So, what’s the problem? It goes back to the fact that successful execution of an updated methodology can’t be bought. An effective program goes beyond a few fancy new tools, titles and team meetings. It’s not always going to be easy, but taking the time to fix a broken strategy (or implement it the right way at the start) is going to be far less painful in the long run. And ultimately, it’s going to result in your developers crafting higher quality software and pave the way for better security outcomes.

Let’s break it down:

Let go of the "Agile" apron strings

There is somewhat of a misconception that an organization must choose between Agile or DevOps, setting down one path or the other, never to look back.

The thing is, the development process works best when both are being considered and implemented as one. DevOps is ​not ​ a reinvention of Agile development; rather, it is an extension of it. The wheels tend to fall off when there is an expectation that the process will be exactly like ​ Agile, or ​completely different ​ from Agile. Agile supports the principle of cross-functional teams, bringing designers, testers, and developers together from the beginning and committing to open communication lines throughout a project. Its aim is to stop siloed delivery and reduce double-handling, both of which are benefits of the DevOps process as well. However, DevOps goes a step further, introducing developers, systems, and operations into the mix to offer a robust, end-to-end skillset that had the ultimate goal of full, functional software delivery to the customer. Security is also considered earlier, though separated AppSec teams are still fairly common even in this environment.

During the inevitable pain-points of moving to a more DevOps-centric process, the risk of siloed development can crop up again. You can often have the original Agile team working together, with the security and operations additions still finding their way in the machine; no-one is quite sure how to include them, what they should be doing and their overall objectives.

DevOps does not work without clearly defined objectives, cross-functional onboarding and direct communication with all parties. There will be an adjustment period requiring careful change management, sure, but getting everyone on the same page with the enhancements that DevOps functionality will bring is half the battle.

Increasingly (thank goodness), DevOps is placing emphasis on security best practice as part of the process as well, demystifying that step and bridging the gap between the security team and, well, everyone else. As I have said before, we still have a long way to go in empowering developers to code securely from the start, but the successful implementation of DevOps methodologies is an excellent foundation on which to build into a fully-fledged DevSecOps program, with security as a primary goal and a shared responsibility, with developers given the support they need to thrive in this process.

Automation isn’t everything (and it’s not the most secure)

The primary feature of DevOps is, to a certain extent, the automation of the software development process. Continuous integration and continuous delivery (CI/CD) principles are the cornerstones of this concept, and as you likely know, are very reliant on tools.

Tools are awesome, they really are. They can bring unprecedented speed to the software delivery process, managing the code repository, testing, maintenance, and storage elements with relatively seamless ease. And if you’re managing a team of developers in a DevOps process, these tools and ​the people who use them are a vital piece of the puzzle​ in shipping quality software.

However, while robots might take all our jobs and imprison us someday, they are definitely not there yet. Heavy reliance on tools and automation leaves a window wide open for errors. Scans and tests may not pick up everything, code may go unchecked, and that presents enormous quality (not to mention, security) issues down the track. An attacker only needs one back door to exploit to steal data, and forgoing the human element in quality and security control can have disastrous consequences.

The "happy medium" is to ensure you have a balance of people ​and ​ tools. Tools should serve as the assistants to a team you trust to deliver on project goals. You should:

• Allocate enough time for people to become familiar with the chosen DevOps toolchain
• Focus on effective collaboration (and how the tools can support that)
• Address any gaps in the process, whether they are skill/knowledge or tool-based.

In short, don’t just "tool up" and hope for the best.

DevOps isn’t a buzzword, it’s a culture. Are you growing yours?

Change management is tough at the best of times. Fear of the unknown can stop even the most brilliant team members from growing their skills and expanding their horizons.

You see, merely saying "let’s do DevOps" and making the operations team move desks isn’t going to magically implement a successful process. Many will be confused, and long-serving members of the team will be left feeling disgruntled. Communication of expectations is crucial, as is "walking the walk". DevOps represents a cultural movement just as much as a development methodology, and a team should live and breathe a cross-functional, collaborative mindset.

Development managers will need to advocate for their teams and help through what may be an uncomfortable adjustment period.

What does a great DevOps culture look like?

• Individuals are empowered to lend their expertise to a process, not just leaders
• Open, honest and respectful communication between teams
• Each person takes responsibility for the overall objective of building quality (and hopefully security) into the development process
• Everyone is on the same page with the definition of DevOps in the business, the roadmap and how/what/why of each person’s role.

When I say this is a foundation for security excellence, I believe that most of the elements help forge a path for where we need to arrive (and quickly): DevSecOps best practice.

Moving the needle to DevSecOps

For years I have emphasized the importance of building positive security cultures in organizations, and it is DevSecOps that promotes security as a shared responsibility, as well as making it a primary goal from the beginning of the software development process.

The right tools, knowledge, and support are imperative to achieving security best practice, seeing a downturn in discovered vulnerabilities and opening the team’s eyes to the importance of protecting our data. DevOps lays the cultural groundwork for positive change, but pivoting to an environment where you put the "Sec" in "DevSecOps" is a necessary, but not so painful transition from there. Ensure everyone -- especially developers -- understands their role, value, expectations, plus the overall project goals and steps in the process. And you ​must ​ ensure they have what they need to succeed - don’t throw any old training at them, and don’t reward speed over security in shipped code. Help the whole team understand the importance of it, and the immense positive impact they can have at their fingertips.

Company-wide security awareness is a must, but it is your developers that can be the first line of defense with the right team leader advocate, the right tools, and time to get savvy with secure coding.

Not sure where to start with DevSec? Get ​the five point tactical to Secure development.