RSA is arguably the preeminent security conference of the year. 2019 looks to live up to the excitement with a schedule full of knowledge sharing from the top experts in our industry. All week, we will share what we are learning this year, on both our social media channels and our blog.
Monday was full of pre-conference seminars and sessions to attend, and the one that caught our eye was DevSecOps Days. Our very own Tim Jarret, Director of Product Management, attended this day-long seminar and has a few takeaways to share with you.
DevSecOps is here, just not evenly distributed
DevOps alone still largely remains an aspirational goal for companies looking to accelerate their development schedules, drive predictability, and pivot quickly to new market demands. The theory of DevOps is fantastic, but the practice isn’t as straightforward. It makes sense that DevSecOps is catching on in theory, but remains aspirational in practice.
Tim says that, “A lot of practitioners talked about the ideals of DevSecOps but acknowledge that there are still a lot of challenges. Some attendees are still struggling with the DevOps transformation alone (including how to make traditional infrastructure teams ‘agile’), so DevSecOps is a challenge atop a challenge.”
The biggest hurdles facing DevSecOps may be organizational and psychological rather than technological
There is little dispute that the ability to implement DevSecOps from a technology perspective is possible, and some companies have found success in doing so. However, technology remains an easy escape for blame when the real problems are with the people. Technology enables DevOps and DevSecOps, but it’s people, processes, and culture that drive it forward. So all the technology in the world will not help a company if they do not have the capabilities and drive to execute a DevSecOps strategy. It’s also why companies are looking for vendors to not just provide them with a “shiny tool” but give them a full programmatic approach to DevSecOps.
One moment stood out to Tim – “One panelist talked about the challenge of getting security practitioners to agree to implement feedback loops around incidents as an example of a simple mind shift. A danger is that security continues to see itself outside processes and therefore abdicates power where it could have an opportunity to drive change.”
Our recommendation to security leaders: be an enabling body who’s mission is to help drive development forward. Lead with stories about how your developers must deal with the backlog work, in the form of security issues, that will slow down development later or, worse, force them to drop everything when a breach occurs.
To succeed with DevSecOps, security must recast what it does in terms of business value delivery
Our previous recommendation drives right into the third takeaway from DevSecOps Days. Security is often seen as a blocker to getting work done – the annoying person over your shoulder preventing your code from moving forward. This does not have to be the case, and security should be champions for efficient and high-velocity development.
Tim’s thoughts on this? “It’s hard to prioritize security activities that avoid risk against projects that deliver business value. Security needs to define its work as helping to deliver business value faster or more safely rather than standing outside the process.”
We recommend that your security team sets a goal for itself: In the next 12 months, someone on your team will deliver a presentation, webinar, or speaking engagement on how you helped increase the overall velocity of your development teams. Make that a real driving goal for your team and ask yourself if the processes and controls put in place are driving your team towards that goal.
Stay tuned for more from RSA …