Security: Make a Commitment to Working With Development

The days of security and development working side by side in separate silos are over. With the DevOps-induced security “shift left,” security testing now falls in the realm of the developer, and leaves security in more of an enabling, rather than enforcing, role. And this new role requires a new understanding of developer priorities and processes. The security function cannot be effective in a DevSecOps world without a thorough grasp of how developers work, the software development tools they use, the challenges they face and how security fits into this picture.

In a DevSecOps environment, developers own the testing of applications in their development environment, fixing flaws to pass policy and continuing to build code. 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.

With the traditional security role of running scans on completed code and passing back reports to developers, a lack of understanding of the developer function wasn’t necessarily a show-stopper. But security’s new role does require this understanding – without it, security professionals simply won’t be effective and will get left behind as the pace of development continues to accelerate.

Security needs to understand developer processes in order to best integrate security into development workflows. In addition, developers can’t fix every flaw at the same time, so security needs to be pragmatic, be aware of development’s priorities and bandwidth, and help them prioritize the tasks and the timelines.

And we are already seeing good progress on this shift. Veracode recently conducted a survey of 400 IT pros who are involved with application security, and 58 percent of respondents indicated that application development and security teams collaborate to prioritize security defects based on likelihood of exploitation, and 45 percent said that the security team regularly participates in daily scrums and planning meetings. We’re clearly moving in the right direction, but we’ve got more to do.

Make a Commitment

Security teams must commit to understanding developer tools, processes and pains. How to commit? Start by:

Understanding the developer role: Having empathy for developers and their challenges will go a long way in making you more effective. Try taking a developer or two to lunch, and have them explain their processes and challenges.

Learning to code: You will need to be familiar with coding practices. There are numerous free or almost-free software development classes available. For instance, Coursera and Ed-X offer a number of excellent courses on “learning to code” through to advanced computer science topics like AI and machine learning.

Experiencing a “day in the life of a developer”: Shadow a developer for a day or part of one to understand their challenges and processes.

Learning about the tools of the trade and how they work – Git, Ansible, etc.: Focus on gaining a high-level understanding of the tools and what they do, rather than details about specific tools, i.e., focus on the “why” not the “what.” Spending time with your developers will aid in understanding what problem they are trying to solve.

Visiting online developer communities such as StackOverflow or joining development Slack channels: Find out what developers are thinking and talking about. Take it one step further by looking for security-related topics and questions, and contribute to the conversation where you can.

What is your experience with the shifting roles of DevSecOps? Are your security and development teams working more closely? Get more of our thoughts about the evolving security professional role in The Security Professional’s Role in a DevSecOps World.