If AI is going to have deep impacts on the human workforce, it stands to reason that human resources will need to play a vital role in how organizations adapt. That’s no small task.
DevSecOps: How to get your team on board
Security teams can’t live on an island in the age of DevOps. Use these 6 tips to win buy-in for change
Treat DevSecOps as serious business
Here’s how George Gerchow, chief security at Sumo Logic, views DevSecOps: “DevSecOps is about transparently finding, showing and sharing deficiencies quickly in order to improve on a continuous basis. Security can no longer be siloed and sit in an ivory tower, afraid of what might be exposed. Find vulnerabilities, fix them, and improve.”
His first step toward getting people on board with that vision is very much in the direct control of IT leadership: Show the rest of the organization you take it seriously, especially given that the technology hype machine does create some understandable skepticism of new terms and trends.
“In order for organizations to take this first step, they must accept that DevSecOps is more than a buzzword – it is the current and future state of IT,” Gerchow says. “All too often, security is one of the last pieces of the puzzle when it comes to building new solutions, but in actuality, the security conversation must come first, especially when it comes to the cloud.”
Stress the problem with the status quo
In an era of faster and more frequent deployments, bolting security onto the end of the delivery pipeline is increasingly problematic.
“Security cannot be last in the release process,” says Robert Reeves, CTO and cofounder at Datical. Yet he still regularly sees companies treat security as something that happens post-testing, just prior to a release.
Getting people on board with DevSecOps – and helping different parts of the broader team see their goals as shared – sometimes depends upon making clear why the old way of doing things is a problem.
Reeves shares some examples from the “security as final step” approach. For starters, when you do catch vulnerabilities prior to deploying to production, Reeves notes that the team – as in the whole team – is left with two bad choices: release the vulnerable code as is, or delay the release. Both can have negative consequences.
“Both expose the company to unnecessary risk: one from bad actors, the other from competition,” Reeves says. Everyone shares – or should share – responsibility for those negative outcomes. Develop clear cases for how moving security earlier into the pipeline minimizes those outcomes.
When it comes to tools, focus on automation
The advice to focus on people first does not imply people only. DevSecOps, just like its older DevOps relative, must ultimately account for other pieces of the puzzle.
“Getting your team on board with DevSecOps practices requires a combination of awareness, training, implementing the right set of tools, and standardizing key processes to structure team collaboration,” says Robert Hawk, privacy and security lead at xMatters.
Just as conflicting incentives or goals can stand in the way of a thriving DevSecOps culture, so can a hodgepodge of non-standard security tools.
When you sharpen your focus on security tools as part of DevSecOps, Sumo Logic’s Gerchow recommends a common thread: Automation. A fundamental reason why more companies don’t “move left” with security – in other words, make security a part of the earliest stages of the software development life cycle – is that to do so in manual fashion can be painful, especially as services or the organization itself scales. That’s further exacerbated in companies that struggle to find qualified security talent.
Treat automation as a key strategy for achieving the goals of DevSecOps without making people miserable in their jobs. From a technology standpoint, automation enables security to be baked into earlier and earlier stages of the SDLC without grinding everything to a halt – just as automation enables development and operations teams to tame the complexity of faster, more frequent deployments. For automation lessons learned from your peers, see our related resource: Automation: The IT leader's guide.
Want more wisdom like this, IT leaders? Sign up for our weekly email newsletter.