 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
DevSecOps is a hot term that many security leaders and executives are talking about. However, this process of embedding security into every stage of the software development life cycle (SDLC) is, like many technology undertakings, also subject to a number of misconceptions and myths.
To successfully implement a DevSecOps program within an organization, it is important to enter into the effort with eyes wide open, and to understand that some of what you have heard about it might be wrong.
Here are five common misconceptions and myths that might be holding organizations back from adopting DevSecOps.
It’s easy to see where this idea might come from, because a lot of people in the development community might view anything having to do with product security as a hindrance that takes away their freedom and creativity. Developers, project managers and others like the idea of being in control of their work and the pace of their progress.
Furthermore, people might have concerns about DevSecOps automation and what it might mean for their own sense of purpose on the team. While manual processes can be slow and methodical, they do give teams a hands-on feel that can also provide a sense of control.
To address the misconceptions related to control, DevSecOps leaders need to educate the team about how the process works and why it is beneficial to all. It might help to share real-world stories of how well DevSecOps is working at other organizations and the gains they are seeing with the help of all team members.
Perhaps because of vendor marketing and public relations verbiage, some people have gotten the mistaken impression that DevSecOps is a product or service that can be purchased and implemented like so many technology tools.
As with DevOps, there is no single tool or suite of tools that deliver all the capabilities of DevSecOps, no matter what sales and marketing representatives claim. Thinking that DevSecOps can be bought and used without any changes in cultural mindset, collaborative efforts and processes is, of course, a mistake.
Again, education is needed about exactly what DevSecOps is and isn’t, and what the concept entails. This is especially true when senior business executives start demanding that the company “buy” DevSecOps right away to enhance security in the development and operations process.
How great it would be to deploy a secure development framework that readily fits into any type of organization, and once it’s set up, it can run indefinitely with minimal need for maintenance. Unfortunately, that’s not how DevSecOps works.
Yes, some of the central concepts can apply to any type or size of organization. But a DevSecOps initiative is meant to be adaptable so it can help meet the specific goals of an organization, fit within its culture and be in sync with all related operations, such as security.. Just as every organization is unique, so is every approach to DevSecOps.
And yes, there is automation involved, and it’s a big part of DevSecOps. However, the human element is vital for success. Change is a constant in both the development and security domains, so thinking that processes can continue running as-is, without the need for adapting, is a mistake.
Because DevSecOps is so closely related to DevOps, there might be a tendency to think the goal is to enhance and change development and operations, with no need to adapt cybersecurity in any way.
The security team needs to learn, and be willing, to collaborate with development and operations team members for DevSecOps to work. It’s not about security dictating how things will be done, but an effort to share goals and ideas to find the best solutions for everyone.
DevSecOps might require that the security team make changes in its own practices and methodologies to be in a better position to help make security a big part of the development process. As with the other myths, the key to addressing any misconceptions about what needs to change comes from educating all parties.
This is kind of a double myth. The idea that DevSecOps is only about technology is wrong, because it ignores all the people and process factors that are so important to success. It’s similar to the thinking that DevSecOps is something that organizations can purchase and run without intervention.
Technology is certainly a key component of DevSecOps, but it’s by no means the only one. How people work together to improve processes plays a big role.
Conversely, to think that DevSecOps is simply a matter of changing the culture of the development operations is also a mistake. While culture and mindset certainly come into play, teams also need the tools that enhance security in the development process.
