Roles shifting can be disconcerting. Having a clear role and understanding your responsibilities and tasks is comforting. But getting too comfortable can be dangerous. Take parenting for example. Parents wouldn’t be doing their kids any favors by continuing to feed and dress them as if they were 4 when they’re 10. As children age, they start to do these basic tasks on their own, and the parent role shifts to one of enabler – helping and guiding children as they do these tasks for themselves. This shift leaves the parents free to focus on more “value-add” type activities, such as homework and social activities.
Similarly, most people find their role in the workplace changing as their career advances. For instance, the shift from individual contributor to manager accompanies a shift from doing to enabling. Just as parents stop doing everything for their kids and start enabling kids to do things for themselves, managers need to stop doing all the work, and enabling and guiding their team to do the work.
This is not an easy transition, and one many never fully make (think “helicopter parenting,” empty nesters feeling lost and depressed, or micromanaging bosses).
But in the end, not making it does more harm than good – in child rearing, the workplace … and even application security.
With the shift to DevSecOps, security professionals are undergoing a shift in their role in the development process. Security’s role in AppSec is shifting from one of “do-er” to enabler. Just as kids growing and maturing changes the landscape and forces a shift in roles, changing and maturing software development is instigating a role shift as well.
In this new landscape, the security team is no longer doing the security testing, but enabling developers to do the testing. And just as with raising children or managing a team, neglecting to embrace this shift will harm both the process and the individual.
With the number of applications exploding and the pace of development rapidly intensifying, traditional application security methods are no longer able to keep up.
Security teams conducting their testing after the development process, then sending results back to the dev teams to address them is simply not feasible in today’s fast-paced environment. Today, security needs to shift left and be addressed early and often as part of the development process. Modern application security programs feature centralized governance by security, but testing and fixing are owned by development in an automated fashion throughout the build process. In this approach, security owns setting policies, tracking KPIs and providing security coaching to developers.
In addition, security is responsible for providing developers with support in integrating scalable tools like Veracode into their SDLC. Developers own testing applications in their development environment, fixing flaws to pass policy and continuing to build code. In this process, security-related defects are just another bug during the build process, and developers have the tools and guidance needed to fix them. At the same time, security can govern the program to make sure KPIs and policies are met.
DevSecOps is going to be a disruptive force for security professionals. But it’s also a positive shift, creating an opportunity to greatly improve application security, and allowing the security team to focus on more value-added tasks and initiatives like governance and coaching.
As with most life changes, the key is to understand the change and its implications on your role and be prepared to not only survive it, but thrive in it. Change is never easy, but failing to adapt will inevitably hold you and those around you back.
Get best practices for working in this new development environment in The Security Professional’s Role in a DevSecOps World.