A Closer Look at Security’s Role in a DevSecOps Organization

In February, we hosted a virtual summit titled “Assembling the Pieces of the DevSecOps Puzzle.” The goal of the summit was to provide organizations with tools and information to implement a DevSecOps strategy in their organization—and make the shift from theory into practice. 

In his educational webinar at the summit, Chris Wysopal—CA Veracode’s CTO and co-founder—tackles an important, practical question head-on: If AppSec is shifting left, and the responsibility of testing security now belongs to developers, what does this mean for the security team?

First, it is important to note that DevSecOps does not shift all security responsibility onto the development team. Instead, it requires that the teams integrate “so that they’re working together as one team as opposed to a separate team [development] with an audit function [security],” noted Wysopal.

Therefore, security teams need to shift their thinking and start acting as “builders,” rather than “breakers.” They need to work to integrate security into development, instead of fixing it after the fact. This requires educating developers, forming open means of communication between the teams, and, most importantly, automating as much as possible so that it does not burden development teams.

Automate or batch

Automation is key to shifting security testing left into development. You need to keep developers moving forward, not asking them to stop coding to open another tool and start scanning. But what about testing that simply can’t be automated? For testing like manual testing and threat modeling, make sure you take it out of band of the DevOps pipeline – you don’t want to create gates that hold up the build. Additionally, conduct manual processes in small batch sizes so they don’t hold things up for extended periods of time. For example, conduct threat modeling on a piece of software, rather than the whole application. Or manually test just the pieces of the code that need it, for example, a password reset mechanism. 

Keep in mind that, not only do you want to help developers find the problems, you want to enable strategies for them to fix the vulnerabilities and errors found. You can do this by creating guidelines, checklists, and recipe-style formats so developers know what to do in a particular situation. This way, developers have the necessary information on hand and do not need to waste time calling and searching for help.  

Create security champions

Wysopal also discussed the importance of “security champions,” which Sonali Shah, VP of Product Strategy at CA Veracode, discussed in her summit webinar. Security champions play an increasingly important role with the rise of DevSecOps and the shifting left of security. The security champion acts as a security ambassador on the development team, maintaining consistent communication and knowledge sharing between both groups. In a poll conducted during the webinar, Wysopal found that most AppSec security advisors oversee nearly 200 developers, so it is evident that security officers need liaisons and well-trained security specialists to relay important information.

Have developer empathy

If the security team is going to start working more closely with the development team, they need a better understanding of what developers do. To effectively develop relationships between the development and security teams, Wysopal emphasized the importance of having developer empathy. Essentially, security should understand developers’ goals, incentives, and, most importantly, struggles. This way, security can understand what motivates developers and how to properly integrate security so as to maintain their culture and deadlines.

The security/development relationship still a struggle

At the end of the webinar, Wysopal answered questions from viewers that were very revealing in terms of what organizations are struggling with in the shift toward DevSecOps:

How do I foster a relationship between security and engineering?

Be united: Meet with counterparts and think of yourselves as one team.

Have empathy: What is the other team struggling with? What is the other team’s goals?

Shared accountability: Set common goals and hold each other to them.

What if my security officers don’t want to work with my developers?

Be clear; working with developers is a mandatory part of their role.

Vocalize benefits: It is better for their career going forward since they will gain a breadth of skills, understanding, and experiences.

How do I get my overworked AppSec experts to prioritize helping DevOps teams?

Security champions: Build this program quickly and effectively to alleviate some of the responsibility from overworked security officers

Listen to Chris Wysopal’s full talk here.

*** This is a Security Bloggers Network syndicated blog from RSS | Veracode Blog authored by [email protected] (mspencer). Read the original post at: http://www.veracode.com/blog/managing-appsec/closer-look-security%E2%80%99s-role-devsecops-organization