Fail-fast culture can be advantageous for modern systems design and development. But “fail fast” usually connotes learning and improvement. Without that piece, it becomes just “fail” – the speed doesn’t really matter.
This principle applies to DevSecOps, which like DevOps depends on a culture of continuous learning and improvement. You won’t always get it right and you will learn some lessons by taking missteps along the way.
4 DevSecOps mistakes
Just watch out for the big pitfalls when you do – these are the ones that are likely to stymie your DevSecOps approach and potentially cause more problems than you’re solving. Let’s look at four fundamental mistakes to watch out for.
[ Want a shareable primer on DevSecOps and its benefits? See What is DevSecOps. ]
1. You're playing buzzword bingo
As with other kinds of cultural and philosophical changes, DevSecOps is easier to say than to actually do.
Security in general is susceptible to buzzword bingo, the game in which we deploy lots of IT and business jargon in lieu of substantive change. Unlike the actual game of chance, you don’t want to fill this bingo card and declare yourself the winner.
“Too many times, I’ve seen organizations say that they do DevSecOps when in reality there is little security involved,” says Sean Wright, lead application security SME at Immersive Labs. “Just because you have a tool in your process doesn’t necessarily mean you are doing DevSecOps.”
Talking about security openly and honestly as an organization is a generative practice for a healthier security culture. Declaring “We do DevSecOps!” without any execution behind the statement is not.
[ Where is your team's digital transformation work stalling? Get the eBook: What's slowing down your Digital Transformation? 8 questions to ask. ]
2. There's a lack of real commitment and resources
Speaking of execution, if you believe in what you’re doing, you need to ensure there’s a visible long-term commitment to making DevSecOps work. Especially if you’re coming from a more traditional (aka “legacy”) model for IT operations – and even if you’re already doing DevOps and are now trying to codify the role of security in your organization – there’s work involved.
That work is usually worth it, according to Wright and other proponents: “You need to commit to it,” Wright says. “Oftentimes, the more work you put in, the greater the reward.”
“Commitment” and similar terms might sound a little fuzzy, but you can translate this into concrete areas. Are you giving your teams the budget they need to modernize their tooling and infuse security into every phase of the software delivery lifecycle (SDLC)?
Are you giving teams the time to rethink and revise how they collaborate to ensure security in earlier and earlier stages of development? Are they getting the resources needed to understand and identify threats?
If you’re answering “no” or “maybe” to those kinds of questions, then commitment isn’t fuzzy – it’s simply lacking.
“One of the most common mistakes that organizations make when building DevSecOps culture and practices is that they don’t give them sufficient due,” says Red Hat technology evangelist Gordon Haff.
This can sneak up on you if you’re making progress in one area – building more automation in your tooling and processes to mitigate threats, for example – but ignoring others. (Hold that thought – we’ll get back to it in #3.)
This appears to be a more pressing problem than some organizations realize. In a study conducted by Immersive Labs with Osterman Research, just 39 percent of security teams said they have the proper time and resources to “shift left” in the SDLC and support more secure application development.
Meanwhile, more than half (54 percent) of security pros in the report said they don’t think their developer counterparts have a sufficient understanding of the modern application security threats to their code.
[ Read also: What is ransomware? 5 facts IT leaders should understand now. ]
3. You're using technology to hammer every problem
These data points speak to one of the main pillars of DevSecOps success: People.
When Haff says that some organizations make the mistake of not giving DevSecOps its due, he adds that the people and culture component is most often the glaring omission.
Of course, it’s not actually “glaring” until you realize that your DevSecOps initiative has fallen flat and you start to wonder why. One way you might end up traveling this suboptimal path: You focus too much on technology as the end-all solution rather than a layer in a multi-faceted strategy.
“They probably have adopted at least some of the scanning and other tooling they need to mitigate various types of threats. They’re likely implementing workflows that incorporate automation and interactive development,” Haff says. “What they’re less likely paying less attention to – and may be treating as an afterthought – is people and culture.”
Just as DevOps was about more than a toolchain, DevSecOps is about more than throwing security technologies at various risks.
“An organization can get all the tools and mechanics right but if, for example, developers and operations teams don’t collaborate with your security experts, you’re not really doing DevSecOps,” Haff says.
4. Leaders and teams aren't on the same page
Perk up, IT leaders: This mistake might be the easiest to miss if you’re not paying attention.
All of the above and more conditions antithetical to DevSecOps success become more likely when managers and teams aren’t on the same page.
“Oh, don’t you worry about it. My team and I are on the same page,” you say.
Are you sure? In the Immersive/Osterman study, 80 percent of senior managers said they believe security is everyone’s responsibility, including developers. That sounds great, right? After all, shared responsibility is a central tenet of DevSecOps culture and practices.
The problem: Only 27 percent of their front-line development staff see security as part of their job responsibilities. That’s not a gap – it’s a chasm.
There’s a difference between thinking (or even saying aloud) that you’re aligned and investing in making that happen.
That’s the moral of the story that runs through many of the major pitfalls in a DevSecOps implementation: Make sure you’re committed to the changes necessary to make it work and show that commitment up by giving your teams the time, resources, tools, and education they need to build a sustainable culture.
The Immersive/Osterman report also highlights the risks of not doing so: The vast majority (81 percent) of development teams surveyed said they’ve pushed code to production with known security vulnerabilities, with one in five senior managers copping to doing so often.
In other words: There’s a reason why DevSecOps interest is soaring.
“You need to infuse security throughout the lifecycle of the process, embed the appropriate tools at the right stages, and – most importantly – equip your staff with the right knowledge, skills, and judgment to run and consume those tools, as well as prevent and fix security issues,” Wright says. “This ultimately allows everyone to have a part to play in the overall security of an application or service.”
[ How do containers and Kubernetes help manage risk? Read also: A layered approach to container and Kubernetes security. ]
